Модель как источник: профиль ошибок и способы проверки

Две крайности, одинаково мешающие работать.

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

Вторая: «модель врёт, я ей не пользуюсь». Приводит к тому, что человек тратит сорок минут на подъём от симптома к термину — на задачу, где модель отвечает за двадцать секунд, потому что это ровно её сильная сторона.

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

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

Откуда берётся профиль ошибок

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

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

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

Где модель сильнее поиска

Есть задачи, на которых модель объективно быстрее и лучше индекса. Все они объединены одним свойством: вход длинный и неструктурированный, выход короткий или структурированный.

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

Где модель слабее поиска

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

Простое правило маршрутизации:

Как сделать ответ проверяемым

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

1. Требовать якоря, а не утверждения. Просите не ответ, а место, где ответ написан: «назови раздел документации и точное имя параметра, которое нужно искать». Ошибка в якоре обнаруживается за секунды.

2. Требовать разделения знания и предположения. Явно просите пометить, что модель знает, а что достраивает:

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

3. Не подсказывать желаемый ответ. Сравните: «Правда ли, что X быстрее Y?» и «Что известно о производительности X и Y и при каких условиях каждый выигрывает?». Первая формулировка приглашает согласиться. Вопрос без встроенной посылки — единственный способ не поймать соглашательство.

4. Просить контрпример. «В каких условиях этот совет неверен?» — сильный приём: он заставляет породить границы применимости, а границы — это ровно то, что теряется в пересказе.

5. Спрашивать дважды и по-разному. Один и тот же вопрос в двух формулировках (а лучше — в двух сессиях). Расхождение ответов — сигнал, что тема плохо покрыта и надо идти в источник. Совпадение, впрочем, ничего не доказывает.

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

Режим с веб-поиском: что меняется

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

Что улучшается: появляется актуальность; появляются якоря, которые можно открыть; снижается доля выдуманных сущностей.

Что появляется нового:

1. Ссылка есть, но она не подтверждает утверждение. Самый частый дефект. Страница по ссылке про ту же тему, но конкретной фразы там нет или сказано иначе. Проверка одна: открыть и найти утверждение глазами.
2. Качество ответа наследуется от качества выдачи. Если по теме в вебе доминируют пересказы, модель суммирует пересказы. Все проблемы из главы 7 остаются, только теперь они спрятаны за гладким текстом.
3. Потеря датировки. Ответ сводит вместе страницы разных лет без пометок о версиях. Три источника, три версии продукта, один абзац.
4. Инъекция через содержимое страницы. Если модель читает веб, текст на странице может содержать инструкции, адресованные ей. Для агентных режимов с доступом к инструментам это полноценный вектор атаки; разбор — Безопасность и инъекции и Безопасность агентов.

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

Модель внутри вашего рабочего цикла

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

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

Разбор: одна и та же разведка двумя способами

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

Только поиск. Запрос по тексту ошибки даёт форумные обсуждения разных лет. Тридцать минут уходит на то, чтобы через случайно встреченное слово выйти на термин «connection pooling» и понять, что дело может быть в переиспользовании соединений. Ещё двадцать — на поиск нужного раздела документации. Итого около часа, из которых сорок минут — блуждание без словаря.

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

Совмещённый порядок.

1. Модель, две минуты: «Опиши, какие механизмы могут вызывать такое поведение при обновлении HTTP-клиента. Верни список терминов, без решений». Получаем словарь: keep-alive, connection pool, idle timeout, DNS-кэш, retry-on-failure.
2. Проверка терминов, одна минута: каждый ищется в документации клиента. Четыре из пяти находятся, один — нет; отбрасываем.
3. Первоисточник, десять минут: в changelog находится строка про изменившееся умолчание времени простоя соединения. Датировка получена.
4. Эксперимент, десять минут: ставим старое значение, воспроизводим, подтверждаем причину.
5. След, три минуты: запись с формулировкой, ссылкой на строку changelog, версией и командой воспроизведения.

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

Ответ, который нельзя проверить

Отдельная неприятная ситуация: модель дала утверждение, первоисточника нет, эксперимент дорогой. Что делать.

• Понизить статус утверждения до гипотезы и явно пометить это в записи. Гипотеза в документе — нормально; гипотеза, выданная за факт, — нет.
• Найти косвенную проверку. Не «правда ли это», а «что должно быть верно, если это правда» — и проверить следствие, которое дешевле.
• Спросить человека. Один вопрос мейнтейнеру или коллеге закрывает то, на что вы потратите день (глава 10).
• Спроектировать так, чтобы утверждение не имело значения. Часто самый дешёвый ход: если поведение неизвестно, сделайте систему нечувствительной к нему — например, идемпотентной.

Локальные модели и офлайн-работа

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

Экономика: когда что дешевле

Правила, которые стоит сделать привычкой

1. Никогда не устанавливать пакет, имя которого пришло из ответа модели, без проверки в реестре.
2. Никогда не цитировать модель как источник в документе, ADR или постмортеме. В документ идёт первоисточник, который вы открыли.
3. Всегда проверять существование упомянутых методов, флагов и файлов. Одна команда.
4. Открывать приведённые ссылки и искать в них утверждение. Не наличие ссылки, а её содержание.
5. Не спорить с моделью ради проверки. Спор проверяет уступчивость. Проверяет источник.
6. Приносить источник самому там, где это возможно. Это переводит модель из режима памяти в режим обработки — и убирает большую часть профиля ошибок.

Как встроить проверку в рабочий процесс

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

# проверка существования пакета до установки — одной командой
npm view SOME-PACKAGE version 2>/dev/null || echo "ПАКЕТА НЕТ В РЕЕСТРЕ"
pip index versions SOME-PACKAGE 2>/dev/null || echo "ПАКЕТА НЕТ В РЕЕСТРЕ"

# проверка существования флага или метода
mytool --help | rg -- '--suggested-flag' || echo "флага не существует"
python - <<'EOF'
import inspect, somelib
print([m for m in dir(somelib.Client) if 'retry' in m.lower()])
EOF

# фиксация версий, чтобы советы вообще имели смысл
pip freeze | rg -i 'requests|urllib3'
go list -m all | rg 'golang.org/x/net'

Организационные приёмы, которые работают в команде:

• В код-ревью спрашивать про источник, а не про стиль: «откуда взято это значение таймаута?». Один вопрос отсекает целый класс проблем.
• В ADR и постмортемах требовать ссылку. Формулировка «по данным модели» в проектном документе не должна проходить ревью.
• Держать в проекте файл с проверенными фактами — краткие записи вида «утверждение — ссылка — версия — как проверяли». Это тот же след из главы 13, но общий для команды.
• Иметь установленный барьер на установку зависимостей. Проверка реестра, лицензии и уязвимостей до добавления в манифест.

Мини-практика

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

1. Значение по умолчанию у конкретного параметра.
2. В какой версии появилась конкретная возможность.
3. Точная формулировка гарантии из документации.
4. Как называется механизм, который вы опишете своими словами.
5. Какие есть альтернативные подходы к вашей задаче.

Затем оцените ответы по своей экспертизе. Типичный результат: вопросы 4 и 5 — отлично, вопросы 1 и 2 — правдоподобно и неверно, вопрос 3 — близко, но с потерянным условием. Это и есть профиль ошибок, увиденный своими глазами. После такого упражнения маршрутизация вопросов перестаёт быть теорией.

Типичные ошибки

1. Считать уверенный тон признаком точности. Связи нет.
2. Использовать модель как замену первоисточнику в вопросах про версии и лимиты. Это её слабейшая зона.
3. Проверять ответ вопросом «ты уверена?». Проверяется покладистость.
4. Принимать ссылку за подтверждение. Ссылка подтверждает только то, что страница существует.
5. Забывать, что ответ модели не является независимым источником. Он из того же корпуса, что и веб.
6. Не пользоваться моделью там, где она сильна. Сорок минут на подъём к термину — тоже потеря.
7. Передавать в модель то, что нельзя передавать. Секреты, персональные данные, чужой закрытый код — отдельный вопрос политики, который решается до, а не во время работы.

Мини-итог

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

Источники

• Трек ИИ: основы — устройство больших языковых моделей; Токены и контекст — почему длина и границы знания устроены именно так.
• Ji Z. et al. (2023). Survey of Hallucination in Natural Language Generation. ACM Computing Surveys, 55(12) — dl.acm.org/doi/10.1145/3571730.
• Sharma M. et al. (2023). Towards Understanding Sycophancy in Language Models — arxiv.org/abs/2310.13548.
• OWASP Top 10 for Large Language Model Applications — систематизация рисков, включая инъекции через данные: owasp.org/www-project-top-10-for-large-language-model-applications.
• Трек ИИ-агенты — про построение проверок вокруг ответов модели.

Что дальше

Иногда ответа нет ни в документации, ни у модели, потому что вопрос ещё исследовательский. Академический слой: arXiv, Scholar, препринты.