Зміст
Коротко
Один виклик великої мовної моделі здається дешевшим за ланцюжок із п’яти чи десяти. Але для підтримки та внутрішніх баз знань важлива не ціна окремого звернення до LLM, а ціна вирішеного питання: разом з уточненнями користувача, очікуванням і підключенням фахівця.
Автор розбирає випадок, коли агент ШІ робить кілька самостійних кроків пошуку, але зрештою обходиться дешевше за звичайний RAG. RAG — це підхід, за якого модель отримує знайдені фрагменти бази знань до формування відповіді.
Що сталося
Простий помічник зазвичай рухається прямою схемою: перетворює питання на векторне подання, знаходить відповідні фрагменти та просить LLM скласти відповідь. Це добре працює, коли рішення міститься в одному документі. Складне звернення часто вимагає зіставити нотатки до версії, інструкцію з перенесення налаштувань і точний текст помилки.
Якщо перша відповідь неповна, частину пошуку виконує користувач: уточнює запит, інакше описує симптом та чекає нового результату. Після кількох невдалих спроб звернення переходить оператору. Кожен виклик моделі міг бути недорогим, проте питання весь цей час залишалося відкритим.
У описаному проєкті агент сам обирає наступний спосіб пошуку. Він може шукати за змістом, перевірити точний термін, відкрити знайдений уривок документа й лише тоді сформувати відповідь із посиланнями. Викликів LLM більшає, зате користувачеві не треба спрямовувати пошук повторними уточненнями.
Чому це важливо
Автор пропонує рахувати повну вартість закритого питання. До неї входять токени, час користувача, частка переданих оператору звернень і час фахівця. Додаткова робота моделі може бути виправданою, якщо вона суттєво зменшує кількість випадків, де потрібна людина.
Приклад у статті стосується помилки після оновлення продукту. Звичайний помічник кілька разів радить перевірити загальні налаштування пошти та лише після уточнень знаходить перейменоване поле. Агент помічає зв’язок із нотатками до версії, відкриває їх, шукає нову назву поля й знаходить інструкцію з оновлення відповідностей.
Це не означає, що багатокроковий пошук потрібен завжди. На запит на кшталт «який порт використовує сервіс» проста відповідь буде швидшою та дешевшою. Агент корисний там, де відповідь складається з кількох джерел або слід перевірити кілька правдоподібних причин.
На практиці
Важливий не лише набір засобів пошуку, а й обмеження для агента. Йому потрібно вчасно зупиняти безрезультатні спроби, зберігати початкове питання та не заповнювати контекст результатами кожного проміжного кроку. В описаній системі постійне стискання історії моделлю було дорогим і часом втрачало важливі подробиці.
Замість цього застосували ковзне вікно контексту. Системна інструкція та останні повідомлення зберігаються, а старі результати пошуку прибираються після досягнення ліміту. Стискання лишається резервним механізмом з обмеженою кількістю запусків. Такий підхід менш витончений, але передбачуваніший для робочої підтримки.
- Відокремте точний пошук від пошуку за змістом: код помилки й назву поля зручніше шукати рядком, а загальну проблему — за семантичною близькістю.
- Використовуйте різні класи моделей для легких кроків, підсумкової відповіді та побудови векторних подань.
- Записуйте для кожного звернення виклики, токени, результати інструментів, час до відповіді та передавання оператору.
- Окремо перевіряйте прості, складні й невизначені питання: один режим не мусить бути найкращим для всіх.
- Оцінюйте частку звернень, вирішених з першої відповіді, а не лише кількість викликів моделі.
Підсумок
Агент ШІ не скасовує прості RAG-помічники. Для коротких довідкових запитів додаткове міркування збільшує і затримку, і витрати токенів. Він також не виправить порожню або застарілу базу знань: повторний пошук не створить інформації, якої в ній немає.
У підтримці зі складними симптомами вартість однієї відповіді — хибна метрика. Система, що сама знаходить причину, інструкцію з виправлення та підтвердні документи, заощаджує час користувачів і операторів разом із токенами. Порівнювати такі рішення варто за вартістю закритого звернення та часткою справді розв’язаних задач.