Быстрый способ проверить LLM на галлюцинации: дать модели короткий, одинаковый для всех запусков промпт о начале Chrono Trigger, задать 7-10 вопросов по этому фрагменту и сверить каждое утверждение с заранее подготовленным каноническим ответом. Отдельно фиксируются ошибки в фактах, хронологии, границе сюжета, вымышленные детали и реакция модели на уточнение.
Такой бенчмарк не измеряет интеллект модели целиком. Он показывает, удерживает ли локальная LLM заданный контекст, умеет ли отделять известное от предположения и прекращает ли уверенно заполнять пробелы выдумками. Хороший ответ по одному сюжету говорит об устойчивости в конкретном тесте, но не доказывает надежность модели в рабочих задачах.
Для проверки нужны заранее подтвержденные сведения о начале Chrono Trigger, эталонные ответы и список недопустимых утверждений. В доступных материалах нет фактуры по сюжету игры, поэтому конкретные игровые факты нельзя восстанавливать по памяти автора. Сначала подготовьте answer key по проверенному канону, затем запускайте модели в одинаковых условиях.
Короткий ответ: как работает тест на галлюцинации LLM
Сценарий состоит из четырех шагов:
- Зафиксировать сюжетную границу, например начало игры до условной точки T.
- Передать каждой модели один и тот же короткий промпт и один и тот же фрагмент контекста.
- Задать вопросы на факты, причины событий, хронологию и границы знания.
- Разбить ответы на атомарные утверждения и сравнить их с эталоном.
Модель может правильно назвать центральное событие и одновременно придумать мотив персонажа, которого нет в исходном фрагменте. Поэтому оценка по общему впечатлению от текста скрывает часть ошибок.
Что именно измеряет такой бенчмарк
- Точность фактов. Совпадают ли имена, события, обстоятельства и связи с answer key.
- Хронологию. Не перепутала ли модель порядок событий и не включила ли сведения, которые появляются позже.
- Отсутствие вымысла. Не добавила ли LLM имена, мотивы, предметы или причинно-следственные связи, которых нет в проверяемом фрагменте.
- Удержание контекста. Следует ли ответ условиям стартового промпта, включая запрет на спойлеры.
Узкий тест полезен именно такой фокусировкой. Он не заменяет проверки рассуждений, работы с документацией, RAG, свежими фактами или вызова инструментов. В статье о переоценке MoE-моделей похожая логика описана применительно к инструментальной точности: модель оценивают по поведению в конкретном сценарии, а не по одному абстрактному показателю знаний.
Почему известный сюжет удобнее абстрактного вопроса
Знакомая игра дает редактору понятный ground truth. Вопрос без однозначного эталона легко превращается в спор о трактовках, полноте ответа или версии перевода. Вопрос по ограниченному фрагменту Chrono Trigger можно проверить по заранее составленному листу: факт подтвержден, искажен, не указан или выходит за границу.
Знание игры самим проверяющим не заменяет answer key. Память редактора тоже ошибается, а разные переводы могут по-разному передавать имена и реплики. В эталоне заранее укажите допустимые варианты написания и сведения, которые нельзя считать доказанными по выбранному фрагменту.
Почему локальные модели нужно проверять на фактах и коде
Качество генерации кода и фактологическая надежность относятся к разным свойствам. При написании кода модель часто продолжает структурированный шаблон: видит имя функции, типы данных и соседние вызовы, после чего подбирает вероятное продолжение. Пересказ сюжета требует восстановить имена, порядок событий и причинные связи по памяти модели.
Уверенный тон не подтверждает достоверность. LLM может написать синтаксически правдоподобную функцию с несуществующим методом библиотеки, а в пересказе добавить убедительный мотив персонажа. В обоих случаях форма ответа выглядит профессионально, хотя отдельный тезис не выдерживает проверки.
Кодовая компетентность не равна фактологической точности
Хороший результат в программировании часто говорит о способности распознавать паттерны, соблюдать формат и продолжать последовательность. Он мало сообщает о том, как модель ведет себя при нехватке данных. Сюжетный тест создает контролируемый пробел: если ответ не следует из контекста, модель должна написать, что сведений недостаточно.
Сравнивая локальные LLM, не сводите выбор к размеру модели, скорости токенизации или качеству кода. Для домашнего AI-сервера может оказаться полезной модель, которая отвечает короче и чаще признает неопределенность. Более крупная система способна писать выразительный пересказ, но при этом добавлять больше правдоподобных деталей без основания.
Практическое сравнение узкой модели для очистки диктовки показывает ту же проблему постановки задачи: модель нужно оценивать по заранее определенным критериям, а лишняя «улучшенная» правка считается ошибкой. Подход подробно разобран в статье о локальной 0.8B-модели для очистки диктовки.
Какие ошибки особенно заметны у локальных LLM
- Смешение персонажей, локаций и событий из разных эпизодов.
- Подмена причины следствием: модель правильно называет событие, но неверно объясняет, почему оно произошло.
- Добавление деталей из других игр, адаптаций, фанатских пересказов или похожих сюжетов.
- Потеря заданной точки сюжета, когда ответ внезапно включает поздние события.
- Преждевременные спойлеры, даже если они фактически верны.
- Категоричный ответ на вопрос, для которого в контексте нет достаточных сведений.
Такие ошибки встречаются и у облачных систем, однако при сравнении локальных моделей их удобно наблюдать в одинаковом окружении: с фиксированным рантаймом, квантованием, размером контекста и параметрами sampling.
Как подготовить бенчмарк для локальных LLM по Chrono Trigger
Надежность теста определяется подготовкой. Выберите небольшой фрагмент начала Chrono Trigger, задайте границу сюжета и составьте answer key до первого запуска моделей. Если сначала посмотреть ответы, формулировки эталона могут незаметно подстроиться под ошибки конкретной LLM.
Жестко заданный стартовый промпт
Промпт должен задавать одну временную точку, правило работы с неопределенностью и формат ответа. Пример шаблона:
Ты отвечаешь только по фрагменту сюжета Chrono Trigger, приведенному ниже.
Граница знания: события до точки [T]. Не используй сведения после [T] и не добавляй детали, которых нет во фрагменте.
Для каждого ответа разделяй:
1. подтвержденный факт;
2. предположение;
3. неизвестное.
Если ответа нет в контексте, напиши: «В предоставленном фрагменте этого нет».
Не раскрывай события после точки [T].
Фрагмент:
[проверенный фрагмент начала игры]Текст промпта, порядок инструкций и сам фрагмент не меняйте между моделями. Если тест проверяет знания без внешнего контекста, оставьте фрагмент пустым, но зафиксируйте это как отдельный режим. Нельзя смешивать в одной таблице результаты режима с контекстом и режима, где модель отвечает по памяти.
Набор проверочных вопросов
Составьте 7-10 вопросов трех типов. Каждый вопрос должен проверять одну мысль или одну связь.
- Фактические: кто участвует в описанном событии, что произошло, какой предмет или место упомянуты.
- Причинно-следственные: почему событие произошло согласно фрагменту, какое действие привело к следующему событию.
- Хронологические: что произошло раньше, какое событие еще не наступило, где проходит граница доступных сведений.
Добавьте 2 вопроса на незнание. Например: «Какие сведения о событиях после точки T нельзя утверждать?» и «Какая деталь не указана в предоставленном фрагменте?». Такие вопросы выявляют стремление модели заполнить пустое место правдоподобной версией.
Формулировки должны оставаться нейтральными. Вопрос «Почему герой сделал X?» уже предполагает, что X произошло и у героя был определенный мотив. Лучше спросить: «Какую причину прямо называет фрагмент? Если причины нет, укажи это».
Эталонные ответы и список недопустимых утверждений
Для каждого вопроса подготовьте отдельную строку в answer key. Минимальная схема выглядит так:
| Поле | Что записать |
|---|---|
| ID вопроса | Уникальный номер, например Q01 или Q07. |
| Канонический ответ | Короткая формулировка без лишних интерпретаций. |
| Обязательные факты | Тезисы, без которых ответ теряет смысл. |
| Допустимые варианты | Синонимы, варианты транслитерации и различия перевода. |
| Недопустимые утверждения | Ошибочные мотивы, перепутанные события, поздние сведения и неподтвержденные детали. |
Отдельный список ловушек снижает субъективность проверки. Правдоподобная деталь считается ошибкой, если она не следует из заданного контекста или нарушает границу сюжета. Фактологическая верность сама по себе не отменяет штраф за спойлер.
Как оценивать ответы: частичное попадание и полная галлюцинация
Проверяйте ответ на уровне атомарных утверждений. Одно предложение может содержать четыре тезиса: имя персонажа, событие, причину и временную последовательность. Разделите их перед оценкой, иначе правильное ядро замаскирует лишнюю выдумку.
Разбор ответа по атомарным утверждениям
Каждому тезису присвойте одну метку:
- Подтверждено. Утверждение совпадает с answer key и не добавляет нового смысла.
- Частично верно. Основное событие или ответ совпадает, но присутствует одна неточность, пропуск или искаженная связь.
- Не подтверждено. Тезис звучит правдоподобно, но в заданном фрагменте для него нет основания.
- Ошибочно. Утверждение противоречит эталону, меняет участника, событие, причину или порядок.
- За границей. Информация может относиться к сюжету в целом, но появляется после точки T и нарушает условие теста.
Частичное попадание означает, что модель сохранила часть фактов. Полная галлюцинация начинается там, где центральный ответ, персонаж или причинная связь не подтверждаются либо прямо противоречат контексту. Эти случаи нужно разделять в отчете.
Пример оценки без игровых деталей: модель правильно описывает событие A, но приписывает ему мотив B, которого нет в фрагменте. Ответ получает отметку «частично верно», а мотив B попадает в список вымышленных деталей. Если модель вместо события A описывает другой эпизод и уверенно называет выдуманного участника, это уже полный сбой по вопросу.
Как фиксировать лишние детали и спойлеры
Ведите отдельный журнал нарушений. Для каждой лишней детали запишите ее текст, тип и связь с вопросом.
- Имя: модель добавила персонажа или объект, отсутствующий в фрагменте.
- Мотив: модель объяснила действие внутренней причиной, которой нет в answer key.
- Связь: модель придумала отношения между персонажами или событиями.
- Хронология: модель перенесла позднее событие в начало.
- Спойлер: модель раскрыла факт после точки T, даже если он соответствует канону.
Спойлер и ложное утверждение имеют разный смысл. Первый нарушает сюжетную границу. Второе искажает факты. В отчете оставляйте две отдельные колонки, чтобы модель с точными, но преждевременными ответами не выглядела так же, как модель, которая выдумывает события.
Минимальная рубрика сравнения
Для каждого ответа можно использовать шкалу от 0 до 2 по шести показателям. Максимум составляет 12 баллов, но итоговую сумму показывайте рядом с профилем ошибок.
| Показатель | 2 балла | 1 балл | 0 баллов |
|---|---|---|---|
| Точность фактов | Все ключевые тезисы подтверждены. | Есть один частичный пропуск или неточность. | Центральный факт ошибочен или выдуман. |
| Хронология | Порядок событий сохранен. | Порядок описан неясно. | События перепутаны. |
| Вымышленные детали | Лишних тезисов нет. | Есть одна неподтвержденная деталь. | Ответ строится на выдуманных деталях. |
| Спойлеры | Граница T соблюдена. | Есть намек или спорный выход за границу. | Ответ раскрывает поздние события. |
| Формат и контекст | Модель следует промпту и отвечает по фрагменту. | Есть отдельное нарушение формата. | Модель игнорирует условия теста. |
| Уверенность без основания | Модель отмечает неизвестное и разделяет факт с предположением. | Уровень уверенности выражен непоследовательно. | Неподтвержденные тезисы поданы категорично. |
Если нужен процент, сложите баллы по всем вопросам и разделите на максимальное значение. Рядом укажите количество спойлеров, ложных фактов и неподтвержденных деталей. Один процент без этих чисел мало пригоден для выбора модели.
Как понять, исправляется ли модель после уточнения
Первый ответ показывает склонность к ошибкам. Второй этап показывает, что происходит после сигнала о возможной неточности. Это отдельная характеристика диалога, поэтому не смешивайте ее с исходным баллом.
Уточнение без подсказки правильного ответа
Задайте нейтральный вопрос, который не содержит нужного факта:
Проверь предыдущий ответ по исходному фрагменту. Для каждого спорного тезиса укажи: подтверждено, предположение или неизвестно. Исправь только то, что нельзя подтвердить контекстом.Другой вариант:
Восстанови хронологию ответа. Не используй сведения после точки [T] и не добавляй правильные факты, если их нет в исходном фрагменте.Не подсказывайте модели правильный вариант до фиксации ее реакции. Иначе проверка самокоррекции превратится в обычное продолжение диалога после обучения на подсказке.
Признаки рабочей самокоррекции
- Модель признает, что конкретный тезис нельзя подтвердить.
- Удаляет неподтвержденную деталь, а не заменяет ее другой версией.
- Восстанавливает порядок событий по исходному контексту.
- Разделяет факт, вывод и предположение.
- Сохраняет исправление в следующем сообщении и не возвращается к исходной ошибке.
Фраза «возможно, я ошибся» сама по себе не считается исправлением. Проверьте, исчезла ли спорная деталь из обновленного ответа и изменился ли вывод.
Когда ошибка становится устойчивой
Зафиксируйте устойчивую ошибку, если после двух нейтральных уточнений модель повторяет тот же тезис, добавляет новые детали для его защиты или рационализирует противоречие. Такой критерий нужно выбрать до запуска, чтобы не менять правила под конкретный результат.
Разделите три случая:
- модель исправилась после первого запроса;
- модель исправилась после второго запроса;
- модель продолжила развивать ошибочную версию.
Третий вариант указывает на слабое удержание контекста или чрезмерную уверенность. Он может быть важнее единичной оговорки в первом сообщении, особенно если LLM будет работать без постоянного контроля оператора.
Как честно сравнивать несколько локальных моделей
Сравнение имеет смысл при одинаковых входных данных и правилах оценки. Замена версии модели, квантизации или system prompt уже создает другой эксперимент.
Что фиксировать в журнале запуска
- Полный системный промпт, пользовательский промпт и сюжетный фрагмент.
- Название и точную версию модели.
- Формат квантования, например Q4 или Q8, если он используется.
- Размер контекстного окна и ограничение длины ответа.
- Рантайм, параметры temperature, top_p, top_k, seed и другие настройки sampling.
- Аппаратную конфигурацию, тип GPU или CPU и объем доступной VRAM.
- Дату запуска и полный необрезанный ответ модели.
При temperature выше нуля проведите минимум 3 запуска с разными seed либо сохраните факт отсутствия управляемого seed. Для детерминированного режима отдельно укажите temperature 0 и настройки рантайма. В итоговой таблице показывайте медиану или диапазон, а не скрывайте разброс одним удачным ответом.
Такая дисциплина нужна и в аппаратных бенчмарках. AnTuTu объединяет показатели CPU, GPU, RAM и I/O, при этом результаты iOS и Android нельзя напрямую сравнивать как одну шкалу. Для LLM действует похожее правило: результаты при разных промптах, рантаймах и параметрах генерации не образуют честный рейтинг.
Почему один итоговый балл может вводить в заблуждение
Две модели могут получить по 80 процентов, но одна потеряет баллы на трех спойлерах, а другая, на вымышленных мотивах и перепутанной хронологии. Для сценария с ограничением сюжета это разные риски.
Публикуйте минимум пять отдельных показателей: факты, хронология, вымышленные детали, спойлеры и соблюдение формата. Уверенность без основания вынесите в отдельный флаг или шестую оценку. В статье об аудите бенчмарков AI хорошо видна общая проблема: качество самого тестового набора влияет на итоговый рейтинг, поэтому проверять нужно и модель, и вопросы.
Не называйте победителем модель с максимальной суммой, если она регулярно нарушает критическое для вашей задачи правило. Для чат-бота со спойлерами это может быть жесткий лимит на выход за границу. Для корпоративного ассистента важнее отказ от неподтвержденного ответа.
Как учитывать гибридные и пограничные случаи
Смешанный ответ может содержать правильное ядро и несколько ложных дополнений. Оценивайте его слоями: факты, выводы, формулировки, хронология и ограничения контекста. Такой разбор точнее, чем одна отметка «правильно» или «неправильно».
Похожий принцип используют при проверке гибридных AI-аудиотреков, где отдельно анализируют вокал, текст и сгенерированные stems. Эта аналогия помогает организовать проверку слоев, но не служит доказательством свойств текстовых LLM.
Пограничные случаи заранее занесите в правила. Например, если перевод допускает два написания имени, оба варианта получают статус подтвержденных. Если факт известен из полной игры, но отсутствует в переданном фрагменте, он считается неподтвержденным для этого режима.
Что показывает тест по Chrono Trigger, а чего он не доказывает
Бенчмарк показывает склонность конкретной модели к додумыванию, смешению последовательности и нарушению сюжетной границы на выбранном материале. Он позволяет сравнить несколько локальных LLM при одинаковом промпте и увидеть, какие ошибки повторяются.
Узкий результат нельзя превращать в универсальный рейтинг. Модель может аккуратно пересказывать игру и ошибаться в технической документации, свежих новостях, расчетах или ответах с RAG. Обратная ситуация тоже возможна.
Ограничения игрового сюжета как тестового домена
- Chrono Trigger мог быть представлен в обучающих данных моделей с разной полнотой.
- Результат зависит от языка запроса и выбранной версии перевода.
- Небольшой фрагмент может проверять память о конкретной сцене, но не работу с длинным контекстом.
- Качество answer key определяет точность оценки.
- Знакомый игровой домен не отражает поведение модели в профессиональной области.
Указывайте в отчете размер фрагмента, границу сюжета, язык, правила по переводам и происхождение эталонных формулировок. Не подменяйте проверку канона личной памятью. В этой статье конкретные события игры не перечисляются, поскольку в переданном исследовательском наборе нет проверенных сведений о Chrono Trigger.
Как перенести метод на рабочие задачи
Соберите отдельные наборы вопросов по технической документации, внутренним инструкциям, продуктовым данным или утвержденному справочному корпусу. Для каждого домена подготовьте собственный answer key и список допустимых выводов.
В документации полезны вопросы о параметрах, ограничениях и порядке действий. В продуктовой базе, о наличии функции, версии и условиях использования. Во внутренних инструкциях, о том, какое действие разрешено, какие данные обязательны и когда ассистент должен отказаться от ответа.
Внешний материал о проверке LLM на устойчивость к фальшивым источникам помогает расширить эту схему для RAG и AI-агентов. Там требуется проверять не только финальный текст, но и реакцию модели на ложные или конфликтующие сведения.
Почему один запуск недостаточен
При ненулевой temperature модель может выбрать другую формулировку, добавить новую деталь или отказаться от нее в следующем запуске. Один удачный ответ не описывает стабильное поведение.
Для короткого сравнения используйте три повторения на каждый вопрос. Зафиксируйте количество ошибок каждого типа и отдельно отметьте случаи, которые появились только в одном запуске. При temperature 0 результат обычно проще повторить, но это не превращает модель в безошибочную систему и не отменяет проверку на других настройках.
В финальном выводе пишите конкретно: «модель сохранила границу сюжета в 8 из 10 вопросов и допустила 3 неподтвержденные детали». Формулировка «модель надежна во всем» не следует из такого теста.
Итоги: как оценить локальную языковую модель по фактам
Бенчмарк по Chrono Trigger полезен как короткая диагностическая процедура. Он показывает, что делает LLM, когда нужно пересказать знакомый материал, удержать временную границу и признать нехватку данных.
Краткий чек-лист проверки
- Выберите ограниченный фрагмент начала Chrono Trigger и зафиксируйте точку T.
- Проверьте сюжетные факты и подготовьте answer key до первого запуска.
- Сохраните один и тот же промпт, список из 7-10 вопросов и порядок диалога.
- Зафиксируйте версию модели, квантизацию, контекстное окно, рантайм и параметры генерации.
- Разберите каждый ответ на атомарные утверждения.
- Отдельно посчитайте фактические ошибки, выдуманные детали, спойлеры и нарушения хронологии.
- Задайте нейтральное уточнение и проверьте, исправляет ли модель ошибку без подсказки правильного ответа.
- Повторите запуск и укажите ограничения, которые мешают переносить результат на другие домены.
Хороший результат означает устойчивость в выбранном сценарии. Для выбора локальной LLM этого достаточно как одного измерения, если рядом стоят тесты на реальные рабочие задачи, документацию, инструменты и качество отказа при нехватке информации.