Зменшення галюцинацій у системі чат-бота на основі медичних RAG

Проєкт розпочався з простої мети.

Ви хотіли створити чат-бота, здатного відповідати на запитання на основі медичних дослідницьких статей.

Це мало б бути досить просто, чи не так?

Виявилося, що ні.

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

Це працювало.

Але не надійно.

А в медичному контексті „ненадійність“ є серйозною проблемою.

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

Це усвідомлення спонукало процес пошуку до постійного вдосконалення.

Перша проблема: галюцинації

Найнагальнішою проблемою, яку потрібно було вирішити, була галюцинація.

Моделі мови дуже вправно створюють відповіді, які звучать переконливо, іноді навіть занадто переконливо.

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

Цю поведінку потрібно було змінити.

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

Тож основна філософія змінилась.

Замість того, щоб розглядати ШММ як авторитет у питаннях фактів, отримані документи стали справжнім джерелом істини.

Роль ШММ скоротилась до інтерпретації цього контексту та формування з нього послідовної відповіді.

А що робити, коли контексту було недостатньо?

Система мала відмовлятися від припущень.

Початок з базового RAG

Перша версія цієї архітектури виглядала простою:

Це є стандартним паттерном RAG.

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

Кожного разу, коли користувач ставить запитання, воно також інтегрується.

Потім система шукає фрагменти, ембеддинги яких є семантично близькими.

У теорії — все просто.

Але швидко з’явився певний паттерн.

Семантична близькість не гарантує фактичної релевантності.

Чому векторний пошук був недостатнім

"Які наслідки інсулінорезистентності?"

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

Це корисно.

Однак медичні тексти сповнені точною термінологією.

Такі терміни, як:

• резистентність до інсуліну
• HbA1c
• гіперглікемія
• метформін
• толерантність до глюкози

Ці конкретні терміни мають велике значення.

Іноді потрібно розуміння загального значення.

Іншим разом необхідно, щоб система знаходила саме точний термін.

Чому обмежуватися лише однією функцією?

Рішенням було поєднання обох підходів.

Гібридний пошук

Саме тут гібридний пошук став ключовою частиною дизайну.

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

Логіка цього досить інтуїтивна.

Семантичний пошук по суті запитує:

„Який контент має схоже значення?“

Ключовий пошук, натомість, запитує:

„Де насправді зустрічаються ключові терміни?“

Кожен метод має свої переваги.

І кожен має свої слабкі сторони.

У поєднанні вони охоплюють ширший спектр запитів.

Отриманий процес виглядав так:

User Query
                        ↓
              ┌─────────┴─────────┐
              ↓                   ↓
        Vector Search       Keyword Search
              ↓                   ↓
              └─────────┬─────────┘
                        ↓
                  Combined Results
                        ↓
                     Reranker
                        ↓
                 Best Context
                        ↓
                       LLM
                        ↓
                      Answer

Ця зміна змінила підхід до пошуку в майбутньому.

Проте залишалася ще одна проблема.

Отримання чогось не означає, що це найкращий варіант

Припустимо, крок гібридного пошуку повертає 20 фрагментів.

Це звучить обнадійливо.

Але чи кожен з цих фрагментів справді корисний?

Не обов’язково.

Деякі фрагменти можуть бути дуже пов’язаними з темою.

Інші можуть просто мати спільний словниковий запас.

Ще інші можуть бути лише частково пов’язаними та не відповідати на справжнє запитання.

Передача всього цього безпосередньо до LLM — не ідеальне рішення.

Більше отриманого контексту не обов’язково призводить до кращих відповідей.

Насправді це може зашкодити результату.

Це додає більше токенів, більше нерелевантного шуму та більшу затримку.

Тому був введений ще один етап.

Перепріоритизація.

Чому перепріоритизація змінила ситуацію

Роль механізму пошуку можна узагальнити як:

Виявлення можливих кандидатів.

Роль механізму перепріоритизації інша:

Визначення того, які з цих кандидатів є справді релевантними.

Отже, замість простої послідовності:

Query → Search → LLM

процес еволюціонував у:

Query
 ↓
Hybrid Search
 ↓
20 Candidate Chunks
 ↓
Reranker
 ↓
Top Relevant Chunks
 ↓
LLM

Це розділення обов’язків має велике значення.

Перший етап пошуку може надавати пріоритет охопленню, розкидаючи широку мережу пошуку.

Етап перепріоритизації може тоді зосередитися саме на релевантності та точності.

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

Найважливіший елемент: відмова від фальсифікації

Окрім пошуку та переурочення пріоритетів, на етапі генерації були додані суворі обмеження.

Основна інструкція зводилася до наступного:

Use the provided context to answer.

Do not invent information.If the context doesn't contain enough information,
say that there isn't enough information available.

Це здається майже занадто простим, щоб мати значення.

Проте це суттєво змінює поведінку чат-бота.

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

Цей механізм виходу виявляється надзвичайно важливим.

Іноді чесна відповідь виглядає приблизно так:

„Я не зміг знайти достатньо інформації в наданому дослідницькому матеріалі.“

Не кожне запитання заслуговує на впевнену відповідь.

Чи повністю усунуті галюцинації?

Не зовсім.

Це стало зрозумілим під час розробки системи.

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

Але стверджувати, що галюцинації повністю відсутні, — це перебільшення.

Залишається багато можливих проблем.

Механізм пошуку може вибрати неправильний фрагмент.

Сам процес розділення на фрагменти може призвести до втрати важливого контексту.

Механізм ранжування може неправильно оцінити інформацію.

У самих документах може взагалі бракувати необхідної інформації.

І навіть коли все на початкових етапах працює правильно, ШІ все одно може неправильно інтерпретувати отриману інформацію.

Тож справжня мета не є:

«Створити чат-бота, який ніколи не помиляється».

Вона більше схожа на:

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

Це набагато більш досяжна мета.

Дизайн частин виявився критичним

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

Частини, які занадто великі, містять непов’язаний контент.

Частини, які занадто малі, можуть позбавити текст необхідного контексту.

Корисно розглядати кожну частину як самодостатню одиницю знань, а не просто довільний фрагмент тексту.

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

А кращий пошук, у свою чергу, зазвичай дає кращі кінцеві відповіді.

Прискорення процесу обробки

Правильність була лише половиною проблеми; іншою був час відповіді.

Одна заявка RAG може ініціювати кілька різних операцій:

User Query
   ↓
Embedding
   ↓
Vector Search
   ↓
Keyword Search
   ↓
Merge Results
   ↓
Reranking
   ↓
LLM

Виконання всіх цих операцій суворо по черзі уповільнює весь процес.

Щоб вирішити цю проблему, окремі кроки отримання даних були перетворені на асинхронні, де це було можливо.

Оновлений алгоритм виглядав приблизно так:

User Query
                     ↓
              ┌──────┴──────┐
              ↓             ↓
        Vector Search   Keyword Search
              ↓             ↓
              └──────┬──────┘
                     ↓
                  Rerank
                     ↓
                    LLM

Це скоротило час очікування між кроками, які насправді не залежали один від одного.

Лише точність — це не все для хорошої системи RAG.

Користувачі не хочуть сидіти й чекати на відповідь.

Отримана архітектура

Після кількох етапів вдосконалення конвеєр опрацювання набув приблизно такого вигляду:

Medical Research Documents
                         ↓
                  Document Processing
                         ↓
                      Chunking
                         ↓
                     Embeddings
                         ↓
                   Vector Database
                         ↓
                      User Query
                         ↓
              ┌──────────┴──────────┐
              ↓                     ↓
       Semantic Search        Keyword Search
              ↓                     ↓
              └──────────┬──────────┘
                         ↓
                    Result Fusion
                         ↓
                      Reranker
                         ↓
                Relevant Context
                         ↓
                 Grounded Prompt
                         ↓
                       LLM
                         ↓
                 Final Response

Кожен компонент у цій схемі має свою конкретну функцію.

Це розділення стало одним із найцінніших уроків проекту.

База даних векторів призначена не для відповідей на запитання.

Механізм пошуку не призначений для створення відповідей.

LLM не призначений за замовчуванням для того, щоб знати все.

Кожен елемент виконує одну функцію.

І в ідеалі він добре виконує цю функцію.

Уроки з розробки

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

Якість пошуку є непохитною

Навіть найсильніша модель мови не може компенсувати поганий контекст. Якщо надати їй слабкі результати пошуку, вона також надасть слабкі відповіді. Це простий приклад принципу „що ввели, те й отримаєте“.

Гібридний пошук доводить свою ефективність

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

Поновна класифікація заслуговує більшої уваги

Отримання двадцяти кандидатських результатів — це одна з проблем. Вибір п’яти найкращих із них — це зовсім інша проблема. Поновна класифікація знаходиться між цими двома кроками та подолює розбіжності.

Більші контекстні вікна не гарантують кращих відповідей

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

Визнання невизначеності — це сила, а не слабкість

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

Що далі?

Існує багато можливостей для покращень. Серед напрямків, які варто дослідити далі, є:

• Більш ефективні методи оцінки пошуку
• Переписування запитів
• Фільтрація метаданих
• Покращені моделі переранжування
• Відповіді з посиланнями
• Оцінка рівня впевненості та логіка утримання від відповіді
• Кращий контроль над процесом пошуку
• Автоматизовані набори даних для оцінки
• Додаткові заходи щодо кешування та зменшення затримок

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

Підсумок

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

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

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

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

Пов’язана література

• Ієрархічна карта концепцій інженерії ШІ та ситуацій, коли вони мають значення — Дізнайтеся, які концепції інженерії ШІ визначають, чи буде система взагалі функціонувати, які мають значення під час створення продукту для експлуатації, а які можна відкласти.
• Second Brain: Перетворення стенограм зустрічей на знаннєву мережу, яку можна запитувати — Пояснює, як агентний система витягує елементи зі стенограм зустрічей та зберігає їх у Cosmos DB для можливості пошуку за допомогою природної мови та дослідження знаннєвої мережі.