Как языковая модель строит ответ — и откуда берутся уверенные ошибки

Сначала текст превращается не в смысл, а в токены

До работы модели строка проходит токенизатор. Он нормализует ввод, делит его на предварительные фрагменты, применяет выученный словарь и получает числовые идентификаторы. Частое слово может стать одним токеном, редкое — несколькими частями; пробел или знак препинания тоже влияет на разбиение. Поэтому «тысяча слов» и «тысяча токенов» — не одно и то же.

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

В контекст попадают системные инструкции продукта, вопрос, предыдущие сообщения, вставленные документы и иногда результаты инструментов. Все эти элементы конкурируют за ограниченный объём и могут противоречить друг другу. Как именно роли оформляются и сколько места доступно, зависит от конкретного API и версии. Само наличие фрагмента во входе ещё не доказывает, что модель правильно его использовала.

Наглядная схема токенов, контекста и вероятностей

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

Вероятность относится к продолжению последовательности, а не к истинности утверждения во внешнем мире. Если в контексте часто встречается убедительная, но ошибочная связка, модель может продолжить её уверенно. Если вопрос содержит ложную предпосылку, задача next-token prediction не обязана остановить разговор и провести расследование, хотя обучение и системные инструкции могут повышать вероятность осторожного ответа.

Почему связный текст не равен найденному факту

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

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

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

Temperature управляет разнообразием, а не правдой

После расчёта кандидатов система должна выбрать продолжение. При более концентрированной стратегии обычно чаще выбираются верхние кандидаты; при более широком sampling появляются менее вероятные варианты. Temperature меняет форму распределения, top-p ограничивает набор накопленной вероятностью, top-k — количеством кандидатов. Конкретные параметры и допустимые диапазоны определяет библиотека или API.

Снижение temperature может сделать ответ стабильнее между запусками, что удобно для извлечения полей. Оно не проверяет дату, документ или расчёт. Если самый вероятный вариант опирается на устаревший шаблон, детерминированный выбор повторит ошибку последовательнее. Для творческого черновика разнообразие может быть полезно, а для фактического ответа важнее grounding и проверка источника.

Большой контекст тоже требует измерения

Поставщики указывают максимальный размер входа, но эта цифра описывает возможность принять последовательность, а не гарантированно извлечь каждую деталь. Исследование Lost in the Middle показало, что позиция релевантной информации способна заметно менять результат на задачах с длинным контекстом. Нельзя считать загрузку целого архива эквивалентом точного поиска по нему.

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

Три типа ошибки требуют разных действий

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

Как проверять ответ по атомарным утверждениям

1. Выделите фразы, на которых основано решение: число, дата, правило, причинная связь, условие продукта.

2. Для каждой фразы запросите источник и точный фрагмент, а не общий список литературы.

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

4. Отделите то, что прямо сказано, от расчёта и редакционного вывода.

5. Если источники конфликтуют, сохраните конфликт и не заставляйте модель выбирать без критерия.

6. Для расчёта повторите вычисление независимым инструментом; для кода запустите тест.

7. При отсутствии доказательства оставьте UNKNOWN вместо правдоподобного заполнения.

Пример: ответ утверждает, что сервис «не хранит запросы и никогда не использует их для обучения». Это две разные проверяемые фразы. У продукта могут различаться consumer и business режимы, срок хранения для abuse monitoring и отдельная настройка обучения. Одна маркетинговая страница не обязательно покрывает все условия. Нужны актуальные документы именно выбранного тарифа и endpoint.

Практический следующий шаг: построить карту доверия

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

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

Как собрать проверяемый рабочий режим

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

Для повторяемых задач используйте структурированный результат. Schema может требовать обязательные поля, типы, допустимые значения и отдельное UNKNOWN. Валидная структура не гарантирует истинность, но не позволяет скрыть отсутствие даты внутри гладкого абзаца. Числа пересчитывайте кодом, ссылки проверяйте на существование и соответствие, цитаты сопоставляйте с точным фрагментом.

Сравнивайте модели и промпты на одном закрытом наборе примеров. Включите простые случаи, неоднозначность, устаревший факт, конфликт источников, длинный вход и вопрос без ответа. Фиксируйте model ID, параметры, дату и инструменты. Один удачный повтор не доказывает устойчивость, а один провал должен сохраняться как диагностический пример.

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

Что читать дальше

• посмотреть, как внешний поиск добавляет контекст

• сравнить модели на собственных задачах

• проверить качество исходных данных

• понять, как ошибка ответа превращается в действие агента