Давайте дружить в Телеграме: рассказываем про новые фичи и общаемся в комментах Подписаться
support@serv.host
Личный кабинет

Почему ИИ делает не то, что просили, и врёт слишком правдоподобно.

Почему ИИ делает не то, что просили, и врёт слишком правдоподобно.

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

Сторонний мой проект: Zapret2UI.

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

Есть базовая проблема ИИ, которая думаю всем знакома - попросил сделать что-то очень простое и она просто сломала весть твой проект/текс/whatever. Важно понимать, что запрос очевиден ТОЛЬКО ДЛЯ ВАС САМИХ

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

Содержание

  1. Модель не угадывает границы
  2. Разбор четырёх провалов
  3. Запрос «сделай хорошо» обречён
  4. Почему договорённость плывёт к середине разговора
  5. Как формулировать, чтобы попадало
  6. Откуда берётся враньё
  7. Три вида вранья, и опаснее всех второй
  8. Почему модель соглашается, когда вы неправы
  9. Протокол верификации
  10. Частые ошибки
  11. Короткий итог

Источники

Модель не угадывает границы

Вот главное, что стоит понять про весь этот жанр общения.

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

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

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

Это не баг и не тупость(хотя некоторые агентные модели реально тупят). Это ровно то поведение, которого от такой системы следует ожидать, если понимать, как она устроена. Обидно только, что понимаешь обычно уже после того, как твой проект переколбасило.

Разбор четырёх провалов

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

Думаю всем очевидно, что не использовать ИИ в работе с текстом сейчас - бред. Я Как раз в написании своих статей использовал нейросети

Важная помарка, использовал и написал всё статью по теме - не одно и то же.

Провал первый: не указана граница правки

Просил: «содержание поплыло по смыслу, расставь нормально, структуру по содержанию не собрал нормально, поменяй».

Получил: перекроенную статью, которую модель решила просто поменять сама(именно внутренности статьи). Хотя я указывал четко(как мне показалось изначально), что работу надо вести с содержанием.

Что произошло: слово «содержание» в русском означает и оглавление, и смысловое наполнение. Первое прочтение узкое, второе широкое. Модель взяла широкое. Плюс «расставь нормально» не содержит ни намёка на то, что менять можно только порядок строк.

Как надо было: «в блоке оглавления поменяй местами пункты 4 и 5, больше в файле ничего не трогай». Как бы тупо это не звучало - это был бы идеальный промт, который бы четко ответил на мою задачу(ну почти, для понимания думаю хватит этого)

Провал второй: правдоподобное соседство вместо реальной связи

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

Была задача придумать заголовок для статьи про транспорты в прокси. Вышло вот такое: «Транспорты прокси: WebSocket+TLS vs gRPC vs XHTTP vs Reality». Которое ушло в опрос в тг чате servhost(кто видел, тот видел).

Смотрится складно. Только Reality никакой не транспорт. В конфиге транспорт задаётся полем network, а Reality живёт в поле security, это разные оси, и они крутятся независимо. В один ряд их поставить нельзя, это как сравнивать «поезд, самолёт, автобус и красный».

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

Ловится это только знанием предмета. Меня тогда поймали вопросом «а причём тут Reality?», и вопрос был по делу. Я не перепроверил название топика, и просто создал пулл, который по факту с названия был уже ошибкой.

Провал третий: пропущенное слово в вопросе

Так же есть неточности в вопросе. Представим, у вас есть чат, в котором вы обсуждаете определенную тему. Допустим это настройки xray. ИИ не понимает что вы спрашиваете, если не даете конкретики, пример ниже.

Спросил: что делает поле fingerprint: "random".

Получил: «при каждом соединении выбирается случайный отпечаток».

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

Разница принципиальная: в первом варианте вы каждый раз выглядите по-новому, во втором - вы весь сеанс выглядите одинаково, просто непредсказуемо для того, кто не видел старта. Для маскировки это две совершенно разные ситуации.

Что тут сработало: модель ответила на вопрос «что означает слово random в этом контексте», а спрашивал я «как эта штука работает». Формально ответ верный, практически - не точный

Провал четвёртый: точное описание неверного механизма

Немного разбор про ценность ответов ИИ. При обучении нейеросетей их «хвалили» за ОТВЕТ, даже есть он в корне неверный, лучше придумать правдоподобный ответ, который будет звучать хорошо, даже лучше, чем факт(чуть подробно разберем ниже отдельно).

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

Написалось так: «в линуксе за это отвечает net.ipv4.icmp_ratelimit, он ограничивает ответы на пинг».

Полез сверять с документацией ядра. И выяснилось: есть вторая настройка, icmp_ratemask, битовая маска типов ICMP, на которые ограничение вообще распространяется. Дефолтное значение 6168 разворачивается в типы 3, 4, 11 и 12. Echo Reply, то есть ответ на обычный пинг - это тип 0, и в маске его нет. Линукс по умолчанию ответы на пинг этим механизмом не режет вообще.

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

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

Кстати, после проверки объяснение стало лучше исходного: в маске есть тип 11, Time Exceeded, а это ровно тот пакет, которым роутер отвечает на traceroute-зонд. То есть режется именно то, из чего строятся промежуточные строки трассировки. Правильный ответ оказался и точнее, и интереснее. Так обычно и бывает.

Запрос «сделай хорошо» обречён

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

Те самые видосы. Make me rich pls. AI SaaS no mistakes

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

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

Чинится тремя способами, по возрастанию надёжности:

  • Числом. Не «покороче», а «сократи примерно вдвое, до полутора тысяч знаков».
  • Запретом. Не «сделай нормально», а «оставь структуру как есть, правь только формулировки внутри абзацев».
  • Образцом. Самый сильный вариант: «вот кусок текста, который мне нравится по тону, сделай так же». Модели гораздо лучше даётся подражание конкретному образцу, чем следование тому, что сама ИИ нашла или же неверно поняла.

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

Важно понимать, что ИИ это инструмент, его можно использовать хорошо, а можно плохо. Не имеет смысла писать, то, что Вы сами не в состоянии объяснить.

Почему договорённость плывёт к середине разговора

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

Тут иногда обижаются, дескать, «оно меня не слушает». Механика скучнее и понятнее.

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

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

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

Вторая интереснее и не так очевидна. Даже когда всё ещё влезает, информация из середины длинного текста используется хуже, чем из начала и конца. Это разобрано в работе с говорящим названием «Lost in the Middle»(в источниках найти можете): качество извлечения нужного факта заметно проседает, если он лежит в середине, и это воспроизводится даже на моделях, специально заточенных под длинный контекст.

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

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

Есть агенты, которые могут сохранять в работе с проектами в память что-то важное для Вас, нейронке главное ответить, о чем писал выше. Так же есть скиллы, которые дают нейронке вспомнить что-то важное.

Тут я останавливаюсь, потому что про устройство контекста и памяти можно писать отдельную статью, честно говоря не уверен, что хочется.

Как формулировать, чтобы попадало

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

Задавайте границу явно. Самая полезная фраза во всём общении с ИИ - «больше ничего не трогай»/«Работай только с этим файлом». Звучит грубо, работает отлично. Без неё широкая трактовка победит.

Говорите, что нельзя, а не только что нужно. Запрет однозначнее пожелания. «Не меняй структуру», «не добавляй новых разделов», «не переписывай примеры» - каждая такая фраза отсекает целый класс промахов, которые точно будут(если работа большая, то тем более.) Всё не упомянуть, надо использовать всё приёмы.

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

Разбивайте составные задачи. Запрос «поправь это, потом сделай то, а ещё проверь вот это» выполнится неровно: что-то сделается тщательно, что-то по касательной. Три отдельных запроса дают три нормальных результата. Не имеет смысла давать много задач, когда вы можете сделать тщательно вообще всё отдельными запросами.

Проверяйте формулировку на двусмысленность до отправки. Перечитайте свой запрос и спросите: можно ли это понять иначе? Если да, вас поймут иначе. Двадцать секунд на перечитывание экономят три круга переделок. Будьте готовы к тому, что вас всегда могут понять неправильно.

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

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

Переходим ко второй половине. Запрос вы сформулировали идеально, ответ получили осмысленный, а он всё равно врёт. Почему.

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

Никакого внутреннего сигнала «тут я не уверен» в тексте не появляется. Вот это и есть корень проблемы: уверенность ответа никак не связана с его правильностью.

Есть и вторая причина, менее очевидная и довольно ехидная. В сентябре 2025-го исследователи OpenAI и Georgia Tech выпустили работу с прямым названием «Why Language Models Hallucinate»(тоже в источниках), где разбирают вопрос со стороны обучения. Вывод такой: сама процедура тренировки и оценки поощряет угадывание, а не признание незнания. Модели гоняют по тестам, где за ответ «не знаю» ставят ноль, а за угаданный ответ - балл. Как школьник на экзамене с угадайкой: молчать невыгодно, тыкать наугад выгодно. Вот и натыкали.

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

Как и разбирали выше - лучший вариант, это источники, и ручная проверка, того, что вам пишет ИИ.

Три вида вранья, и опаснее всех второй

Полезно различать, потому что ловятся они по-разному и стоят разного.

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

Второй: ложная точность. Реальная вещь описана через неправильный механизм. Поле существует, значение существует, работает не так, как сказано. Оба случая из разбора выше - fingerprint: "random" и icmp_ratelimit - ровно про это.

Вот этот вид и есть настоящая беда. Проверить его дорого: надо лезть в исходники или в RFC, потому что документация часто описывает намерение, а не то, что реально в коде. При этом читается он убедительнее всего остального, ведь конкретика всегда звучит достовернее общих слов. Вы получаете точное, детальное, уверенное и неверное объяснение, и никакого повода усомниться в нём нет.

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

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

Этот вид коварен по-своему: он гуглится. Вы идёте проверять, находите три статьи, которые подтверждают, успокаиваетесь. А статьи трёхлетней давности, и их много ровно потому, что у них было три года на накопление. Этот механизм и то, во что он выливается на практике, я подробно разобрал в отдельной статье про ИИ в технической работе(Ещё не вышла на момент написания), там как раз живые примеры вырезанных полей.

Почему модель соглашается, когда вы неправы

Приходите с готовым мнением - получаете подтверждение. Приходите с противоположным - получаете подтверждение снова. Штука известная, называется подхалимством, и она измерена.

Anthropic(Claude) в 2023-м выпустила работу «Towards Understanding Sycophancy in Language Models»: там прогнали пять топовых ассистентов и нашли это поведение у всех. Дальше авторы полезли в сами данные обучения и нашли причину: когда людей просят выбрать лучший из двух ответов, совпадение ответа с мнением спрашивающего оказывается одним из самых сильных предикторов выбора. То есть люди систематически предпочитают ответы, которые им поддакивают. Модель обучили на этих предпочтениях, она их и воспроизводит. Никакой мистики, чистая механика: обучили угождать - угождает.

Насколько это может уехать, показал апрель 2025-го. OpenAI выкатила обновление GPT-4o, которое настолько усилило эту черту, что модель начала одобрять откровенно вредные решения пользователей. Через три дня обновление откатили и выпустили разбор полётов, где прямо написали: слишком сильно ориентировались на краткосрочную обратную связь от пользователей. То есть на то, что людям нравится, а не на то, что верно. Ровно тот же механизм, только доведённый до абсурда за одно обновление.

Практических выводов два, и оба контринтуитивные.

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

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

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

Можно считать, что моя база в работе с ИИ

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

Запомни на текущий чат

Агенты часто любят придумать проблему и сразу делать базу под её решение, а возможна ли она в твоей задаче - не важно ему

Протокол верификации

Что реально делаю, когда цена ошибки высокая.

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

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

Иерархия доверия у меня такая: исходный код, потом RFC и спецификации, потом официальная документация, и только потом всё остальное. Документация отстаёт от кода, иногда на годы. А блоги врут хором: один написал неточность, двадцать переписали, и получается двадцать независимых подтверждений одной ошибки. Которй изначально при хорошей работе бы ВООБЩЕ не должно было возникнуть.

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

На свежих темах доверие по умолчанию нулевое. Не «проверю, если засомневаюсь», а «проверю всё, потому что тема новая».

Спрашиваю на опровержение, а не на подтверждение. Про это выше целый раздел.

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

Частые ошибки

  • Оставлять границу незаданной. Не сказали, что трогать нельзя, - будет широкая трактовка. Всегда.
  • Просить «сделай хорошо». Критерий живёт у вас в голове, в запросе его нет. Число, запрет или образец.
  • Ссылаться на договорённость из начала длинного диалога. Она уже вытеснена или лежит в середине, откуда извлекается хуже всего. Повторяйте.
  • Верить уверенному тону. Уверенность в ответе не связана с его правильностью никак. Один и тот же тон у проверенного факта и у выдумки.
  • Спрашивать «правильно ли я понял». Формулировка сама тянет за собой согласие. Спрашивайте «что здесь неверно».
  • Считать список источников в конце подтверждением. Он не подтверждает ничего. Требуйте ссылку рядом с фактом(забавно, что у меня будут источники в конце, но я-то перепроверяю. Вы тоже проверить меня можете.)
  • Проверять по блогам. Двадцать статей с одной и той же ошибкой не делают её правдой, они просто переписаны друг у друга. Необходимо проверять оффициальную информацию
  • Одинаково доверять старым и новым темам. Чем свежее технология, тем меньше её в данных и тем охотнее достраивается правдоподобное.
  • Валить в один запрос три задачи. Часть выполнится тщательно, часть по касательной, и не угадаешь какая будет итоговая работа.

Короткий итог

  • Незаданная граница берётся широкой. Не потому что модель тупая, а потому что широкое прочтение встречается в текстах чаще узкого. «Больше ничего не трогай» - самая полезная фраза в этом жанре.
  • Половина смысла вашего запроса живёт в контексте, которого у модели нет. Коллега его достроит из ситуации, модель - нет.
  • «Сделай хорошо» не работает, потому что критерий не сформулирован. Число, запрет или готовый образец.
  • Памяти между сообщениями не существует. Диалог целиком подаётся заново каждый раз, старое вытесняется, а середина длинного контекста используется хуже краёв. Важное повторяйте.
  • Уверенность ответа не связана с его правильностью. Выдумка выглядит ровно так же, как проверенный факт, никакого сигнала «тут я не уверен» в тексте нет.
  • Опаснее всего ложная точность: реальная вещь, описанная через неверный механизм. Проверять дорого, звучит убедительнее правды, и именно этот тип чаще всего доезжает до текста.
  • Подхалимство измерено и объяснено: совпадение с мнением спрашивающего - один из сильнейших предикторов того, какой ответ люди назовут лучшим. Модель обучена на этих предпочтениях, спорьте с ней.
  • Разворачивайте это себе на пользу: просите аргументы против своей позиции, а не за неё.
  • Иерархия доверия: исходники, спецификации, документация, всё остальное. Документация отстаёт, блоги переписывают друг у друга.

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

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

Сторонний мой проект: Zapret2UI.

Источники