Фактчекинг в эпоху языковых моделей: еще важнее, чем раньше

Редакция «Текстерры»

В 1494 году бенедиктинский аббат Иоганн Тритемий опубликовал трактат De laude scriptorum — «Похвала писцам», в котором защищал ручное переписывание книг. Тритемий не был противником прогресса: он понимал преимущества печатных книг, использовал их для расширения монастырской библиотеки, а сам трактат о ценности переписывания вышел в печатной версии. Но аббат считал, что новая технология не должна вытеснить интеллектуальную дисциплину сохранения и передачи текстов.

Рост числа текстов был действительно взрывным. До печатной революции в Европе насчитывали около 30 тысяч книг, а к 1500 году — всего через несколько десятилетий после Гутенберга — их было уже примерно 10–12 миллионов.

Через полвека после выхода трактата Тритемия ученый-энциклопедист Конрад Геснер даже пожаловался на «запутанное и вредное изобилие книг». И снова, заметьте, это был не луддит, а человек, который сам много работал со знанием и литературой.

Интеллектуалы позднего Средневековья сформулировали проблему, которая сегодня снова встала перед нами: новые технологии удешевления текста создают новые кризисы доверия.

Часть 1. Что меняется в фактчекинге, когда в работе появляется AI

Языковая модель за минуты может собрать тезисы, предложить структуру, переписать фрагмент, найти источники и оформить текстовую заготовку. Поэтому работа, которая сводится только к аккуратному оформлению готового техзадания, действительно дешевеет, но редакторскую работу ИИ не отменяет. Это позиция профессиональных медиа: например, Associated Press пишет, что любой ответ нужно воспринимать как непроверенный исходный материал и применять к нему стандартные методы проверки.

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

Растиражированная ошибка выглядит для модели как надежный факт

В 2018 году исследователи Массачусетского технологического института изучили распространение правдивых и ложных новостей в Twitter (ныне X) за 2006–2017 годы. Они проанализировали примерно 126 тысяч новостей, которые в сумме ретвитили более 4,5 млн раз около 3 млн человек. Вывод был таким: ложные новости распространялись быстрее, дальше, глубже и шире правдивых. В частности, ложные истории ретвитили на 70% чаще, а правдивым историям требовалось примерно в шесть раз больше времени, чтобы дойти до 1500 человек. Важно, что эффект сохранялся даже после удаления ботов из анализа: то есть проблему создавали не только автоматизированные аккаунты, но и люди.

Скучная ошибка может остаться незаметной как для редактора, так и для публики. Яркая же ошибка начинает жить отдельно от текста: ее обсуждают и пересылают друг другу, причем возможные разоблачения просто не физически могут «догнать» первую ложную новость.

Кейс: ошибочная характеристика стала вирусной новостью

Моя редактор-стажер работала над материалом про новую модель автомобиля от клиентского бренда. Я проследила, что редактор связалась с экспертом со стороны клиента, и тот даже прислал фото распечатанных характеристик — все выглядело так, будто у него на руках есть документ.

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

Я насчитала около 40 упоминаний новости на крупных сайтах.

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

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

Мини-чек-лист: как проверять яркие факты

1. Не выглядит ли факт «драматически хорошим» или «драматически плохим»?

2. Как потенциально отреагируют люди, которые разбираются в теме глубже редакции?

3. Что произойдет, если именно этот факт начнут обсуждать отдельно от статьи?

Реальная информация — еще не значит подходящая

После запуска AI Overviews (сгенерированных ответов в поиске Google) пользователи столкнулись со странными советами: есть камни и добавлять клей в пиццу, чтобы сыр не сползал. Здесь интересно то, что это не были нейросетевые галлюцинации в чистом виде. Business Insider разобрал пример с пиццей: рекомендация про клей не была придумана умным помощником, а прослеживалась к шуточному пользовательскому комментарию.

Модели все реже грубо придумывают факты и все чаще находят информацию, которая действительно где-то есть. Но они пока не всегда понимают, что перед ними:

• реальная инструкция от эксперта;

• шутка;

• сарказм;

• форумный троллинг;

• пользовательский опыт, который нельзя обобщать для всех;

• устаревший совет;

• реклама;

• пересказ чужого пересказа.

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

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

И это касается не только источников. Та же ошибка возникает, когда модель правильно называет объект, но неверно понимает его статус в реальной задаче: что с ним можно сделать, где он применим, какие у него ограничения.

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

Недавно я выстраивала систему UTM-меток и попросила языковую модель помочь продумать разметку для всех каналов. В ответе среди прочего она предложила UTM-метку для контента, который появляется в AI-выдаче.

Однако фактически нельзя вручную поставить UTM-метку на материал, на который в будущем сошлется нейросеть. Мы можем разметить ссылку в письме, рекламном объявлении, посте, баннере, партнерском материале или, в крайнем случае, AI-ассистенте — то есть там, где сами управляем размещением ссылки. А нейроответ появляется уже вне нашего интерфейса и не по нашей разметке.

Я была неприятно удивлена: неужели модель этого «не понимает»?

Но нейровыдача — тоже канал трафика. Модель просто хорошо выполнила плохо поставленную задачу и достроила схему там, где нужно было уточнить ограничение. Здесь сработал принцип garbage in, garbage out (мусор на входе, мусор на выходе): для качественного результата критично предложить машине качественные данные.

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

Мини-чек-лист: как проверять жанр и статус источника

1. Это официальный документ, исследование, медиа, блог, форум или соцсеть?

2. Автор говорит как эксперт, очевидец, пользователь, продавец или шутник?

3. Это факт, мнение, реклама, инструкция, кейс или личный опыт?

4. Есть ли у источника заинтересованность?

5. Можно ли использовать этот источник в деловой статье?

6. Не приняла ли модель сарказм или пользовательскую шутку за рекомендацию?

7. Не дала ли модель формально логичное решение, которое неприменимо в реальности?

Модель может домыслить связь между реальными фактами

В 2023 году CNET — крупное медиа о технологиях и потребительской электронике — опубликовало серию материалов, написанных с помощью AI-инструмента. Редакторы давали модели наброски, но финальные тексты проверяли недостаточно глубоко. Серьезный фактчекинг начался уже после того, как к одной из статей появились вопросы, и CNET пришлось выпустить исправления к 41 из 77 AI-материалов.

Для нас тут важно то, что в текстах была не столько прямая ложь, сколько ошибки рассуждений: модель брала реальные финансовые понятия и делала из них неверные практические выводы. Такие ошибки сложнее заметить, чем выдуманную цифру или несуществующий источник, и в результате первые 76 материалов «проскочили» незаметно. В этом и риск: AI-текст может быть последовательным и даже основанным на фактах — и при этом не выдерживать глубокую проверку на смысл.

CNET показывает проблему на уровне статьи: факты могут складываться в неверное рассуждение. А кейс AI Overviews показывает тот же риск на уровне отдельных утверждений: даже когда рядом есть источник, модель не всегда переносит из него именно ту мысль, которую потом выдает пользователю. Авторы исследования по сгенерированным ответам в Google изучили 55 393 трендовых запроса и разложили ответы на 98 020 атомарных утверждений, и по их оценке, 11% утверждений не поддерживались процитированными страницами, а качество источника и точность пересказа оказались независимыми вещами.

Иными словами, хороший источник рядом с ответом еще не гарантирует, что модель правильно перенесла из него мысль.

Кейс: модель связала два несвязанных факта в утверждение

Идея написать статью об уязвимостях мессенджера «Макс» возникла у меня, потому что я наблюдала большое количество сообщений о странных багах. Я попросила нейронку собрать все подобные сообщения и отдельно уточнила, что сначала не нужно проверять правомерность этих сообщений — нужно только найти сами факты сообщений.

В числе прочего модель нашла сообщение о чужих кружочках. Действительно, такое видео существовало. Еще она нашла сообщения о том, что один из частых векторов среди найденных в «Максе» уязвимостей связан с IDOR (классом ошибок, при котором можно получить доступ к чужим данным или действиям).

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

Но так делать нельзя. Здесь есть три разных утверждения, которые надо разделить перед фактчекингом:

1. Видео про баг существует.

2. Сообщения белых хакеров об IDOR существуют.

3. Конкретное видео связано с конкретной уязвимостью.

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

Более того, вручную я нашла то, чего не нашла языковая модель: сообщение о том, что волну обсуждения мог подогреть создатель сервиса, который намеренно воспроизводит эффект «случайного чужого кружка». Но это уже совсем другая история.

Языковой модели можно позволять включать в материал реально существующие факты. Но нельзя позволять ей самовольно устанавливать связь между ними.

Мини-чек-лист: как проверять связку утверждения и источника

1. Источник подтверждает именно эту мысль или только похожую?

2. Не стало ли «может» словом «доказано»?

3. Не исчезли ли оговорки: страна, период, выборка, сегмент?

4. Не выданы ли данные по одной группе за вывод обо всем рынке?

5. Не подменен ли глагол: например, «тестируют» не стало «внедрили»?

6. Не устарели ли данные?

7. Есть ли независимое подтверждение, а не цепочка пересказов?

8. Источник действительно нужен для проверки или просто создает ощущение надежности?

9. Не дала ли модель правильный ответ на неправильно понятый вопрос?

Большая подборка фактов может скрывать неполную картину

Одна из книг, которая сильнее всего изменила мой взгляд на фактчекинг, — «Темные данные» Дэвида Хэнда. Она не про редактуру и не про нейросети, но для редактора там есть очень важная мысль: ошибаться можно не только из-за неверных данных, но и из-за данных, которых мы не видим. Пример: если ориентироваться на Twitter как на сигнал о том, где нужна помощь после урагана, можно не увидеть районы без электричества и мобильной связи. Но не потому, что там все спокойно. Наоборот: там все так плохо, что оттуда просто не поступает сигнал.

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

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

AI усиливает эту проблему. Он может быстро собрать большую подборку фактов, и из-за этого появляется ощущение полноты.

Кейс: модель подтвердила вывод, который уже был заложен в вопрос

Однажды я попросила Comet от Perplexity — AI-браузер, который удобно использовать для первичной карты источников, — собрать тезисы для статьи о том, что интерес к старым книгам растет. Из подборки следовало: да, интерес действительно растет, люди устают от цифрового, ищут вещи с историей, покупают редкие издания, ценят старые переплеты, собирают домашние библиотеки, интересуются винтажом...

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

Как и в примере с UTM-метками, инструмент сделал то, что я и хотела — только теперь я получила не решение вне реального контекста, а неполные данные, что еще опаснее.

Мини-чек-лист: как проверять то, чего нет

1. Кто и что могло не попасть в данные?

2. Не видим ли мы мнения только тех, кто чаще высказывается, публикует кейсы или попадает в медиа?

3. Не делаем ли общий вывод из частного наблюдения?

4. Не может ли быть другой группы данных, которая изменила бы вывод?

5. Что мы бы искали, если бы хотели опровергнуть собственную мысль?

6. Не выглядит ли подборка полной только потому, что модель хорошо структурировала ее?

7. Что отвечает модель, если мы попросим собрать ее факты для противоположных выводов?

Подборку «в пользу противоположного вывода» нужно проверять так же придирчиво, как и первоначальную.

Часть 2. Как использовать AI, не отдавая ему управление смыслом

Способ работы зависит от того, насколько редактор знает тему

У меня нет одной универсальной схемы: все зависит от того, насколько хорошо я знаю тему и какие риски у текста, и я использую как минимум три способа работы с языковой моделью.

В новой теме сначала нужно проверять не текст, а карту фактов

Если я не идеально ориентируюсь в теме, я прошу инструмент с поиском, чаще всего Comet от Perplexity, собрать карту фактов:

• какие есть ключевые данные;

• какие исследования и отчеты часто цитируют;

• какие есть спорные места;

• какие источники выглядят первичными;

• где мнения расходятся.

Но здесь важно помнить историю с букинистикой: карта фактов зависит от того, как сформулирован вопрос. Поэтому я проверяю не только ответ модели, но и собственный промпт. Не задала ли я вывод заранее? Не попросила ли найти подтверждения тому, что еще не доказано? Не сузила ли тему так, что важные данные остались за пределами поиска?

Потом я проверяю подборку вручную. Смотрю, откуда взялись факты, какие источники действительно первичные, где пересказ, где устаревшие данные.

И только после этого вручную формулирую для языковой модели фокус:

• на какой мысли держится статья;

• какие факты можно использовать;

• какие утверждения нельзя усиливать;

• где нужны оговорки;

• чего модель не должна додумывать.

Так я не прошу AI «написать статью по теме», а сначала собираю и проверяю фактическое поле. И только потом использую модель (на этом этапе уже ChatGPT) как помощника в структуре, формулировках и редактуре.

В знакомой теме AI можно раньше допускать к черновику

Если я хорошо знаю тему, я могу дать модели свои факты, тезисы и наблюдения и попросить написать блок, раздел, пост или целый черновик. В этом случае мне сразу заметно, где модель:

• исказила смысл;

• излишне обобщила;

• ушла в банальные аргументы и выводы;

• перепутала термины;

• не попала в TOV;

• добавила что-то лишнее;

• потеряла важную оговорку.

В экспертном материале AI структурирует, но не говорит за эксперта

Если есть интервью, комментарии эксперта или какие-то сырые данные, я использую модели для другой задачи.

Он помогает:

• привести расшифровку к читаемому виду;

• выделить тезисы;

• найти противоречия;

• предложить структуру;

• собрать вопросы на уточнение;

• показать, где не хватает доказательств.

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

Эта статья тоже написана языковой моделью — но, возможно, не так, как вы думаете

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

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

• как изменились навыки редактора;

• почему теперь так важны промптинг и фактчекинг;

• как я работаю с Comet и языковыми моделями;

• почему в одних темах сначала собираю факты, а в других сразу прошу модель собрать контентную единицу на моих тезисах.

Потом привела личные примеры: кейс с автомобилем, историю с UTM-метками, кейс с «Максом», пример с букинистикой.

Затем рассказала, что в книгах по фактчекингу и работе с данными показалось мне интересным и подходящим теме статьи — например, историю про аббата Тритемия и несколько мыслей из «Темных данных» Дэвида Хэнда.

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

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

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

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

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

Текст, который дала мне языковая модель, я на этом этапе превратила в хаотичный рабочий материал, но именно на этой итерации начали вырисовываться смыслы, которые я хотела заложить в статью.

Красивый и стройный текст в новой реальности языковых моделей — не всегда финал работы. Часто это только ее начало.

Занятный факт: без AI-инструментов я, скорее всего, написала бы статью о фактчекинге за один рабочий день, а с ними работа заняла... больше двух дней. Но вырос сам масштаб задачи! Я смогла добрать больше зарубежных исследований, проверить больше источников, перебрать несколько композиций статьи — структура, которую вы видите, пятая (!) по счету, — увидеть слабые связи, пересобрать материал и сделать его хотя и не быстрее, но гораздо глубже.

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

Проверка AI-текста начинается с логики сборки фактов

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

Вот сводный чек-лист того, о чем следует спросить себя перед публикацией.

1. Цифры и статистика. Откуда число? За какой период? По какой выборке? Не устарело ли? Не потеряла ли модель оговорку?

2. Даты и текущие статусы. Действует ли закон? Работает ли сервис? Не изменилась ли должность человека? Не обновились ли правила платформы?

3. Имена, названия, должности. Не перепутала ли модель похожие сущности или не подтянула ли старую информацию?

4. Исследования и отчеты. Существует ли исследование? Кто его провел? Есть ли методология? Не пересказывает ли модель пресс-релиз или чужой пересказ?

5. Цитаты. Человек правда это говорил? В каком контексте? Не изменила ли модель формулировку?

1. Причинно-следственные связи. Из того, что два явления совпали, не следует, что одно вызвало другое.

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

3. Необычные факты. Чем ярче факт, тем выше риск, что ошибка разойдется отдельно от текста. Яркие факты не всегда ложные, но в них часто есть нюансы.

1. Источники с AI-ответами. Если факт пришел из Comet, ChatGPT Search, AI Overview или другого инструмента, проверяем не только ответ, но и источники под ним.

2. Жанр источника. Не приняла ли модель шутку, форумный опыт, рекламу или частный случай за факт?

3. Ложные связи. Не связала ли модель два реальных факта так, будто один доказывает другой?

4. Отсутствующие данные. Какие группы, кейсы, рынки или мнения не попали в картину?

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

AI в фактчекинге подходит не для каждого проекта

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

— Я не использую нейросети для фактчекинга. Мы работаем с живыми авторами, и уже во время написания статьи автор прикрепляет ссылки на источники информации, которые я проверяю. Конечно, можно было бы избавить авторов от лишних телодвижений, но на данном этапе развития AI нейросеть просто не справляется с проверкой фактов.

Дело в том, что искусственный интеллект не способен осмыслить понятие «достоверность». Наберите любой запрос в поисковике — и в первую очередь вам предложат как достоверный источник «Википедию». Для AI это эталон. Но сама по себе статья «Вики» всегда требует перепроверки. Ее главное достоинство не содержание, а список источников, приведенный в конце. Каждый из них нужно просмотреть: «Википедия», например, может сослаться на развлекательный сайт без выходных данных, и это ненадежный источник информации. А еще автор статьи может допустить опечатку или некорректно пересказать текст из первоисточника. Поэтому для редактора «Википедия» — не достоверный источник.

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

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

Евгения Сосина

редактор TexTerra

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

Проверь текст как редактор-фактчекер. Не подтверждай факты окончательно и не придумывай источники. Твоя задача — найти зоны риска, которые редактор должен проверить вручную.

1. Выпиши утверждения, которые требуют проверки: цифры, даты, имена, характеристики, законы, исследования, цитаты, причинно-следственные связи и обобщения о рынке или поведении людей.

2. Отметь утверждения, которые звучат слишком ярко, необычно или категорично.

3. Проверь, где источник должен подтверждать именно текущую формулировку, а не похожую мысль.

4. Найди места, где могли исчезнуть оговорки: страна, рынок, период, выборка, аудитория, сегмент бизнеса.

5. Отметь, где может быть перепутан жанр источника: шутка, форумный опыт, реклама, мнение, инструкция, исследование.

6. Отметь, каких данных может не хватать для вывода.

7. Если факт нельзя подтвердить по имеющемуся тексту, напиши: «нужно проверить вручную».

8. В конце составь таблицу: утверждение — риск — что проверить — где искать подтверждение — как можно смягчить формулировку.

Седьмой и восьмой пункты очень важны! По моему опыту, даже бесплатные языковые модели реже фантазируют, если прямо попросить их отмечать места, где данных недостаточно. Это не гарантия от галлюцинаций и ошибок, но качество проверки повышается.

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

Бизнесу нужен не автор черновика, а редактор, который отвечает за доверие

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

AI-инструменты делают похожую вещь. Они не отменяют редактора, а смещают фокус его работы. Редактор нужен, чтобы:

• понять, зачем компании этот текст;

• сформулировать одну главную мысль;

• собрать факты вокруг этой мысли;

• проверить яркие утверждения;

• проверить связку утверждения с источником;

• отличить подходящий источник от неподходящего;

• увидеть ограничения данных;

• заметить странные утверждения;

• задать вопросы эксперту;

• сохранить TOV бренда;

• защитить компанию от правдоподобной ошибки;

• довести текст до состояния, где он закрывает бизнес-задачу.

AI может помочь написать, сократить, структурировать, найти варианты и ускорить черновик. Но пока он не может взять на себя ответственность за смысл.

Читайте также:

Что такое «продающие тексты» в 2026 году и как бизнесу их заказывать

От текстов к бизнес-результату: 7 тезисов о новой роли главреда

Zero-click search и AEO: новая реальность поиска, которую брендам нужно понимать сейчас