Кто
проверит
факты за ИИ

Откуда берётся враньё

У меня есть учебный курс, который написан ИИ — но не «из головы модели». Сначала собирается корпус источников: университетские материалы уровня Стэнфорда, открытые наработки практиков, репозитории и документация самих компаний-создателей моделей на GitHub. Агент работает с этим корпусом скорее как редактор-переводчик, чем как сочинитель: переводит, упрощает язык, оформляет, сверяет утверждения между источниками и помечает нюансы, где источники расходятся.

И тем не менее. Один из треков — 44 урока, примерно 87 000 слов. Автоматический подсчёт нашёл в нём больше 770 проверяемых утверждений: версии продуктов, цены, даты релизов, проценты из бенчмарков, сравнения «X лучше Y». Каждое может оказаться враньём — даже взятое из приличного источника. Потому что источник тоже стареет, а при переводе и упрощении смысл может сместиться на полтона.

Проверить 770 утверждений руками — дни работы профессионального фактчекера. Для открытого бесплатного проекта такой опции нет. Не проверять — тоже не опция: образовательный текст, который врёт, хуже отсутствия текста. Остаётся путь «ИИ проверяет ИИ». Спойлер: в лоб это не работает, и первая же попытка чуть не сломала мне семь правильных фактов. Зато после всех граблей проверка перестала быть подвигом и стала процедурой: весь трек прогоняется за полчаса, по каждому сомнительному факту — вердикт со ссылками на источники.

flowchart LR
  SRC["Рубеж 1. Корпус первоисточников + правила писателю"] --> ED["Рубеж 2. Агент-редактор сверяет при написании"]
  ED --> TXT["Готовый текст: 44 урока, 770 утверждений"]
  TXT --> AUD["Рубеж 3. Внешний аудит другой моделью, с веб-поиском"]
  AUD --> RD["Читатель"]
  AUD -.->|"переаудит раз в квартал"| TXT

Почему писатель сам себя не проверит

Сначала — почему задача вообще встала, при том что процесс написания и так построен вокруг источников. Первые два рубежа проверки встроены в само написание: собранный корпус первоисточников, поверх него агент-редактор, который переводит, адаптирует и сверяет, плюс веб-поиск по ходу — свежие данные подтягиваются перед каждым уроком. Казалось бы, достаточно.

По моим подсчётам, эти два рубежа отлавливали примерно 70–80% потенциальных ошибок. Оставшиеся 20–30% — четыре класса слепых пятен, и каждый из них проверка при написании не закрывает в принципе.

Первый класс — правдоподобно-устаревшее. Утверждение «Kandinsky — главный выбор для генерации изображений с кириллицей» было правдой в 2024–2025. К моменту аудита конкуренты по кириллице сравнялись. Агент-редактор не пошёл это перепроверять, потому что факт не выглядел сомнительным: он стоял в источниках и был правдой — просто протухшей. Самое опасное враньё — то, которое недавно было правдой.

Второй класс — сравнительные утверждения. «X лучше Y для задачи Z» устаревает за 3–6 месяцев, быстрее любого другого типа фактов. Лидер бенчмарка меняется, тариф конкурента падает вдвое — а текст продолжает уверенно рекомендовать вчерашнего чемпиона.

Третий класс — противоречия между документами. В одном уроке написано, что соцсеть показывает в превью до 250 символов, в другом — 500. Оба урока по отдельности выглядят нормально; враньё видно только при сравнении. Писатель, который пишет урок №23, не держит в голове урок №7 — у него и контекста на это нет.

Четвёртый класс — версии. Названия моделей и продуктов меняются так быстро, что между написанием первого и последнего урока трека успевает выйти новая версия того, о чём шла речь в первом.

Первая попытка: проверяющий на каждый урок

Первое решение было прямолинейным: после написания каждого урока запускать отдельного агента-проверяющего. Он получал файл урока, список фактов, которые писатель сам пометил как «проверить», и инструкцию: сходи в веб, проверь каждое, верни отчёт.

Это работало. На каждый урок находилось один-два блокера; за серию набралось 30 с лишним применённых правок — среди них выдуманная ссылка на Bloomberg, неправильные даты, перевранные цитаты. Если бы эти ошибки уехали в публикацию, их нашли бы читатели, и это другая цена.

Но у подхода оказалось два потолка. Во-первых, деньги: проверка одного урока съедала порядка 100 000 токенов агентского контекста, на трек выходило $80–100 — терпимо разово и неподъёмно как регулярная практика. Во-вторых, воспроизводимость: агент в интерактивной сессии — это не конвейер, а ритуал. Его не запустишь по расписанию, его результаты не сравнишь между прогонами.

Итог раздела: per-lesson проверка во время написания осталась в процессе — она ловит блокеры сразу, пока урок ещё в работе. Но для полного аудита готового трека нужен был отдельный конвейер: дешёвый, параллельный, воспроизводимый. И тут я наступил на самые интересные грабли этой истории.

Парадокс поисковика: «AI-поисковик» отвечал из памяти

Логика подсказывала: если нужен фактчек со свежими данными, бери модель, которая создана искать. Perplexity Sonar Pro позиционируется ровно так — «AI-поисковик», всегда ходит в веб, отдаёт ссылки на источники. На бумаге — идеальный фактчекер.

Я дал ему блок из урока с 12 сравнительными утверждениями и попросил по каждому вердикт: OK, устарело, спорно или ложь — плюс исправленную версию и источники.

Результат меня, честно говоря, ошарашил. Семь из двенадцати верных утверждений он пометил как устаревшие. Существующую модель он «откатил» на две версии назад. Реально вышедший продукт назвал несуществующим. Подтверждённый объём контекста объявил ложью.

flowchart TB
  Q["Фактчекеру дана таблица: 12 верных фактов"] --> CH{"Пошёл ли он в веб?"}
  CH -->|"да: поле sources заполнено ссылками"| OK["Вердикты обоснованы, им можно верить"]
  CH -->|"нет: ответ из памяти, sources пустые"| BAD["7 из 12 верных фактов помечены как враньё"]

Диагноз нашёлся в самом ответе: у большинства вердиктов поле источников было пустым. «Поисковик» не ходил в поиск. Он отвечал из обученной памяти, которая закончилась раньше, чем вышли проверяемые продукты, — и всё, что вышло после её отсечки, добросовестно считал несуществующим.

Теперь главное. Если бы я доверился и применил эти «исправления» автоматически — я бы сломал правильный текст в семи местах. Это худший исход фактчека из возможных: не «пропустил ошибку», а «внёс ошибку в верный текст», причём с чувством выполненного долга.

Кто вообще видит свежие факты

После провала «поисковика» я перестал верить позиционированию и устроил проверку — кто из моделей реально видит свежие факты, а кто живёт в законсервированном прошлом.

Тест был жёстким по построению: за два дня до аудита, 16 апреля 2026, вышла Claude Opus 4.7. Свежее некуда — про неё знает только тот, кто реально ищет в вебе. Я спросил пять разных моделей: знаешь такую, когда вышла, какие особенности?

Результат: из пяти моделей правильно ответила одна — и это, по иронии, был тот самый Sonar Pro. Когда вопрос задан прямо («расскажи про X»), его встроенный поиск включается и работает: точная дата, детали, шесть ссылок. Две модели честно ответили «не знаю», ещё две упали с ошибкой. То есть инструмент, который час назад разметил мне семь верных фактов как враньё, на прямой вопрос ответил идеально. Это и есть ключ к парадоксу: у него работал поиск по прямому вопросу, но не включался при разметке таблицы фактов. Способность искать и привычка искать — разные вещи.

Тогда я прогнал бенчмарк шире: 20 моделей разных вендоров, каждая в двух режимах — со включённым веб-поиском и без. Один и тот же вопрос про свежую модель, три контрольных факта в ответе.

Без веб-поиска дату нашла 1 модель из 20. С веб-поиском — 15 из 20. Второй раунд на двадцати самых свежих моделях дал 18 из 20.

Два парадокса проверки

Парадокс рассуждения: чем дольше модель думает, тем хуже проверяет

К этому моменту лидером моих тестов стал Grok 4.20: с веб-поиском он находил реальные устаревания и не размечал верное как ложное. Возник естественный вопрос: а если включить ему режим рассуждения (reasoning — когда модель перед ответом «думает» развёрнутой цепочкой)? Интуиция говорит: больше думает — точнее проверяет.

Интуиция ошиблась, и красиво. Один и тот же блок с фактами, три режима:

Чем больше модель «думала», тем меньше полезного находила. Сильное рассуждение разбило текст на больше утверждений, но реально устаревшие факты пометило как «всё в порядке». Моё объяснение, на правах гипотезы по наблюдению: токены рассуждения уходят на самопроверку, и при любом сомнении модель откатывается к безопасному вердикту «OK». Сказать «всё в порядке» — это то, за что не накажут. Рассуждение делает модель не точнее, а осторожнее — а осторожный фактчекер бесполезен, его работа состоит в том, чтобы находить проблемы, а не избегать ошибок.

Практическое следствие: для фактчека я выключаю режимы рассуждения. Они хороши там, где задача — построить сложную цепочку. Здесь задача другая: уверенно сходить в веб, сравнить и сказать неприятное.

DISPUTED-спам: как распознать слабого фактчекера за одну таблицу

Параллельно я гонял через ту же задачу ещё полдюжины моделей, и на них проявился третий паттерн — самый полезный для быстрой диагностики.

Слабые модели не говорят «не знаю». Они ставят вердикт «спорно» (DISPUTED) на всё подряд: у одной — 9 из 12 утверждений «спорно», у другой — 8 из 12. Формально модель не ошиблась ни разу: «спорно» нельзя опровергнуть. Фактически она не проверила ничего — переложила всю работу обратно на меня, замаскировав пустоту под взвешенность.

Сильный фактчекер на той же таблице выглядит иначе: 15 уверенных «OK», 2 уверенных «устарело» — и оба настоящие. Он не боится коммититься на вердикт.

Итоговый конвейер: три фазы

Теперь — что в итоге собралось из этих уроков. Важно место конвейера в общей схеме: это третий рубеж, а не единственная проверка. Материал уже собран из первоисточников и уже сверен при написании — внешний аудитор приходит последним, по готовому тексту, незамыленным взглядом другой модели. Это осознанный выбор: у разных моделей разные слепые пятна, и проверять текст той же моделью, которая его писала, — значит унаследовать её ошибки вместе с её уверенностью.

Технически конвейер работает на Grok 4.20 с веб-поиском через прямой API вендора (на агрегаторе-посреднике четыре модели из двадцати у меня периодически возвращали пустой ответ, через прямой API — ноль падений). Три фазы, у каждой своя задача — и принципиально, что это именно три разных прохода, а не один «проверь всё».

flowchart LR
  L["44 урока"] --> P1["Фаза 1: факты, поурочно, веб-поиск, 10 параллельных потоков"]
  L --> P2["Фаза 2: весь трек одним запросом, противоречия, без веба"]
  L --> P3["Фаза 3: сравнительные утверждения, веб-поиск"]
  P1 --> R["JSON-отчёты с вердиктами и источниками"]
  P2 --> R
  P3 --> R
  R --> H["Правки руками: спорное смотрит человек"]

Фаза 1 — факты, поурочно. Каждый урок отдельным запросом: найди все проверяемые утверждения, по каждому сходи в веб, верни JSON с вердиктом, исправлением и источниками (полный промпт — P01 ниже). Десять параллельных воркеров. На моём треке: 533 утверждения, 532 веб-запроса, итог — 451 OK, 28 устарело, 51 спорно, 1 ложь. Плюс 69 внутренних противоречий внутри уроков. Около 15 минут на весь трек.

Фаза 2 — противоречия между уроками. Здесь ход обратный: весь трек целиком в один запрос — 44 урока, около 200 000 токенов контекста. Веб-поиск не нужен вообще: задача не «правда ли это», а «согласуется ли это между собой». Модель находит противоречия фактов между уроками, конфликты терминологии (один термин — три определения в разных модулях), дублирование, использование термина до его введения. Один запрос, 31 секунда. Это единственная фаза, которую невозможно воспроизвести поурочной проверкой — противоречие между уроком 7 и уроком 23 видно только тому, кто читает оба.

Фаза 3 — сравнительные утверждения, отдельным проходом. Самая важная фаза для долгоживущего контента. Она намеренно не проверяет существование продуктов и версий — это сделано в Фазе 1. Она проверяет справедливость сравнений: «X лучше Y для задачи Z» — всё ещё правда? Вердикты свои: «всё ещё верно», «конкуренты сравнялись», «лидер поменялся», «нужен свежий тест», «нет открытых бенчмарков». На моём треке: 237 сравнительных утверждений — 170 всё ещё верны, 52 «сравнялись», 4 «лидер поменялся», 7 устарели.

Почему сравнения вынесены в отдельную фазу, а не проверяются вместе с фактами? Потому что у них другой вопрос к вебу. Для факта достаточно найти страницу релиза. Для сравнения нужно искать бенчмарки, свежие обзоры за последние месяцы, смену лидеров — и промпт Фазы 3 явно говорит модели, что и где искать. Когда я пробовал смешивать, сравнения проверялись по логике фактов: «продукт X существует? да? значит OK» — и протухшие сравнения проходили насквозь.

Итог по объёму и времени на трек из 44 уроков (стоимость привожу один раз, справочно — для тех, кто будет повторять):

Что реально поменялось в тексте по итогам: устаревшая версия модели заменена в пяти с лишним уроках; добавлена вышедшая за два дня до аудита модель; лимит OCR-языков исправлен с «7 языков» на «100+ с русским»; тарифы NotebookLM актуализированы в четырёх уроках; «единственный инструмент с планировщиком» перестал быть единственным; рекомендация длины поста для LinkedIn ужалась с 1300–1600 до 900–1100 символов по свежим данным. Каждая правка — с источником из отчёта.

Конвейер — не разовый трюк под один трек. Следующий, более крупный трек (73 урока) прошёл через него же: 837 проверенных утверждений, 84 применённые правки, 53 исправленных внутренних противоречия. Масштабирование линейное: фазы 1 и 3 параллелятся по урокам, а фаза 2 — всё равно один запрос, сколько бы уроков в него ни влезло.

И одна оговорка, чтобы не продать конвейер как магию: вердикты «спорно» и «лидер поменялся» я всё равно просматриваю глазами перед правкой. Автоматически применять можно только точечные замены версий — всё, что меняет смысл, проходит через человека. Конвейер сужает работу человека с 770 утверждений до пары десятков спорных — но не до нуля.

Отдельный случай: сверка с собственными источниками — без веба и почти без LLM

Всё, что выше, проверяет факты о внешнем мире — там без веб-поиска никуда. Но есть второй тип проверки, который я сознательно решаю другими средствами: правильно ли агент собрал текст из уже имеющихся у меня данных. Пересказал ли урок источник без искажений, перенёс ли все числа из таблицы, не потерял ли пункты списка. Гонять для этого модель с веб-поиском — стрелять из пушки мимо воробья: веб тут вообще ни при чём, эталон лежит на диске.

Здесь принцип такой: чем детерминированнее проверка, тем раньше она стоит в цепочке. Сначала обычный скрипт: вытащить из источника и из пересказа все числа, версии, названия, пункты — и сравнить как множества. Это бесплатно, мгновенно и не галлюцинирует: скрипт не умеет «увериться» в совпадении, которого нет. Расхождение — в отчёт, без всякого ИИ.

Смысловые искажения, которые точным сравнением не поймать, ловит векторная сверка. Текст источника и пересказ режутся на куски, каждый кусок переводится в эмбеддинг — числовой отпечаток смысла, по которому можно мерить близость двух фрагментов. Для каждого куска пересказа ищется ближайший кусок источника: если близость низкая, пересказ говорит то, чего в источнике нет, — это кандидат на разбор. У меня вся поисковая база курса и так живёт в векторах, так что инструмент уже под рукой.

И только подозрительные пары — кусок пересказа плюс ближайший кусок источника — отдаются модели с вопросом «передан ли смысл верно». Цепочка скрипт → векторы → LLM сужает работу модели с «прочитай всё и найди искажения» до «сравни два абзаца» — а на узкой задаче модель ошибается на порядок реже. Одна честная оговорка: векторная близость хорошо ловит «в источнике этого нет», но плохо отличает законную переформулировку от тонкого искажения смысла — поэтому она сито, а не судья. Финальное слово на спорных парах — за моделью и человеком.

Промпт фактчекера — основа Фазы 1, подставьте свою дату и тематику. Ключевые места: принуждение к поиску в каждом факте, запрет вердикта без источника, явный список того, что игнорировать. В копируемом файле длинные тире заменены на запятые и двоеточия — это требование к рабочим файлам, а не к тексту статьи.

Ты fact-checker образовательного контента. Сегодня <месяц год>.

Обязательно используй веб-поиск для каждого проверяемого факта,
не полагайся на свою память: она устарела.

Задача:
1. Прочитай весь документ.
2. Выдели ВСЕ проверяемые утверждения: версии продуктов, даты,
   цены, лимиты, числа, сравнения, цитаты, имена и должности.
3. По КАЖДОМУ сделай веб-поиск и проверь актуальность на <месяц год>.
4. Поставь вердикт: OK, OUTDATED, DISPUTED или FALSE.
5. Если нужна правка: предложи точную correct_version.

Игнорируй: общие рассуждения, методические советы ("может помочь",
"бывает полезно"), очевидные факты, цитаты-антипримеры в кавычках.

После фактов проверь внутреннюю согласованность документа:
не противоречат ли утверждения друг другу.

Верни СТРОГО JSON:
{
  "claims": [
    {
      "claim": "точная цитата, до 250 символов",
      "verdict": "OK|OUTDATED|DISPUTED|FALSE",
      "reasoning": "почему, 1-2 предложения",
      "correct_version": "если нужна правка, иначе пусто",
      "sources": ["url"]
    }
  ],
  "internal_inconsistencies": [
    {"description": "...", "locations": ["..."], "suggested_fix": "..."}
  ]
}

Вердикт OUTDATED или FALSE без заполненного sources недопустим.
Только JSON, без пояснений вокруг.

Первый рубеж: прививка от вранья агенту-писателю

Всё, что выше, — проверка постфактум. Но дешевле всего ошибка, которая не родилась. Поэтому первый рубеж живёт не в конвейере, а в правилах агента-писателя — в его мастер-промпте. Эти правила я вывел не из теории, а из конкретных случаев вранья моих же агентов.

Случай, который меня добил: агент написал в отчёте «эту систему мы доводили полтора месяца». Звучит солидно, фактура для текста отличная. Я полез в историю репозитория: вся работа заняла два дня. Агент не «ошибся» — он сгенерировал правдоподобную длительность, потому что «полтора месяца доводили» звучит как нормальная человеческая история. С тех пор в мастер-промпте стоит жёсткое правило: любое утверждение о давности и длительности — только после проверки по датам файлов или истории коммитов. Нет проверки — пиши «не знаю когда, проверю», а не число.

Второе правило оттуда же: число без источника не пишется. Цена, процент, размер, латентность — рядом обязан стоять источник: файл, вывод команды, ссылка. Не нашёл источник — пиши «требует проверки» прямо в тексте. Это неприятно выглядит в черновике и ровно поэтому работает: помеченное «требует проверки» дойдёт до проверки, а уверенно написанное враньё — нет.

Третье: сначала улика, потом гипотеза. Агент, который пишет «вероятно, дело в X, сейчас проверю», уже отравил текст догадкой — даже если потом проверит. Порядок обязан быть обратным: открой файл, процитируй, что увидел, и только потом выводи. То же самое с возражениями: если я говорю агенту «по-моему, тут неправда», правильная реакция — не защищать написанное и не каяться, а молча перепроверить по первоисточнику и вернуться с цитатой. Согласие под давлением — то же враньё, только вежливое.

Эти правила — копипастный блок P02. Они переносимы на любого агента в любом проекте: это не про мой курс, это про то, что генеративная модель по умолчанию оптимизирует правдоподобие, а не правду, и рамку правды ей нужно ставить снаружи.

Правила обращения с фактами. Без исключений.

1. Число без источника не пишется. Цена, процент, размер, версия,
   длительность: рядом источник (файл, вывод команды, ссылка).
   Нет источника: пиши "требует проверки", не пиши число из головы.

2. Давность и длительность только после проверки. Перед любым
   "месяц назад", "делали N недель", "старый код": проверь дату
   по файловой системе или истории коммитов. Нет проверки:
   пиши "не знаю когда, проверю".

3. Сначала улика, потом вывод. Не выдвигай причину, пока не
   процитировал файл, лог или вывод команды, который её доказывает.
   Порядок в ответе: что проверил, что увидел, что это значит.

4. При возражении пользователя: не защищайся и не соглашайся.
   Молча перепроверь по первоисточнику и вернись с цитатой.
   Если был неправ: скажи прямо. Если прав: покажи новую улику.

5. Непроверенное помечай явно: "я не проверял X, чтобы подтвердить,
   нужно Y". Уверенная формулировка неуверенного знания запрещена.

Перепроверщик: агент, который не верит отчётам

Последний инструмент из арсенала — на случай, когда работу делал один агент, а доверять ей нужно как своей. У меня для этого есть отдельный агент-перепроверщик: он получает чужой отчёт («сделано 12 правок», «тесты проходят», «функция переименована везде») и заново выводит каждое утверждение из файлов — read-only, без права что-либо менять. Не «похож ли отчёт на правду», а «вижу ли я это в коде своими глазами». Возвращает таблицу: утверждение → подтверждено/не подтверждено → чем именно.

Зачем это, если писавший агент и так старался? Затем же, зачем Фаза 2 читает весь трек целиком: автор не видит своих ошибок в принципе, у него на них то же слепое пятно, которое их породило. Перепроверщик — это институциализированное недоверие, и оно дешёвое: read-only агент с узким набором инструментов стоит копейки по токенам.

Ты независимый аудитор. Тебе дан отчёт другого агента о выполненной
работе. Не верь ни одному утверждению из отчёта.

Для каждого проверяемого утверждения (изменён файл, добавлена функция,
проходят тесты, настроен сервис, число N):
1. Заново выведи истину из первоисточника: открой файл, запусти
   проверку, найди строку.
2. Зафиксируй, что увидел сам, с точным путём и цитатой.

Тебе запрещено что-либо менять. Только чтение и проверка.

Верни таблицу:
| Утверждение из отчёта | Вердикт | Доказательство |
Вердикты: CONFIRMED, NOT CONFIRMED, PARTIAL.
Для NOT CONFIRMED и PARTIAL: опиши расхождение точно.

Грабли: где конвейер ошибался сам

Честная часть. Конвейер, который ловит чужое враньё, тоже врёт — и его враньё опаснее, потому что приходит с печатью «проверено».

Факты гниют с разной скоростью

Последнее, что важно понять про фактчек ИИ-контента: это не событие, а процесс. Текст, проверенный сегодня, начинает протухать завтра — но неравномерно.

Быстрее всего гниют сравнительные утверждения — те самые «X лучше Y»: 3–6 месяцев, и лидер мог смениться. На моём треке из 237 сравнений 52 уже были в состоянии «конкуренты сравнялись» и 4 — «лидер поменялся», притом что треку было меньше полугода. Следом — цены и тарифы. Версии живут до года. Дольше всего держатся методики и принципы — они почти не протухают.

Отсюда регламент, который у меня теперь закреплён: полный трёхфазный аудит — после написания трека, перед публикацией. Дальше — повторная Фаза 3 (только сравнения) раз в квартал, плюс Фаза 1 на самые динамичные уроки — обзоры моделей и инструментов. По затратам это полчаса машинного времени по расписанию — за то, чтобы образовательный контент не превращался в музей.

Чем это живёт дальше

Конвейер живёт: квартальные переаудиты стоят в календаре, правила из P02 — в мастер-промпте каждого моего агента, перепроверщик запускается после любой крупной агентской работы. Из разовой попытки «проверить трек перед публикацией» это превратилось в постоянный слой инфраструктуры — такой же, как бэкапы: незаметный, пока не понадобился, и окупающийся первым же пойманным «полутора месяцами», которых не было.