Де конвеєри RAG діють сліпо: визначення невдач через патерни агентності
Дізнайтеся, яка схема агентного RAG підходить для кожної проблеми — від переписування запитів та коригувальних заходів до маршрутизації, оцінки відповідей, людського перегляду, керівництва та планування.
Джерела: Your RAG Pipeline Doesn’t Need More Retrieval, It Needs Better Decisions
Стандартний алгоритм генерації з підтримкою пошуку — це проста послідовність дій: пошук, генерація, відповідь. Це підходить для демонстрацій, але запити в реальних умовах швидко виявляють його слабкі місця. Механізм пошуку повертає нерелевантні фрагменти, користувач формулює запит так, як це ніколи не робилося у ваших документах, відповідь зовсім відсутня в індексі, або модель пише щось, чого насправді не підтримує отриманий текст. Додавання більшої кількості документів у запит не вирішує жодної з цих проблем, адже причина не в кількості контексту, а у відсутності рішення щодо подальших дій.
Саме цей шар прийняття рішень і мається на увазі під агентним підходом RAG. У цьому посібнику він розглядається як набір цілеспрямованих відповідей на конкретні сценарії збоїв, а не як єдина архітектура, щоб ви могли проаналізувати свою власну систему, знайти етап, де вона наразі діє сліпо, та обрати найпростіший підхід для вирішення проблеми.
Чому одноразовий підхід не функціонує
Традиційний додаток типу RAG виконує фіксовану послідовність дій. Він бере запит, проводить пошук схожостей у векторній базі даних, зберігає найкращі результати, передає їх моделі LLM та повертає отриману відповідь. Прихованою передумовою є те, що крок пошуку пройшов успішно.
Коли ця передумова не справджується, ніщо в цьому процесі не помічає цього:
- Низькоякісні документи все одно передаються моделі, і вона намагається дати відповідь на їх основі.
- Запит із словниковим запасом, який не збігається з документами, повертає мало корисної інформації.
- Якщо в базі знань просто немає відповіді, у системи немає альтернативного шляху.
Корисно змінити підхід: перестати запитувати лише про те, як покращити процес пошуку інформації, та почати цікавитися тим, що має робити система, коли якість пошуку недостатня. Кожен з наведених нижче прикладів є відповіддю на одну з версій цього другого запитання. Якщо ви хочете отримати більш широке порівняння архітектур пошуку перед тим, як розглядати окремі приклади, перегляньте RAG vs agentic RAG vs graph RAG.
Оцінка якості пошуку та переписування запиту
Візьмемо таке запитання, як «Як LangGraph вирішує проблему збереження даних?». Припустимо, система пошуку повертає п’ять фрагментів, і лише один з них є релевантним. Лінійний підхід передає всі п’ять фрагментів моделі, яка потім мусить їх сортувати, що зменшує корисність отриманих даних та спричиняє плутанину.
У робочому процесі з використанням агентів спочатку вводиться крок оцінки. Оцінювач, яким часто є невеликий запит до LLM із шкалою «так/ні», визначає, чи є отримані документи достатньо релевантними для відповіді на запитання. Якщо ні, процес не просто знову шукає за тим самим текстом. Він генерує покращений запит, ґрунтуючись на результатах першої спроби, та знову проводить пошук. Отриманий цикл виглядає так:
- отримання даних
- оцінка результатів
- переписування запиту, якщо результати недостатні
- знову отримання даних
Сам цикл не є найціннішою частиною. Важливо те, що система може розпізнати, що її перша спроба була недостатньою. На практиці також потрібна умова зупинки, наприклад максимальна кількість переписувань, щоб запитання, на яке індекс не може відповісти, не циклювалося безкінечно.
Перехід на альтернативний варіант, коли у індексу немає відповіді
Переписування допомагає лише тоді, коли інформація існує десь у вашому корпусі даних. Часто її там немає. Уявіть асистента, створеного на основі документації, зібраної місяць тому, і користувача, який запитує про функцію, оголошену вчора. Жодні спроби перефразування не допоможуть знайти документ, який ніколи не був індексований.
Коригувальний підхід RAG вирішує цю проблему. Після оцінки знайдених документів робочий процес розглядає недостатній результат як сигнал до корекції курсу, наприклад, шляхом пошуку в іншому джерелі, такому як веб-пошук. Лінійний ланцюг «знаходження — генерація» перетворюється на:
- знаходження
- оцінка документів
- корекція, якщо оцінка низька
- генерація
Поняття „правильного“ навмисно залишено широким. Залежно від ситуації це може означати переписування запиту, звернення до іншого джерела чи виконання якоїсь іншої дії. Ключовою рисою є те, що невдалий пошук спонукає до використання іншого шляху, а не до недостатньої відповіді. Пам’ятайте, що додавання резервного веб-джерела змінює вашу модель довіри: контент публічного вебу менш ретельно опрацьований, ніж ваша власна документація, тому можливо, вам варто позначати чи фільтрувати відповіді, які ґрунтуються на ньому.
Направлення кожного запиту до правильного джерела
Ще однією прихованою передумовою базових систем RAG є те, що кожен запит має потрапляти до одного й того ж засобу пошуку. Багато реальних систем мають кілька джерел знань одночасно: внутрішню корпоративну документацію, публічну документацію до продукту, один або кілька векторних сховищ та пошук у живому інтернеті.
Ці джерела не є взаємозамінними. На запитання щодо внутрішньої політики кадрів не слід відповідати з відкритого Інтернету. На запитання щодо версії бібліотеки, випущеної минулого тижня, не слід покладатися виключно на сховище векторів, створене до цього випуску.
Адаптивний RAG додає рішення щодо маршрутизації на початку. Перш ніж отримувати будь-яку інформацію, система класифікує запитання та визначає, яке джерело найкраще підходить для його відповіді, а потім оцінює контекст, який надходить з цього джерела. Шлях отримання інформації обирається окремо для кожного запитання, а не є фіксованим для всіх. Маршрутизатор може бути настільки простим, як запит на класифікацію чи набір правил; йому не обов’язково бути складним, щоб усунути всю категорію неправильних відповідей з невірних джерел.
Перевірка відповіді, а не лише документів
Більш тонку проблему легко пропустити: відмінне пошукове функціонування не гарантує хорошої відповіді. Модель може отримати саме правильні уривки тексту, але все одно створити відповідь, яка виходить за їхні межі або відхиляється від поставленого запитання.
Рішенням є також оцінювати результат. Після генерації агентний робочий процес може поставити такі запитання:
- Чи кожне твердження в відповіді ґрунтується на знайденому контексті?
- Чи відповідь стосується того, про що насправді запитав користувач?
- Чи додала модель інформацію, яку не підтримує контекст?
Якщо відповідь є некоректною, робочий процес може її виправити або створити заново. Це дає можливість провести два окремі перевірки, які варто тримати роздільними: чи була отримана правильна інформація та чи вона була використана належним чином. Розділення цих етапів також значно полегшує виправлення помилок, адже причину невдачі можна приписати етапу отримання даних або етапу їх генерації, замість того щоб просто казати «бот помилився». Стаття на оцінка RAG за етапами невдач детальніше розглядає цю ідею.
Зупинка для рішення людини
Деякі результати не повинні вирішуватися автоматично. Типові причини для людського перегляду включають:
- докази, які є неоднозначними або суперечливими
- відповіді, які потребують формального схвалення перед використанням
- низький рівень впевненості з боку власних оцінювачів системи
Модель RAG із участю людини встановлює контрольну точку у робочому процесі, де хтось може схвалити результат, відхилити його або внести зміни перед продовженням виконання. Це не відступ від автоматизації. Система все ще самостійно обробляє типові випадки та передає на розгляд лише ті, які справді потребують оцінки, що зазвичай є набагато кращим використанням часу перевіряючих, ніж перевірка всього або нічого. Фреймворки оркестрації на основі графів, такі як LangGraph, ідеально підходять для цього, оскільки вони можуть зберігати стан робочого процесу на контрольній точці та продовжити роботу після того, як людина надасть відповідь.
Розподіл роботи між спеціалізованими агентами
У міру зростання обсягу роботи стає складно керувати одним агентом, який бере на себе всю відповідальність, та ефективно формулювати для нього завдання. Деякі проблеми природним чином розділяються на окремі функції: пошук інформації, дослідження, оцінка тощо.
У конфігурації з кількома агентами та керівником один агент відповідає за координацію. Керівник вирішує, який спеціаліст має виконати наступний крок, а спеціалісти виконують окремі, вузькоспрямовані завдання. Мета не в тому, щоб додавати агентів просто так; кожен додатковий агент збільшує затримки, витрати та потребу у додаткових інструкціях. Це має сенс, коли проблема дійсно вимагає кількох кроків чи спеціалізованих підходів, а інструкції для одного агента перетворюються на некерований список окремих випадків.
Паралельна робота незалежних механізмів пошуку
Не кожен крок мусить чекати на попередній. Якщо для відповіді потрібна інформація з кількох незалежних джерел, то запитування їх по черзі — спочатку джерело А, потім B, потім C, а вже після цього формування відповіді — є марною тратою часу.
Модель паралельного розгортання виконує ці запити одночасно: запит посилається до A, B та C одночасно, а їхні результати об’єднуються перед створенням відповіді. Незалежні завдання з пошуку чи обробки виконуються паралельно та поєднуються наприкінці. Це може зробити складні робочі процеси як швидшими, так і простішими у структуруванні, оскільки кожна гілка є самодостатньою. Однак це має свою ціну: на етапі об’єднання необхідно керувати перекриваючимися чи суперечливими результатами, а також вирішувати, що робити, якщо одна з гілок зазнає невдачі чи досягає таймауту.
Планування перед виконанням
Деякі запитання взагалі неможливо відповісти за допомогою одного лише пошуку. Для їх вирішення потрібні кілька пошуків, проміжні перетворення чи етапи міркувань, порядок яких має значення.
Метод Plan-and-execute RAG вирішує цю проблему, розділяючи процес міркувань та виконання завдання. Послідовність дій є такою:
- отримання запитання
- створення плану
- виконання запланованих кроків
- оцінка результатів
- надання відповіді
Планувальник визначає, що потрібно зробити; виконання опікується окремими кроками. Це найбільш корисно для багатоетапних запитань, таких як порівняння кількох документів, адже безпосереднє використання інструментів часто призводить до поверхневих чи неповних відповідей. План також дозволяє перевірити, що сталося у разі проблем під час виконання, що складніше з агентом, який імпровізує кожен крок.
Що насправді робить систему RAG агентною
Виклик LLM чи називання чогось агентом саме по собі не робить систему агентською. Ключовою властивістю є здатність системи оцінити свою ситуацію та обрати наступний крок. Фіксована схема передбачає спочатку отримання інформації, а потім відповідь. Агентська система може поставити собі низку запитань:
- Чи потрібне взагалі отримання інформації для цього запитання?
- Чи була отримана інформація справді корисною?
- Чи варто шукати знову за іншим запитом?
- Чи підійде краще інше джерело?
- Чи підтверджується відповідь доказами?
- Чи потрібно втручання людини?
- Чи варто передати обов’язки іншому, спеціалізованому агенту?
- Чи принесе кращий результат попереднє планування дій?
Кожне запитання відповідає одному з наведених вище шаблонів, тому корисно розглядати агентний RAG як набір інструментів для прийняття рішень, а не як єдину монолітичну структуру. Ці шаблони природно відповідають принципам оркестрації графів: оцінювання та маршрутизація стають умовними ребрами, цикли — циклами з лічильником у стані, людський огляд — перериванням, а розгалуження — паралельними гілками, які з’єднуються.
Підберіть шаблон до типу збою
Жоден додаток не потребує всіх цих шаблонів, і кожен з них додає затримку, витрати та елементи, які потребують обслуговування. Вибирайте відповідно до того збою, який ви фактично спостерігаєте:
- Якщо основною проблемою є якість отримання інформації, може вистачити переписування запиту з використанням оцінювача релевантності.
- Якщо в базі знань є прогалини, додайте резервний джерело інформації.
- Якщо ви використовуєте кілька джерел знань, додайте механізм маршрутизації.
- Якщо деякі рішення потребують контролю, додайте людський етап перевірки.
Підсумок
Питання, яке призводить до корисних покращень, полягає не у тому, як зробити систему RAG більш автономною, а у тому, де система наразі діє сліпо: надсилає документи, які ніхто не перевірив, шукає у неправильних джерелах, довіряє безпідставним відповідям чи ухвалює рішення, яке має приймати людина. Оптимізуйте процес, щоб бачити, які з цих проблем трапляються найчастіше, додайте найпростіший етап прийняття рішень для вирішення найпоширенішої проблеми, а потім знову проведіть оцінку перед додаванням наступного елемента.