RAG чи тонке налаштування? Чого нас навчили реальні клієнтські проєкти

Майже кожна моя розмова про ШІ для бізнесу вже протягом першої години доходить до тієї самої розвилки. У клієнта є велика мовна модель, яка справляє враження під час демонстрації, але не знає його продуктів, політик і стилю письма. Хтось у кімнаті запитує: чи варто нам налаштувати модель на наших даних, чи краще побудувати для неї систему генерації з доповненим пошуком (RAG)?

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

Почніть із того, чого бракує моделі

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

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

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

RAG — інструмент для розв’язання першої проблеми. Тонке налаштування — для другої. Більшість непорозумінь, із якими я стикаюся, виникає через спроби навчити модель фактам за допомогою тонкого налаштування.

Чому тонке налаштування — невдалий спосіб додати знання

Спокусливо думати, що якщо навчити модель на своїх документах, вона їх «знатиме». На практиці вона значно краще засвоює стиль цих документів, ніж викладені в них факти. Дослідники Microsoft безпосередньо порівняли обидва підходи для запитань, що потребують ґрунтовних знань, і з’ясували, що RAG стабільно перевершував неконтрольоване тонке налаштування як щодо фактів, які модель бачила під час навчання, так і щодо цілком нових фактів.

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

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

Хороший приклад — наш клієнт із логістичної галузі. Його клієнти хотіли миттєво отримувати відповіді про місце перебування своїх вантажів і відсутні документи. Ця інформація змінюється кожні кілька хвилин. Жодне навчання не дало б змоги постійно підтримувати модель в актуальному стані, тож створений нами асистент під час запиту відповідає на основі даних відстеження в реальному часі та даних IoT, а не власної пам’яті. Єдиним працездатним рішенням був пошук.

Де тонке налаштування справді доречне

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

• Суворо визначені повторювані формати відповідей. Коли модель має тисячі разів на день видавати однакову структуровану відповідь — наприклад, витягувати поля з рахунків-фактур за фіксованою схемою JSON, — невелика модель із тонким налаштуванням часто працює надійніше й коштує набагато дешевше, ніж велика модель, якій дають відповідні інструкції.
• Галузева термінологія. У деяких галузях є скорочення, які базова модель тлумачить неправильно. Типові приклади — коди логістичних статусів, клінічні абревіатури та внутрішні коди продуктів. Помірного тонкого налаштування може бути достатньо, щоб виправити цю проблему.
• Вартість і затримка за великого масштабу. Щойно завдання чітко визначене, невелика модель із тонким налаштуванням може замінити велику універсальну модель. Такі методи, як LoRA, роблять це доступним за вартістю: замість усієї моделі навчається невеликий набір додаткових ваг.

Зауважте: жоден із цих випадків не стосується фактів. Ідеться про те, щоб навчити модель виконувати завдання, яке ви вже добре розумієте.

Більшість збоїв RAG — це збої пошуку

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

Рішення не вражають, але дієві:

• Діліть на фрагменти за змістом, а не за кількістю символів. Якщо розбити договір кожні 500 символів, його пункти розірвуться навпіл. Поділ за розділами й заголовками допомагає зберегти контекст.
• Додавайте контекст до кожного фрагмента. Фрагмент із текстом «ліміт становить 30 днів» ні до чого не придатний, якщо невідомо, до якої політики він належить. В Anthropic повідомили, що додавання короткого контексту документа до кожного фрагмента перед індексуванням — підхід, який там називають контекстно збагаченим пошуком, — зменшило кількість невдалих пошуків на 49%, а в поєднанні з повторним ранжуванням — на 67%.
• Поєднуйте пошук за ключовими словами з векторним пошуком. Векторний пошук добре вловлює зміст, але гірше працює з точними термінами, як-от номери деталей. Гібридний пошук охоплює обидва типи запитів.
• Перевірте пошук окремо. Складіть набір реальних запитань із відомими правильними джерельними фрагментами й перевірте, чи з’являється потрібний фрагмент серед перших результатів, перш ніж оцінювати остаточні відповіді.

Коли варто використовувати обидва підходи

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

Але важлива послідовність. Ми майже завжди спочатку створюємо систему RAG, визначаємо, у чому її недоліки, і лише потім вирішуємо, чи варте донавчання зусиль. Якщо почати з донавчання, доведеться оплачувати навчання, ще не з’ясувавши, у чому саме проблема.

Простий контрольний список для ухвалення рішення

1. Чи залежить завдання від фактів, які змінюються частіше ніж раз на квартал? Використовуйте RAG.
2. Чи потрібно користувачам або аудиторам бачити, звідки взялася відповідь? Використовуйте RAG.
3. Проблема у форматі, тоні чи лексиці відповідей, а не у фактах? Розгляньте донавчання.
4. Це вузькоспеціалізоване завдання, яке виконується у великих обсягах, і для нього важливі вартість або швидкість? Розгляньте донавчання меншої моделі.
5. Ви вже окремо виміряли якість пошуку? Якщо ні, зробіть це передусім.

Головний висновок

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