Практичні поради: розумні способи покращення відповідей AI-агентів у продакшні

Використовуйте цей документ як оновлену версію ідей з матеріалу „Розумні способи покращення відповідей AI-агентів у продакшні“ для спеціалістів: чіткі етапи, впорядковані блоки коду та примітки щодо відновлення, які зберігаються під час передачі обов’язків. Етап Огляду найкраще функціонує, якщо його розглядати як вимірювану основу. Запишіть один ідеальний запис розмови, один випадок збою та примітки щодо скасування змін перед розширенням обсягу роботи. Записуйте час виконання та витрати на токени або запити поруч із функціональними результатами. Відображення витрат на ранньому етапі запобігає несподіваним рахункам під час переходу від демо-версії до спільних середовищ.

1. Надайте агенту правильний контекст, а не більше контексту

На етапі 1 «Надати агенту» необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись визначити прихований стан. Конфігурацію слід тримати окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код. Встановлюйте людське схвалення для дій, які призводять до витрат грошей чи змінюють дані у продакшені. Підключення на етапі компіляції не є гарантією повноти бізнес-функціоналу.

User Question
      ↓
Query Embedding
      ↓
Vector Search
      ↓
Top-K Results
      ↓
Reranking
      ↓
Relevant Chunks
      ↓
LLM
      ↓
Final Answer

2. Дебагування перед зміною LLM

Для етапу «2 Debug Retrieval Before» необхідно визначити вхідні дані, відповідальну особу за крок та критерії завершення ще до змін у коді. Оператори мають мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Необхідно документувати як успішний, так і відновлювальний сценарії роботи. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації. У разі, коли наступним кроком є код або виклик інструменту, краще використовувати структуровані результати з перевіркою схеми, ніж вільний текст.

Question
   ↓
Query Transformation
   ↓
Retrieved Documents
   ↓
Similarity Scores
   ↓
Reranking
   ↓
Final Context
   ↓
Prompt
   ↓
LLM Response

results = vector_store.similarity_search(
    query=user_question,
    k=5
)

for result in results:
    print("Score:", result.score)
    print("Source:", result.metadata.get("source"))
    print("Content:", result.page_content[:500])

3. Покращити розділення на частини перед збільшенням обсягу контексту

На етапі „3. Покращити розділення на частини“ необхідно визначити вхідні дані, відповідальну особу за крок та критерії завершення перед зміною коду. Оператори повинні мати можливість знову виконати крок з відомої точки контролю, не намагаючись вгадати прихований стан. Краще використовувати невеликі, перевірювані одиниці коду замість об’ємних скриптів. Коли крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану структуру процесу. Встановлюйте людське схвалення для операцій, які призводять до витрат грошей чи змінюють дані у продакшені. Підключення елементів під час компіляції не є гарантією повноти бізнес-функціоналу. На етапі „3. Покращити розділення на частини“ необхідно визначити вхідні дані, відповідальну особу за крок та критерії завершення перед зміною коду. Оператори повинні мати можливість знову виконати крок з відомої точки контролю, не намагаючись вгадати прихований стан. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Відображення витрат на ранньому етапі запобігає несподіваним рахункам під час переходу від демо-версії до спільного середовища.

Коментарі.

Chunk 1:
Employees are eligible for reimbursement when...

Chunk 2:
...the expense was approved by their manager and
submitted within 30 days.

4. Не надсилайте всю розмову моделі

Під час виконання етапу «Не надсилайте» спочатку запишіть умови використання: необхідні дані вхіду, сигнал про успіх та наслідки часткової невдачі. Цей перелік допомагає зберігати чесність у подальших змінах коду. Зберігайте конфігурацію окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, яке оператори можуть перевіряти, не читаючи весь код. Зберігайте у кеші стабільні інструкції системи та схеми інструментів. Повторне надсилання однакового вступного тексту є поширеною причиною надмірних витрат.

Conversation Context

Recent Messages:
- User asked about refund eligibility.
- Agent explained the standard policy.
- User mentioned they purchased an annual plan.

Conversation Summary:
Customer purchased an annual subscription
and wants to know whether they qualify for a refund.

Current Question:
Can I still get a refund?

5. Розділяйте інструкції системи, контекст та дані вхіду користувача

Під час виконання 5 етапів інструкцій окремої системи спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Одночасно задокументуйте шлях успішного виконання та шлях відновлення. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої доробки. Робіть контрольні пункти після дорогих кроків. Система відновлення не повинна знову стягувати плату за той самий виклик LLM, коли оператор намагається знову виконати пізнішу операцію.

SYSTEM INSTRUCTIONS

You are a customer support agent.
Answer using the provided knowledge.
Do not invent company policies.
If the answer isn't available, say that you don't know.
KNOWLEDGE
<retrieved_documents>
USER QUESTION
<user_question>

6. Навчіть агента, коли йому слід сказати „ви не знаєте“

Під час виконання 6 етапів «Навчання агента» спочатку запишіть умови взаємодії: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність подальших змін у коді. Віддавайте перевагу невеликим, тестованим одиницям коду перед об’ємними скриптами. Якщо якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на складну послідовність операцій. Робіть контрольні пункти після дорогих кроків. Система відновлення не повинна знову стягувати плату за один і той самий виклик LLM, коли оператор намагається знову виконати пізніший етап. Під час виконання 6 етапів «Навчання агента» спочатку запишіть умови взаємодії: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність подальших змін у коді. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам, коли процес переходить від демо-режиму до спільних середовищ.

If the answer cannot be supported by the provided
knowledge, do not guess.

Clearly state that the information is unavailable.

7. Не включайте бізнес-логіку до запиту

Етап „7. Не включайте бізнес-логіку“ найкраще функціонує, якщо його розглядати як вимірювану поверхню. Запишіть один ідеальний запис виконання, один випадок збою та примітки щодо скасування змін перед розширенням обсягу роботи. Тримайте конфігурацію окремо від коду програми. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код. Встановіть ліміти на кількість токенів за раунд та сесію. Інструменти типу агентів активно розширюють контекст; жорсткі обмеження запобігають тому, що демонстрації перетворюються на несподівані рахунки.

def check_refund_eligibility(customer, purchase):
    if not customer.is_premium:
        return False

if customer.account_age_years < 2:
        return False
    if purchase.days_since_purchase > 30:
        return False
    if customer.previous_refund:
        return False
    return True

LLM
→ Understands the request
→ Decides which tool to use
→ Explains the result

Application
→ Enforces business rules
→ Validates data
→ Performs deterministic operations

8. Визначте чіткі обов’язки інструментів

Інструменти типу Clear stage найкраще функціонують, якщо їх розглядати як вимірювану поверхню. Збережіть один ідеальний приклад виконання, один випадок збою та запис про скасування дій перед розширенням обсягу роботи. Документуйте як успішний, так і відновлювальний сценарії роботи. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації. Розкривайте інструменти з вузькими схемами та чіткими позначеннями побічних ефектів. Хостам потрібно знати, які виклики змінюють стан, перш ніж вони автоматично схвалюють дії.

process_customer_data()

get_customer_order()
cancel_customer_order()
update_customer_address()
create_support_ticket()

9. Перевіряйте результати роботи агента

Принцип „9 Validate“: етап працює найкраще, коли його розглядають як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку щодо скасування змін перед розширенням обсягу роботи. Віддавайте перевагу невеликим, тестованим одиницям перед складними скриптами. Коли якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність дій. Зберігайте стан графа у простому та типованому вигляді. Вкладені структури приховують інформацію про те, який вузол заповнив яке поле, що ускладнює продовження роботи після перерв. Принцип „9 Validate“: етап працює найкраще, коли його розглядають як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку щодо скасування змін перед розширенням обсягу роботи. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам під час переходу від демо-версії до спільних середовищ.

User
 ↓
LLM
 ↓
Refund API

User
 ↓
LLM
 ↓
Tool Request
 ↓
Application Validation
 ↓
Business Rules
 ↓
Refund API

{
  "customer_id": "12345",
  "eligible": true,
  "reason": "Purchase is within the refund window"
}

10. Не додавайте кілька агентів без реальної причини

На етапі «Не додавайте» необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не здогадуючись про прихований стан. Зберігайте конфігурацію поза кодом додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, яке оператори можуть перевірити, не читаючи весь граф. Встановіть людське схвалення для дій, які спричиняють витрати грошей або змінюють дані в продакшені. Підключення на етапі компіляції не є гарантією повноти бізнес-функціоналу.

                    User
                     ↓
                Router Agent
                /     |     \
               ↓      ↓      ↓
             RAG     SQL     API
               \      |      /
                \     |     /
                 Final Agent
                     ↓
                  Response

11. Створіть набір даних для оцінки на основі реальних запитань

На етапі 11 «Створення оцінки» необхідно визначити вхідні дані, відповідальну особу за крок та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Необхідно документувати як шлях успішного виконання, так і шлях відновлення. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації. Необхідно встановити людське схвалення для операцій, які призводять до витрат грошей чи змінюють дані у продакшені. Підключення на етапі компіляції не є гарантією повності функціоналу продукту.

Easy questions
Ambiguous questions
Multi-step questions
Out-of-domain questions
No-answer questions
Tool-use questions
Adversarial questions

12. Відстежуйте весь робочий процес агента

Для етапу „12 Trace the Entire“ необхідно визначити вхідні дані, відповідальну особу за крок та критерії завершення перед зміною коду. Оператори повинні мати можливість знову виконати крок з відомої точки контролю, не намагаючись вгадати прихований стан. Краще використовувати невеликі, перевірювані одиниці коду замість об’ємних скриптів. Коли крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на складну структуру процесу. Встановлюйте людське схвалення для операцій, які призводять до витрат грошей чи змінюють дані у продакшені. Підключення елементів під час компіляції не є гарантією повноти бізнес-функціоналу. Для етапу „12 Trace the Entire“ необхідно визначити вхідні дані, відповідальну особу за крок та критерії завершення перед зміною коду. Оператори повинні мати можливість знову виконати крок з відомої точки контролю, не намагаючись вгадати прихований стан. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Відображення витрат на ранньому етапі запобігає несподіваним рахункам під час переходу від демо-середовищ до спільних середовищ.

Request ID
    ↓
User Question
    ↓
Query Transformation
    ↓
Retrieved Documents
    ↓
Reranking Results
    ↓
Prompt Version
    ↓
Model
    ↓
Tool Calls
    ↓
Tool Responses
    ↓
Final Response
    ↓
Validation

13. Не оптимізуйте лише заради точності

Під час виконання етапу «13. Не оптимізуйте» спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допоможе зберегти чесність подальших змін у коді. Тримайте конфігурацію окремо від коду додатку. Файли середовища, сховища секретних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код. Робіть контрольні точки після дорогих операцій. Функція відновлення не повинна знову стягувати плату за один і той самий виклик LLM, коли оператор перезапускає пізнішу ланку.

Response Quality
      +
Reliability
      +
Latency
      +
Cost
      +
User Experience

Заключні міркування

Під час роботи над етапом „Заключні міркування“ спочатку запишіть умови виконання: необхідні дані вхіду, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді.

Перелік операційних кроків

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

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

Пункт перевірки після дорогих кроків. Функція відновлення не повинна знову стягувати плату за той самий виклик LLM, коли оператор намагається знову виконати пізніший етап.

Забезпечте фіксацію версій залежностей та зафіксуйте дайджест зображення, яке використовувалося під час демонстрації. Відтворюваність краща за індивідуальні знання.

Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам під час переходу від демонстрації до спільних середовищ.

Пункт перевірки після дорогих кроків. Функція відновлення не повинна знову стягувати плату за той самий виклик LLM, коли оператор намагається знову виконати пізніший етап.

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

Примітка до пакету 1481fc99429e: не включайте ключі постачальників у репозиторій, встановіть ліміт токенів на сеанс та зберігайте транскрипції поруч із фіксами для оцінки, щоб подальша заміна моделей залишалася порівнянною.