Чому Google відключив медичний AI: архітектурний розбір збою RAG

Чим chunk-collision відрізняється від галюцинації — і чому це важливіше

Більшість розробників налаштовують RAG проти галюцинацій: знижують temperature, додають grounding, перевіряють джерела. Але chunk-collision — інша категорія помилки. Модель грає за правилами. Проблема — в тому, що їй підклали.

Визначення: що таке галюцинація в LLM

Галюцинація — це коли модель генерує факт, якого немає в джерелах і який суперечить реальності. Модель «вигадує» інформацію з параметричної пам'яті, коли впевненість висока, але знання — хибне.

Детально про механізми галюцинацій, їх типи і способи зниження ризику — у нашій окремій статті: Галюцинації ШІ: що це, чому небезпечні та як уникнути .

Визначення: що таке chunk-collision

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

Порівняння: галюцинація проти chunk-collision

Чому chunk-collision складніше діагностувати

Галюцинацію можна виявити через грounding-перевірку: порівняти відповідь з документами у контекстному вікні. Якщо відповідь суперечить chunks — це галюцинація.

Chunk-collision цим методом не ловиться. Подивись на приклад:

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

Grounding-перевірка:
✓ "обмежити жири до 40г" → підтверджено chunk_id: 4821
✓ "достатня калорійність, включаючи жири" → підтверджено chunk_id: 2203

Результат перевірки: PASSED. Відповідь заземлена.
Реальна проблема: chunk 4821 і chunk 2203 — різні клінічні протоколи.
  

Стандартні метрики якості RAG — faithfulness, answer_relevancy, context_precision — також не виловлюють chunk-collision, оскільки відповідь дійсно faithful до chunks у контексті. Система отримує високі оцінки якості — і залишається небезпечною.

Третій клас помилок: схемінг

Галюцинація і chunk-collision — це помилки без наміру: модель не «хоче» помилятися, вона просто не має механізму розрізнити правильне від хибного в цьому контексті.

Існує й третій, принципово інший клас відхилень — схемінг: коли поведінка моделі систематично розходиться з декларованими цілями, але не через помилку, а через оптимізацію на прихований сигнал. Це окрема і складніша проблема — детально про неї: Схемінг у ШІ: як моделі обманюють і як захиститися .

Як діагностувати chunk-collision у своєму пайплайні

1. Аналізуй різноманітність chunks у контексті

Якщо retrieval повертає фрагменти з різних протоколів, категорій або часових періодів — це сигнал ризику. Введи метрику context diversity score: наскільки різняться metadata retrieved chunks за одним запитом. Висока різноманітність при вузькому запиті — червоний прапор.

2. Додай metadata-фільтрацію перед синтезом

Chunks з несумісними тегами не повинні потрапляти в один контекст. Приклад фільтра на рівні retrieval-пайплайну:

def filter_incompatible_chunks(chunks: list[Chunk]) -> list[Chunk]:
    """
    Видаляє chunks з несумісними condition_type.
    Залишає тільки ті, що відповідають домінантній категорії запиту.
    """
    condition_types = [c.metadata.get("condition_type") for c in chunks]
    dominant_type = Counter(condition_types).most_common(1)[0][0]

    return [
        c for c in chunks
        if c.metadata.get("condition_type") == dominant_type
    ]
  

Це спрощений приклад — реальна логіка залежить від домену. Але принцип незмінний: metadata повинна бути частиною chunk з моменту індексування, а не додаватися пізніше.

3. Логуй на рівні retrieval, а не тільки generation

Більшість команд логує фінальні відповіді і оцінює їх якість постфактум. Chunk-collision цим не виловлюється — проблема виникає до генерації.

Мінімальний набір для логування кожного запиту:

• query — оригінальний запит користувача
• retrieved_chunk_ids — ідентифікатори всіх chunks у контексті
• chunk_metadata — metadata кожного chunk (категорія, дата, джерело)
• similarity_scores — cosine similarity для кожного chunk
• final_answer — згенерована відповідь

Маючи цей лог, ти зможеш ретроспективно виявити патерни collision: запити, при яких retrieval стабільно повертає chunks з різних категорій.

4. Додай cross-chunk consistency check перед синтезом

Перед передачею chunks у generation-модель додай проміжний крок: попроси LLM оцінити, чи є retrieved chunks сумісними між собою в контексті запиту. Якщо ні — або відфільтруй несумісні, або поверни уточнюючий запит користувачеві.

consistency_prompt = f"""
Запит користувача: {query}

Нижче наведені фрагменти, знайдені для відповіді на цей запит.
Визнач: чи всі вони відносяться до одного клінічного/предметного контексту?
Якщо є несумісні фрагменти — вкажи їх ID і поясни несумісність.

{format_chunks(retrieved_chunks)}

Відповідай у форматі JSON:
{{"compatible": true/false, "incompatible_ids": [], "reason": ""}}
"""
  

Це додає latency — але для YMYL-запитів це виправданий компроміс.

Що це означає для будь-якого RAG-пайплайну — не тільки медичного

Медицина — найбільш видимий приклад, але не єдиний. Chunk-collision і validation bias виникають скрізь, де корпус неоднорідний, а ставки помилки високі.

Три сфери з аналогічною структурою ризику

E-commerce і ціноутворення

RAG-бот отримує запит про ціну продукту. У корпусі — chunks зі старими прайсами, акційними умовами і поточним каталогом. Similarity search не розрізняє актуальність. Клієнт отримує неправильну ціну, підкріплену «джерелами».

Юридичні боти

Запит про трудове право. У корпусі — судова практика 2018 року і поправки 2023 року. Обидва документи семантично близькі до запиту. Відповідь синтезується з несумісних правових норм. Користувач отримує юридично застарілу рекомендацію.

Корпоративний пошук

Запит про внутрішній процес. У корпусі — старий регламент і новий. Обидва знаходяться по запиту. Відповідь мікшує два несумісних процеси. Особливо критично для onboarding або compliance-систем.

Три архітектурних висновки

1. Класифікатор контексту перед retrieval

До similarity search додай крок класифікації запиту: до якої категорії він належить? Це дозволяє обмежити пошук тільки релевантним підкорпусом. Наприклад, запит з тегом oncology шукає тільки в онкологічному розділі корпусу, а не по всій медичній базі.

2. Metadata у chunk — не опція, а вимога

Кожен chunk повинен містити метадані, які дозволяють фільтрувати несумісні фрагменти: дата документа, категорія, версія протоколу, область застосування. При chunking ці поля не повинні відрізатися — вони є частиною контексту фрагмента.

3. Логування на рівні retrieval, а не тільки generation

Більшість команд логує фінальні відповіді і оцінює їх якість. Це не дозволяє побачити проблему: chunk-collision виникає до генерації. Логуй retrieved chunks для кожного запиту, і ти побачиш патерни несумісності задовго до того, як вони стануть скаргами користувачів.

Практичні підходи до оцінки якості retrieval описані в документації RAGAS — відкритого фреймворку для evaluation RAG-систем.

Куди рухається індустрія: відкритий пошук проти закритих верифікованих систем

Відкат Google — не відступ від AI в медицині. Це розмежування між двома архітектурами: публічним пошуком з відкритим корпусом і закритими системами з контрольованим індексом.

Публічний пошук стає консервативним

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

Це не унікальна позиція Google. Microsoft Bing, який агресивно інтегрував GPT-4 у пошук у 2023 році, також додав explicit disclaimers для медичних запитів і обмежив генеративні відповіді на YMYL-тематику після серії публічних інцидентів. Тренд однаковий: відкритий корпус + генеративний синтез = некерований ризик для критичних ніш.

Закриті системи: що означає «контрольований індекс» на практиці

Термін «контрольований індекс» звучить абстрактно. На практиці це набір конкретних архітектурних рішень, які відрізняють закриту медичну систему від публічного RAG:

Верифіковані джерела з явною областю застосування

Кожен документ у корпусі пройшов ручну або автоматизовану верифікацію. Metadata містить не просто «медична стаття», а condition: oncology, stage: chemotherapy, protocol_version: 2023-Q4, reviewed_by: oncologist. Retrieval фільтрує за цими полями до similarity search — а не після.

Версіонування документів

Медичні протоколи оновлюються. У контрольованому індексі кожна версія документа зберігається окремо з датою введення в дію. Запит автоматично маршрутизується до актуальної версії — застарілий chunk фізично не потрапляє у retrieval.

Детерміновані відповіді для критичних сценаріїв

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

Аудит-лог кожного inference-запиту

Для регуляторної звітності (HIPAA у США, MDR у Євросоюзі) кожен запит, retrieved chunks і згенерована відповідь логуються з можливістю повного відтворення. Це не опція — це вимога сертифікації.

Приклади закритих систем, що вже працюють

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

Інші приклади тієї ж архітектурної логіки:

• Epic Systems + AI — інтеграція LLM у медичні записи (EHR) з жорстко контрольованим корпусом: модель працює тільки з даними конкретного пацієнта і верифікованими клінічними протоколами, ізольованими від відкритого вебу.
• FDA-cleared AI-пристрої — клас Software as a Medical Device (SaMD), де кожна версія моделі і корпусу проходить окрему сертифікацію. Будь-яке оновлення індексу — новий регуляторний цикл.
• Внутрішні корпоративні RAG-системи — юридичні, фінансові, compliance-боти у великих компаніях, де корпус — виключно внутрішні верифіковані документи, а не відкритий веб.

Чеклист: чи готовий твій RAG для критичної ніші

Якщо ти будуєш RAG для задачі з високою ціною помилки — пройдись по цьому списку перед тим, як відкривати систему для користувачів:

• ☐ Кожен документ у корпусі має явну metadata про область застосування і дату актуальності
• ☐ Застарілі версії документів ізольовані від retrieval або явно помічені
• ☐ Retrieval фільтрує за контекстом запиту до similarity search, а не після
• ☐ Логується не тільки відповідь, а й retrieved chunks з similarity scores
• ☐ Є механізм виявлення chunk-collision перед синтезом
• ☐ Для найкритичніших запитів — детермінований витяг замість генеративного синтезу
• ☐ Є процес регулярного аудиту корпусу на актуальність і несуперечливість

Питання не «яку модель взяти» — питання «як організований корпус». Архітектурні рішення на рівні індексування, chunking і metadata визначають якість системи більше, ніж вибір між конкретними LLM.

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

Висновок

Відкат What People Suggest — це не поразка AI у медицині. Це корекція архітектурної помилки: спроби застосувати інструмент загального призначення до задачі, яка вимагає контрольованого корпусу і верифікованих джерел.

Джерело важливіше за модель. Ця теза незручна, тому що з нею складніше продавати нові архітектури. Але вона точна.

А тепер питання до тебе: як у твоєму поточному RAG-пайплайні організована фільтрація несумісних chunks? Чи є metadata, яка дозволяє retrieval-системі розрізняти контекст — чи все іде в один індекс?

Часті питання

Що таке RAG і навіщо він потрібен?

RAG (Retrieval-Augmented Generation) — архітектура, при якій мовна модель перед генерацією відповіді витягує релевантні фрагменти з зовнішнього корпусу документів. Це дозволяє моделі відповідати на запити, спираючись на актуальні дані, а не тільки на параметричну пам'ять з тренування. Детальніше — в оригінальній статті RAG від Meta AI (2020).

Що таке YMYL у контексті пошуку?

YMYL (Your Money or Your Life) — категорія пошукових запитів, визначена Google, де неправильна відповідь може завдати шкоди: медицина, право, фінанси, безпека. До таких запитів Google застосовує підвищені вимоги до якості джерел. Офіційне визначення — у Search Quality Rater Guidelines.

Чи можна повністю уникнути chunk-collision?

Повністю — ні, якщо корпус великий і неоднорідний. Але ризик суттєво знижується через класифікацію запитів перед retrieval, детальну metadata на рівні chunk і фільтрацію несумісних фрагментів перед синтезом.

Які інструменти допомагають оцінити якість RAG?

Серед відкритих фреймворків для evaluation RAG-систем:

• RAGAS — метрики faithfulness, answer relevancy, context precision
• RAGAS на GitHub — відкритий код
• TruLens — evaluation і трасування RAG-пайплайнів