Три причини невдач у продакшн-системах RAG: фрагментований контекст, зміни у даних та неправильне використання.

Чому демонстрації RAG функціонують, а продакшн-системи — ні

Технологія Retrieval-augmented generation стала стандартною архітектурою для корпоративних ШІ. Асистенти підтримки, внутрішні інструменти знань, консультанти з дотримання правил та розумні пошукові системи в банківській, страховій, медичній сферах, телекомунікаціях, ритейлі та урядових установах використовують її для підключення мовних моделей до власних знань компанії. Ідея здається простою: отримати відповідні уривки з бази знань та передати їх моделі перед тим, як вона дасть відповідь. Однак реалізувати це в продакшені набагато складніше, ніж може здатися на етапі демонстрації концепції.

Багато команд створюють прототип, який працює, але потім стикаються з новими проблемами при масштабуванні. Відповіді надходять неповними. Якість пошуку погіршується з ростом обсягу даних. Втрачається важливий контекст, з’являються галюцинації, зростає затримка, а користувачі отримують відповіді, які технічно правильні, але практично марні. Іноді система пошуку знаходить саме потрібні документи, але модель все одно дає неправильну відповідь.

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

Існує поширене хибне уявлення, що кращий RAG означає переважно кращий LLM. Вибір моделі має значення, але багато проблем у продакшні виникають з інших причин: розділення на частини, архітектура пошуку, керування контекстом, процеси ранжування та оцінки. Добре створена система пошуку у поєднанні з потужною моделлю часто буде кращою за недбалу систему, яка використовує найсучаснішу модель. У регульованих сферах, таких як банківська справа, знання цих способів збоїв зазвичай мають більшу цінність, ніж знання внутрішньої структури найновіших моделей, адже успіх у продакшні рідко залежить від оновлення однієї моделі. Все залежить від того, наскільки добре інформація знаходиться, ранжується, формулюється та представляється.

Три сценарії показують, як можуть виникнути проблеми:

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

Модель дає неправильні відповіді, хоча були знайдені правильні документи.

Урок, який можна зробити з усіх трьох прикладів, полягає у тому, що якісний RAG залежить від кращого пошуку інформації, управління контекстом, оцінки та проектування системи, а не лише від кращих моделей.

Сценарій один: релевантний текст, але відсутній суть

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

Уявіть собі сховище знань банку, яке містить правила оформлення клієнтських акаунтів. Основні вимоги розміщені в одному розділі, обробка винятків — у іншому, а регуляторні вимоги — у окремому розділі, який опікується відділ ризиків. Клієнт запитує, чи достатньо певного документа для відкриття рахунку. Система пошуку повертає відповідні правила, але не бере до уваги регуляторні винятки, задокументовані в іншому місці. Відповідь моделі є правильною з огляду на отриману інформацію, але все одно неповною з точки зору бізнес-процесів. Це приклад системи, яка розуміє лише частину документа та не бачить загальної картини.

Інженери часто підозрюють у проблемах саму модель. Зазвичай винуватцем є архітектура пошуку.

Фрагменти фіксованого розміру переривають логіку

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

Способи усунення розривів контексту

Семантичне розділення є стандартним рішенням. Замість того, щоб ділити текст за произвільною кількістю токенів, воно слідує природній структурі — заголовкам, розділам, абзацам та змінам теми, що дозволяє зберегти взаємозв’язки та значно покращити процес пошуку.

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

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

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

Зростання обсягів баз знань підвищує вимоги до якості пошуку. Векторний пошук чудово підходить для пошуку семантично схожого контенту, але може пропустити точну термінологію, назви продуктів, ідентифікатори політик, нормативні посилання та ключові слова, специфічні для певної галузі. У банківській сфері клієнт може посилатися на конкретну нормативну акт, тип рахунку чи категорію операції, які вимагають точного збігу. Гібридна стратегія, яка поєднує семантичний пошук із методами на основі ключових слів, такими як BM25, враховує обидві сторони: семантичний пошук дозволяє розуміти зміст, а пошук за ключовими словами — забезпечує точність, і разом вони охоплюють більше, ніж кожен з них окремо.

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

Коротко кажучи

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

Сценарій два: чудово під час розробки, проблематично у продакшені

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

Чи змінилися дані?

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

Вимірюйте ефективність пошуку окремо

Далі оцінюйте процес пошуку окремо від мовної моделі. Поширеною помилкою є звинувачення ШМ у поганих відповідях, коли механізм пошуку взагалі не надав правильного контексту. Показники на кшталт Recall@K та Precision@K швидко розв’язують цю проблему: якщо правильний документ не потрапляє до числа топових результатів, у моделі просто не було шансів. Часто сам процес пошуку потребує вдосконалення.

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

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

Реальні запити відрізняються від тестових

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

Подивіться всередину конвеєра обробки даних

Оперативне спостереження за процесом пошуку є ще однією цінною технікою. Для кожного запиту в промисловому середовищі видимість має охоплювати:

• які документи були отримані
• причину отримання кожного з них
• бали схожості
• кінцевий контекст, надісланий до ШІ
• створену відповідь

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

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

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

Коротко кажучи

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

Сценарій третій: правильні документи, неправильна відповідь

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

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

Надмірний обсяг контексту та проблеми з його обробкою

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

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

Запити, які вимагають обґрунтування

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

Генерація на основі цитувань також допомагає. Коли моделі потрібно назвати конкретні розділи чи ідентифікатори документів, значно простіше перевірити, чи ґрунтується відповідь на отриманих доказах, що має велике значення у регульованих галузях, таких як банківська справа, де необхідні можливості аудиту та пояснення.

Суперечливі джерела

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

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

Коротко кажучи

Коли правильні документи повертаються, а відповідь все одно неправильна, перевірте, як модель використовує контекст: перевантаження, ефекти „втрати в середині“, суперечливі джерела та слабке обґрунтування. Серед способів виправлення, які варто спробувати, — переранжування результатів, скорочення обсягу контексту, відповіді з посиланнями на джерела, фільтри метаданих та запити, які змушують модель спиратися лише на отримані докази. Часто проблема полягає не у самому пошуку, а у тому, як використовується контекст.

Що спільного у цих трьох випадках

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

Постійною темою є те, що якість отримання інформації має таке ж значення, як і можливості моделі. Навіть найсучасніша ШІ-модель не може компенсувати відсутність контексту, погано структуровані фрагменти, слабкі стратегії пошуку чи несуттєвий матеріал у запиті, а покращення архітектури пошуку часто приносить більше користі, ніж заміна моделі. Для інженерів, архітекторів та технічних керівників те, що відрізняє системи промислового рівня від ефектних демонстрацій, — це ретельне проектування: правильна структурування інформації, надійні механізми пошуку, орієнтація на контекст, переурочування результатів та постійна оцінка. Корпоративний ШІ — це не лише генерація відповідей. Це генерація відповідей, які є релевантними, обґрунтованими, пояснюваними та послідовно надійними.