Виправляйте проблеми в конвеєрі обробки даних, а не у LLM: продуктивна модель мислення для усунення несправностей у системах RAG.
Коли бот RAG дає неправильну відповідь, причиною рідко є LLM. Відстежуйте проблеми на етапах отримання даних, пошуку, генерації, оцінки та повторного оброблення, щоб знайти проблемну ланку.
Джерела: RAG Is Not Just Vector Search
Уявіть собі бота підтримки у середній компанії з програмного забезпечення на підписці, який одного дня по-різному відповідає двом клієнтам, коли обидва запитують про терміни повернення грошей.
Відкривається інцидент, і першою думкою інженера, який працює у режимі чергування, є те, що ШІ створює хибні дані, тож потрібна інша модель. Це початковий діагноз; при цьому RAG розглядається як „чорна скринька“, модель замінюється, і сподіваються, що симптоми зникнуть.
Досвідчений інженер починає з іншого підходу та запитує, на якому етапі процесу виникла проблема. Твердження про те, що модель створює хибні назви, є лише симптомом та нічого не пояснює.
Через два дні з’являється справжня проблема. Політика повернення грошей була змінена, проте ніхто не видалив застарілий PDF з корпусу даних, тож обидві версії продовжували з’являтися з схожими оцінками релевантності, а модель вірно узагальнювала суперечливий контекст. Вона зовсім не уявляла того, що не існує. (Це складений сценарій для ілюстрації, але його варіанти є поширеними.)
Ось різниця між типовою версією RAG та тим, як він функціонує в реальних умовах. У навчальних матеріалах це зазвичай стискається до одного рядка:
Embed → Search → Generate
Цього достатньо для демонстрації, але недостатньо для реального використання. Справжня система має кілька меж несправностей. Важливе інженерне питання полягає не лише у тому, чи може LLM написати хорошу відповідь, а й у тому, чи кожен шар, який формує цю відповідь, працює належним чином.
Прийом даних: якість визначається ще до початку пошуку
Більшість спроб виправлення проблем у RAG починаються з неправильного кроку. Люди налаштовують запити, змінюють моделі ембеддингу та коригують параметри top-k, тоді як справжня проблема виникла ще кілька тижнів тому під час прийому даних.
Аналіз за структурою
Таблиці, блоки коду, заголовки та списки передають значення через свою структуру. Якщо перетворити таблицю з цінами на звичайний текст, зв’язок між рядком та його заголовком може зникнути. Канал прийому даних має зберігати цю структуру та обирати формат, придатний для пошуку, а не розглядати кожен документ як єдиний нерозрізнений блок тексту.
Правильний підхід залежить від змісту. Для таблиць може знадобитися структуроване вилучення даних, серіалізація тексту, метадані або поєднання лексичного та семантичного пошуку.
Часткове розділення за сенсом
Простий метод полягає у розділенні тексту на частини кожні 512 токенів. Однак кількість токенів та сенс не завжди збігаються, тож одна частина може починатися з вступу та закінчуватися ще до досягнення основної ідеї.
Семантичне розділення передбачає розбій на частини на місцях зміни теми, а не за кількістю токенів. Це не є універсальним покращенням, і воно збільшує витрати під час обробки даних. У довгих документах, таких як політики, контракти та технічна документація, збереження цілісності ідей часто покращує результати пошуку.
Надайте кожній частині певний контекст перед вставкою
Фрагмент, взятий зі сторінки 40 60-сторінкового документа, може бути абсолютно коректним текстом, проте залишатися неоднозначним поза своїм контекстом. Візьмемо речення, у якому зазначено, що певний ліміт стосується лише клієнтів категорії Enterprise. Без сусіднього розділу ніщо не підкаже системі, на що саме посилається „цей ліміт“.
Контекстуальне пошукове забезпечення вирішує цю проблему, додаючи перед фрагментом контекст на рівні документа: назву, шлях до розділу, продукт, версію чи коротку автоматично створену примітку про місце розташування фрагмента. Мета полягає у тому, щоб кожен фрагмент зберігав контекст, який інакше було б втрачено внаслідок його розділення.
Додавання метаданих
Розглядайте метадані як функціональні дані. У наступних кроках потрібні джерело, дата, тип документа, користувач, дозволи та версія для фільтрації, контролю доступу, перевірки актуальності та виправлення помилок.
Це піднімає одне з найважливіших питань щодо обробки даних під час їх надходження: що станеться, якщо джерельний документ зміниться завтра? Якщо процес може лише переіндексувати все, навіть незначна зміна контенту перетворюється на операційне навантаження. Ідеально, щоб процес надходження даних був інкрементальним та ідемпотентним, щоб оновлення виявлялися, оброблялися та поширювалися без необхідності повторної створення всього корпусу даних.
У описаній вище ситуації стара політика повернення грошей ніколи не була проблемою ШІ — причина крилася у способі керування процесом надходження даних та самим корпусом.
Отримання даних — це процес, а не просте пошук
Це слово натякає на один крок. Насправді ж отримання даних — це ланцюг рішень, і послідовність цих рішень має наслідки.
1. Переписати
Люди не пишуть пошукові запити спонтанно. Вони запитують щось на кшталт того, чи вже відправлено гроші назад. Штучний інтелект може перетворити такий запит на більш корисний для пошуку, можливо, включивши історію розмови або розділивши складне запитання на менші. Однак переписування запитів — це не безкоштовно: поганий варіант переписування може призвести до втрати ключових деталей або додавання неправильних припущень. Сприймайте це як ще один елемент для оцінки, а не як чудо.
2. Обсяг пошуку
Це одна з найважливіших деталей експлуатації. Якщо система є багатокористувацькою або враховує права доступу, простір пошуку має дотримуватися цих меж. Інформація про користувачів, права доступу, видимість, дату та джерело має враховуватися під час процедури пошуку там, де це дозволяє базова система.
Фільтрація після використання критерію top-k створює дві проблеми. По-перше, корисні документи можуть вже бути видалені з списку top-k через документи, які користувачеві не дозволено бачити. По-друге, логіка авторизації опиняється небезпечно відокремленою від процесу пошуку. Простіше кажучи, не слід шукати все, а потім запитувати, що може бачити користувач. Спочатку необхідно звузити область пошуку.
3. Пошук двома способами
Щільний векторний пошук добре справляється з визначенням семантичної близькості. Запит про те, як скасувати щось, може бути співставлений із текстом про те, що клієнти можуть припинити користування послугою у будь-який час, незважаючи на відсутність спільних слів.
Однак ембеддинги менш ефективні з точними ідентифікаторами. Уявіть собі такі рядки:
ERR_CONNECTION_RESET
SKU-48392
API-v3-beta
Для таких запитів літеральний токен є сигналом, і саме тут знаходить застосування лексичний пошук, такий як BM25. У продакшн-середовищах пошук часто поєднує щільний пошук за змістом із лексичним пошуком за точними рядками.
4. Об’єднання
Тепер існують два списки з рангуванням. У щільного пошуку є власне порядкування, у BM25 — своє, і їхні первинні оцінки не завжди піддаються порівнянню. Метод взаємного об’єднання рангів (RRF) пропонує простий спосіб їх об’єднати за допомогою позиції в рангуванні:
RRF_score(d) = Σ 1 / (k + rank_i(d))
Кожен список вносить свій внесок залежно від того, де знаходиться документ у ньому, що дозволяє уникнути необхідності калібрування розподілів оцінок двох незалежних систем одна від одної.
5. Переурочування рангів
Фузія дає набір кандидатів, але не обов’язково кінцевий контекст. Крос-енкодер-переурочувач читає запит та кожного кандидата разом та створює оцінку релевантності для цієї конкретної пари. Це принципово відрізняється від окремого вкладення запиту та документа та порівняння векторів.
Витратою є обчислювальні ресурси, тому крос-енкодер не використовується для обробки всього корпусу. Механізм пошуку може повернути топ-20 або 50 кандидатів, а переурочувач обирає найкращий контекст серед них.
Отже, модель мислення під час роботи полягає у спочатку інтенсивному пошуку, потім лексичному пошуку, далі фузії та нарешті переурочуванні рангів. Це не просто „база даних векторів – і все“.
Генерація: хороший контекст все ще не гарантує хорошої відповіді
Знаходження правильних документів є необхідним, але недостатнім. Штучний інтелект все одно має правильно ними скористатися.
Керування вікном контексту
Більше контексту не завжди призводить до кращої відповіді. Моделі не однаково використовують довгий контекст. Дослідження показали, що інформація, розташована посеред довгого контексту, може бути запам’ятана менш надійно, ніж інформація біля початку чи кінця. Тому включення перших 20 фрагментів у запит може погіршити якість відповіді. Метою є максимально корисний контекст, а не максимальний обсяг контексту.
Межі запиту та атрибуція
У запиті чітко вкажіть, як слід використовувати знайдені уривки. Модель має розглядати їх як докази для цитування, а не як інструкції для виконання.
Цитування також допомагають зміцнити довіру та виправляти помилки. Коли у відповіді зазначається, що клієнти Enterprise мають 30 днів на скасування, потрібен спосіб прив’язати це твердження до відповідного джерела.
Утримання від відповіді
Утримання від відповіді позначає суттєву різницю між демо-версією та надійною системою. Якщо пошук не дає результатів, модель все одно намагатиметься допомогти, якщо тільки відмова не є допустимим результатом. Система для продакшну має мати можливість відповісти, що доказів недостатньо. Це часто є правильним рішенням, а не дефектом.
Без утримання від відповіді кожна невдача пошуку може перетворитися на хибну інформацію. Штучний інтелект бере на себе вину за неправильну відповідь, хоча справжня проблема могла виникнути кілька рівнів раніше.
Оцінка перед будь-яким виправленням
RAG має незручну властивість: якість може погіршуватися, навіть якщо код додатку залишається недоторканим. Нова модель вбудовування, інший метод розбиття на частини, додані чи видалені документи, скориговані налаштування пошуку чи змінений запит можуть кожен змінити відповіді, навіть якщо код, розгорнутий вчора, є ідентичним байт за байтом. Тому системи RAG у продакшені слід оцінювати на кількох рівнях.
Якість пошуку. Точність контексту визначає, наскільки відібраний контекст був релевантним. Відтворюваність контексту визначає, наскільки з усієї наявної релевантної інформації система пошуку дійсно знайшла її. Разом вони дозволяють розрізнити ситуації „ми його ніколи не знаходили“ та „ми його знайшли, але загубили серед шуму“.
Якість генерації. Перевірка вірності (також називана обґрунтованістю) переконується, що відповідь випливає з отриманих доказів, а перевірка точності цитування переконується, що зазначені джерела підтримують кожне твердження. Добре написана відповідь все одно може бути безпідставною.
Стан системи. Важливими є також оперативні показники: затримка p95, витрати на один запит та кількість відмов. Це не лише проблеми інфраструктури. Якщо затримка подвоюється через те, що агент починає виконувати кілька циклів пошуку, це є частиною якості системи. Раптове зростання кількості відмов може означати погіршення процесу пошуку. Підвищення витрат на один запит може свідчити про те, що зміна, яка здавалася безневинною, призвела до використання дорогого шляху.
Розділення показників вимірювань сприяє точнішій діагностиці. Здорове значення зі зниженням рівня прив’язаності вказує на генерацію результатів. Зниження точності вказує на процеси інгестування, фільтрації, пошуку чи ранжування. Якщо ви відстежуєте лише загальну якість відповідей, кожна регресія виглядає однаковою та не дає підстав для дій.
Від потоку обробки до циклу зворотного зв’язку
Основний потік обробки залишається простим:
Ingestion → Retrieval → Generation → Evaluation
Багато систем не потребують нічого більше. Одна добре індексована база знань та чіткі запитання рідко вимагають, щоб агент обирав наступний крок. Однак існують й складніші запитання.
Візьмемо запит на порівняння показників доходу за другий квартал із даними, наведеними у презентації для правління, а потім пояснення різниці. Для відповіді можуть знадобитися цифри за Q2, презентація правління, відповідні розділи кожної з них, порівняння, а можливо, й запит до іншого джерела даних. Однієї процедури пошуку може виявитися недостатньо, і саме тут стає корисним агентний підхід RAG. Замість простого кроку «знайти — створити» можна використовувати цикл:
Retrieve
↓
Evaluate
↓
Enough evidence?
↓ no
Retrieve again
↓
Generate
Така система може дійти висновку, що наявних доказів недостатньо, перефразувати запит, здійснити новий пошук або передати підзапит SQL-базі даних, графу знань чи живому API. Процес отримання інформації стає ітеративним та більше не є одноразовим.
Проте агентний підхід RAG не є автоматично кращим. Кожен додатковий цикл збільшує затримку, витрати на токени та ризик невдач, а також може спричинити зайві пошуки, коли у агента немає чіткої причини для продовження. Його складність має сенс тоді, коли запити є неоднозначними, потребують кількох кроків обробки чи кількох джерел інформації. Запит про політику повернення грошей, ймовірно, слід відповісти за один прохід за допомогою добре спроєктованої статичної системи. Порівняння типів карток може виправдати ітерації.
Важливим є питання про те, чи є у системи вимірювана причина для повторного пошуку, а не про те, чи взагалі їй потрібен агент. Ітерації без чітких правил завершення лише збільшують затримку та витрати.
Ментальна модель для виробництва
Найпоширенішою помилкою під час дебаггінгу є початок роботи з LLM. Погана відповідь — це лише останній симптом, а причина може знаходитися значно раніше у ланцюжку обробки даних. Застарілі документи нагадують галюцинації, погане розділення даних — невдалий пошук, слабкий пошук — помилку у генерації, а відсутність оцінки приховує всі ці проблеми до тих пір, поки клієнти не почнуть скаржитися.
Тож не запитуйте, яку модель використовувати. Запитайте, який шар у системі не працює належним чином.
INGESTION
↓
RETRIEVAL
↓
GENERATION
↓
EVALUATION
↖
└── feedback loop / Agentic RAG
Застарілі дані означають необхідність виправлення процесу їх надходження. Відсутній документ означає необхідність виправлення процесу його пошуку. Документ знайдений, але має низький ранг — це означає необхідність виправлення механізму ранжування. Неправильна відповідь у правильному контексті вимагає перегляду процесу генерації тексту. Якщо ви не можете визначити, що саме стосується ситуації, спочатку розробіть кращу систему оцінки. А коли однієї процедури ніколи не буде достатньо, розгляньте можливість використання агентного циклу.
Почніть з потоку обробки даних та залиште модель на останньому етапі.
Звідки походять ці ідеї
Для подальшого читання оригінальна стаття про генерацію з підсиленням за допомогою пошуку від Льюїса та його колег (NeurIPS 2020) визначає основну схему. Стаття Anthropic 2024 року про контекстуальний пошук повідомляє про значне зниження кількості невдалих пошуків завдяки контекстуальним ембеддингам, контекстуальному BM25 та механізмам переранжування, хоча це є власними показниками компанії-виробника. Кормак, Кларк та Бюттчер (SIGIR 2009) представили метод Reciprocal Rank Fusion. Стаття «Lost in the Middle» від Лю та його колег досліджує, як моделі використовують довгі контексти; стаття RAGAs описує автоматизовану оцінку RAG, а стаття Self-RAG від Асаї та його колег розглядає саморефлексивний, агентний пошук.
Пов’язана література
- Практичні нотатки: Межі векторного пошуку в RAG — косинусна схожість та інше — Детальний огляд Практичних нотаток: Межі векторного пошуку в RAG — косинусна схожість та інше: контракти, перевірки та готові фрагменти коду для команд, які впроваджують цю схему.
- Значення як координати: від ембеддингів до векторних баз даних та RAG — Простий опис ембеддингів речень, косинусної схожості, векторних баз даних та циклу RAG, із чотирма короткими реченнями про собак, котів та Париж, які демонструють, як працює пошук за значенням.