Як AI-контент перевіряється на факти, перш ніж публікуватись

Текст, якому не можна вірити на слово

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

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

Перший рівень: генерація, прив'язана до джерела

Запит на генерацію ніколи не йде "в порожнечу" — завжди є конкретне призначене джерело (тема-якір і\або посилання на першоджерело), і модель отримує пряму інструкцію: не впевнений у даті, назві компанії, імені дослідника чи цифрі — не вигадувати, краще сформулювати загальніше. Це знижує кількість вигадок на старті, але не гарантує нуль — тому є другий, окремий рівень.

Другий рівень: незалежний прохід перевірки фактів

Окремий виклик моделі читає вже готовий текст і шукає твердження, не підтверджені в джерелі-якорі: цифри, дати, назви компаній і продуктів, статистику, цитати, порівняльні висновки ("перемагає"/"програє", "краще"/"гірше"). Для кожного — звіряється з офіційним джерелом через живий пошук, і або виправляє на коректні дані, або, якщо перевірити неможливо, переформульовує узагальнено — ніколи не підставляючи одну вигадку замість іншої.

// Спрощено з реального проходу перевірки
const prompt = `
Перевір текст на твердження, яких немає в темі-якорі
і які не підтверджені web_search.
Для кожного: знайди коректні дані через пошук або
переформулюй узагальнено, прибравши вигадану конкретику.
`;

Окрема перевірка — напрямок порівняльних висновків на числових метриках: якщо метрика "менше = краще" (час, вартість, помилки), а в тексті подана як перемога через зростання числа — це помилка інтерпретації навіть при правильних цифрах, і вона теж виправляється.

Кожен прогін повертає не просто виправлений текст, а список конкретних правок — тобто log, який можна переглянути окремо від самої статті:

const CORRECTION_TOOL = {
  name: 'submit_corrected_article',
  input_schema: {
    type: 'object',
    properties: {
      content: { type: 'string' },      // повний текст, з правками або без
      corrections: { type: 'array', items: { type: 'string' } }, // що саме змінено
    },
    required: ['content', 'corrections'],
  },
};

Інженерна деталь, яка пояснює, чому це окремий HTTP-виклик, а не ще один крок у тій самій генерації: три послідовні виклики Claude (написати → перевірити факти → self-review) в одній serverless-функції на Vercel впирались у ліміт виконання й падали з 504 FUNCTION_INVOCATION_TIMEOUT. Рішення — не "збільшити таймаут", а розбити кроки на окремі HTTP-запити: дашборд викликає перевірку фактів ОКРЕМИМ запитом вже після того, як основна генерація повернула чернетку.

Третій рівень: лінки не вимагають довіри, вони перевіряються кодом

Інструкція в промпті "використовуй правильні посилання" — це прохання, не гарантія. Тому окремий, не-AI шар парсить кожне посилання у фінальному тексті проти реального списку опублікованих сторінок на диску (для потрібної мови) і проти карти відповідності UK↔EN:

// Якщо посилання веде на статтю, яка існує лише в іншій мовній версії —
// не просто прибрати, а спробувати знайти відповідник цією ж мовою
if (otherKnownSlugs.has(slug)) {
  const mappedSlug = getAltLocaleSlug(slug, urlLocale);
  if (knownSlugs.has(mappedSlug)) {
    return `[${text}](/${locale}/blog/${mappedSlug})`; // підміна на правильну локаль
  }
}
// відповідника немає — краще прибрати посилання, ніж лишити биту адресу
return text;

Рівень перевірки	Що ловить	Тип
Інструкція в промпті	Базові вигадки на етапі написання	AI (запит)
Незалежний прохід перевірки фактів	Дати/цифри/назви/порівняння без підтвердження	AI (аудит)
Лінк-валідатор	Биті чи локально неправильні посилання	Код (детерміновано)
Self-review (нижче)	Формальні дефекти заперечення/логіки/пунктуації	AI (дешева модель)

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

Четвертий рівень: дешева модель, що шукає лише формальні дефекти

Окремий, навмисно дешевий прохід на меншій моделі (Haiku, а не та сама Sonnet, що пише й перевіряє факти) перечитує фінальний текст і шукає рівно три типи дефектів — не стиль, не зміст:

1. Зайва або пропущена частка заперечення ("не", "ні", "чи"), яка перевертає сенс речення
2. Смислова нестиковка всередині речення
3. Пунктуаційний дефект — питання без "?", незакритий розділовий знак

const REVIEW_TOOL = {
  name: 'submit_review',
  input_schema: {
    properties: {
      ok: { type: 'boolean' },         // true = дефектів не знайдено
      fixedContent: { type: 'string' }, // повний текст, лише якщо ok=false
    },
    required: ['ok'],
  },
};
// запобіжник: правку приймають, лише якщо виправлений текст
// не коротший за 70% довжини оригіналу — інакше модель відхиляється
// і лишається оригінальний текст без self-review-правки
if (ok === false && fixedContent.length >= content.length * 0.7) { /* ... */ }

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

Білінгвальність: кожна мова проходить усі чотири рівні окремо

Переклад не прирівнюється до правильності. Кожна мовна версія проходить свій незалежний прохід перевірки фактів і окремий self-review — одна мова не успадковує "довіру" від іншої лише тому, що це переклад.

Чому це не просто "ще один AI-виклик зверху"

Різниця — в архітектурі відповідальності. Модель, яка пише текст, і модель, яка його перевіряє, — це окремі виклики з окремими інструкціями: та, що перевіряє, не бачить "намірів" тієї, що писала, лише готовий результат і джерело. А лінк-валідатор — взагалі не AI, а звичайний код, який не можна "переконати" чи "задобрити" гарним формулюванням. Детальніше про те, як грамотно поєднувати пошук за змістом і захист від вигадок, — у статті Гібридний RAG: точний пошук і захист від вигадок AI.

Чому це взагалі важливо

Ризики AI-галюцинацій — це не абстракція для техблогів. Про реальні випадки, коли вигадана деталь від AI мало не призвела до серйозних наслідків, — стаття Галюцинація AI мало не розпочала війну. Застосування схожого підходу до самоаналізу якості AI-системи — в іншому технічному розборі: Архітектура AI-чат-бота, що сам аналізує свою роботу.

Результат на практиці

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