Чому розумні ШІ-асистенти все одно помиляються: погляд через конвеєр

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

Виникає дивний парадокс.

More intelligence ≠ Perfect accuracy

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

User Question
      ↓
Query Understanding
      ↓
Retrieval System (RAG)
      ↓
Context Selection
      ↓
LLM Generation
      ↓
Final Answer

Вада лише на одному етапі здатна зіпсувати підсумкову відповідь, навіть якщо всі інші етапи відпрацювали ідеально. Якщо простежити весь ланцюжок, видно, де що ламається і що можна зробити з кожним збоєм.

Розумний — не означає точний

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

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

Передбачення без перевірки

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

Question:
Who invented XYZ technology?

AI:
Generates the most probable answer.

Problem:
Probability is not always truth.

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

Який вигляд має галюцинація

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

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

Звичайна послідовність проста.

Missing Information
      ↓
Model Attempts Prediction
      ↓
Confident But Incorrect Output

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

Вузьке місце контекстного вікна

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

Large Document
      ↓
Only Selected Context
      ↓
LLM
      ↓
Answer

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

RAG допомагає, але додає точки відмови

Генерація, доповнена пошуком (RAG), розв'язує проблему того, що ШІ не знає ваших даних. Релевантні документи витягають із бази знань, передають моделі як контекст, і відповідь спирається на них. Це справді підвищує точність, але помилок не усуває, бо приносить нові способи зламатися:

• Погане нарізання на чанки. Коли документи ріжуть на частини для зберігання, ключова інформація може відірватися від контексту, що надає їй сенсу. Фраза на кшталт «це стосується лише річних тарифів» може потрапити в інший чанк, ніж правило, яке вона уточнює.
• Схожі, але хибні збіги. Пошук повертає документи, схожі на запит, а це не обов'язково ті, що на нього відповідають. Тема правильна, подробиці — ні.
• Застарілі дані. Векторне сховище свіже рівно настільки, наскільки свіже його останнє оновлення. Якщо політика повернення коштів змінилася минулого місяця, а ембединги не перегенерували, асистент упевнено процитує стару політику.
• Забагато контексту. Підтягувати зайві документи «про всяк випадок» може обернутися проти вас. Коли промпт переповнений, потрібний матеріал тоне в шумі, і модель утрачає з поля зору головне.

Подібність — не правильність

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

User Query

"refund for yearly subscription"

        ↓

Embedding

        ↓

Similar Documents Retrieved

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

Генерація теж може підвести

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

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

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

Ось як суперечливий контекст псує в іншому справний конвеєр:

Retrieved Data:

Document A:
Refund allowed within 30 days.

Document B:
Refund allowed within 14 days.

      ↓

AI must decide.

      ↓

Possible incorrect answer.

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

Надійність треба проєктувати свідомо

Усе це не робить RAG чи LLM ненадійними за своєю природою. Це означає, що надійність треба вибудовувати свідомо. Найсильніше впливають кілька важелів.

Якісніший пошук:

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

Чіткі інструкції моделі. Явні вказівки помітно скорочують галюцинації:

Answer only using the provided context.
If the information is not available in the context, say you don't know.

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

Вимірювання. Невиміряне не можна виправити, тож надійні системи відстежують достовірність (чи відповідає відповідь знайденому контексту?), точність (чи правильна вона фактично?) і якість пошуку (чи взагалі знайдено потрібні документи?).

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

Не судіть за тоном

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

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

• Точність пошуку: чи знаходяться потрібні документи для цього запиту?
• Релевантність відповіді: чи відповідає вона на поставлене запитання?
• Частота галюцинацій: як часто система видає твердження без опори?
• Задоволеність користувачів: чи отримують люди користь, чи лише ввічливі відписки?

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

Наступне завдання — надійність

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

Better Models

+

Better Data

+

Better Retrieval

+

Better Evaluation

=

Reliable AI Assistants

Кожна хибна відповідь асистента сягає корінням прогалини в одному з цих рівнів, а не браку інтелекту. З'ясувати, який рівень підвів, — перший крок до виправлення.