Перейти до основного вмісту

Частина 3: Побудуйте верифікацію

Ось рядок, який вирішує, займаєтеся ви справжньою інженерією чи просто покладаєтеся на вдачу: як верифікуються ваші результати? Якщо відповідь — «запускаю і виглядає, що працює», ви займаєтеся вайб-кодингом, незалежно від того, наскільки витонченими є ваші промпти. Верифікація — це дисципліна, яка робить AI-результат надійним на продакшн-рівні.

Два механізми працюють разом. Тести охоплюють детерміноване. Евали охоплюють те, що ним не є.

Тести: детермінований контракт​

Тести перевіряють ті частини вашої системи, де заданий вхід повинен давати заданий вихід. Це ті самі тести, які ви писали б у будь-якому разі — але в AI-робочому процесі вони беруть на себе другу функцію: вони передають наміри агенту точніше, ніж будь-який промпт.

Тест — це специфікація, яку може перевірити машина. Дайте агенту тест, що падає, і команду «змусь це пройти», і ви дали йому однозначну ціль плюс автоматичний спосіб знати, коли він закінчив. Тому пишіть тести спочатку:

def test_refund_over_threshold_requires_approval():
    charge = make_charge(amount=600_00)
    with pytest.raises(ApprovalRequired):
        refund_service.issue(charge.id, amount=600_00, approved_by=None)

def test_refund_writes_ledger_entry():
    charge = make_charge(amount=50_00)
    refund_service.issue(charge.id, amount=50_00, approved_by="alice")
    assert ledger.last_entry().type == "refund"

Агент тепер знає правило порогу і вимогу до реєстру без необхідності пояснювати це прозою. Тест і є поясненням.

Евали: оцінювання недетермінованих частин​

Тести не можуть охопити все, оскільки значна частина поведінки агента не є детермінованою. Чи пройшов агент розумним шляхом до відповіді? Чи вибрав він правильні інструменти? Чи справді гарний кінцевий результат, а не лише синтаксично коректний? Саме це вимірюють евали.

Евали перевіряються за допомогою розмічених датасетів, рубриків оцінювання, а іноді й моделі, що виступає суддею. Існують два різновиди, і вони обидва потрібні:

  • Оцінювання результату — оцінює кінцевий артефакт. Чи компілюється код? Чи проходять тести? Чи точне резюме?
  • Оцінювання траєкторії — оцінює як він туди дістався. Чи викликав агент правильні інструменти у розумному порядку, чи метався і випадково прийшов до правильного результату?

Траєкторія важливіша, ніж здається. Правильний на вигляд результат, який пропустив кроки верифікації, є більш небезпечним, ніж той, у якого є очевидна помилка, — бо він приховує ризик. Агент, який випадково написав правильний код, проігнорувавши набір тестів, врешті-решт напише неправильний код так само.

Конкретний рубрик евалу​

Для агента, який відповідає на запитання з вашої документації, набір евалів — це список кейсів плюс рубрик:

- question: "How do I rotate an API key?"
  must_mention: ["settings page", "revoke old key", "24h grace period"]
  must_not: ["email support"]   # we have self-serve rotation now
  tool_path: ["search_docs"]    # should retrieve, not answer from memory

- question: "What's the refund window?"
  must_mention: ["30 days"]
  tool_path: ["search_docs"]

Кожен запуск оцінює: чи згадав він необхідні факти, чи уникнув заборонених, чи слідував очікуваному шляху інструментів? Модель-суддя може оцінити м'якший вимір «чи ця відповідь зрозуміла і правильна» за рубриком, який ви пишете. Суть у тому, що «якісно» тепер визначено явно й перевіряється автоматично — а не оцінюється на окомір.

Маховик якості​

Тести й евали досягають повної цінності, коли ви вбудовуєте їх у цикл, що накопичується:

  1. Оцінюйте за набором бенчмарків.
  2. Діагностуйте збої, кластеризуючи їх за першопричинами (а не виправляйте поодинокі випадки).
  3. Оптимізуйте промпт, правило або інструмент, що спричинив кластер.
  4. Верифікуйте виправлення за регресійним набором, щоб воно залишалося виправленим.
  5. Відстежуйте продакшн-трафік на нові режими збоїв і повертайте їх до кроку 1.

Кожен оберт цього циклу дає наступному вищу вихідну точку. Саме так агент стає надійно кращим з часом без зміни моделі під ним.

Налаштуйте власний робочий процес​

  • Для наступної функціональності напишіть тести до того, як дозволити агенту генерувати код.
  • Побудуйте невеликий набір евалів — навіть десять кейсів — для однієї поведінки агента, яка вас цікавить.
  • Для кожного кейсу евалу визначте як те, що результат має містити, так і очікуваний шлях інструментів.
  • Додайте регресійний набір, що повторно запускає кожне виправлення.
  • Оберіть один продакшн-збій цього тижня, знайдіть його кластер першопричини і виправте причину, а не симптом.