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

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

Так от, виявити це можна, і робиться воно не інтуїцією, а процедурою. Але спочатку варто зрозуміти, чому модель узагалі так робить, бо без цього будь-яка перевірка перетворюється на недовіру до всього підряд.

Чому модель вигадує

Велика мовна модель влаштована так, щоб дати відповідь. Хоч якусь. Їй, грубо кажучи, все одно, чи ця відповідь придумана, головне її видати.

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

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

Найчастіший біль: посилань немає взагалі

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

На першому: "Тому що він не надає посилання. Він дуже багато вигадує від себе, розписує від себе. Я йому, наприклад, можу дати і джерело, і ще щось. І він таке щось замудре пише, пише багато зайвого. І найкритичніше це те, що він не дає посилання."

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

В цілому це не поодинокий випадок, а системна поведінка режимів із пошуком. Тому в редакційній роботі правило просте: посилання, яке ви не відкрили самі, не існує.

Половина скарг на вигадані джерела це просто не той режим

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

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

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

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

Ну і окремо про сам Deep Research, бо я не хочу, щоб це прозвучало як претензія до режиму. Режим хороший, у багатьох задачах він мене дуже виручав.

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

Процедура перевірки, яка реально працює

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

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

Робочий порядок:

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

• просити не висновок, а цитату з посиланням на конкретний пункт документа

• відкривати кожне посилання руками. Це нудно, але займає хвилини

• питати норму, а не аналітику, якщо тема регульована

• ставити фінальну перевірку іншою моделлю, як окремий крок

Чому перевіряти може тільки той, хто розуміє тему

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

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

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

Що ставити в регламент

Якщо у вас регульована галузь або робота з зовнішніми документами, три речі варто закріпити письмово:

• який клас задач взагалі не виконується через ШІ без перевірки другою людиною

• хто відповідає за перевірку і що фіксується як факт перевірки

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

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

Чому питання "ти впевнений?" нічого не перевіряє

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

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

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

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

Де вигадки трапляються найчастіше

За моїми спостереженнями, помилка майже ніколи не приходить у великому твердженні. Вона сидить у дрібниці.

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

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

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

Головне про перевірку відповідей

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

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

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