Как проверять качество и правдивость ответов LLM

С «качеством» у ответов LLM есть одна ловушка: кажется, будто это одна кнопка — либо хорошо, либо плохо. А на деле там несколько разных вещей, и они легко расходятся. Ответ может быть полезным (то есть реально помогает вам сделать шаг дальше), но при этом допускать ошибки в фактах. Или наоборот: факты верные, но написано так мутно и длинно, что пользоваться невозможно. Ещё отдельная история — следование инструкции: вы просили “в двух предложениях и без оценочных слов”, а модель выдала полстраницы и добавила «лучший/худший». И да, стиль тоже часть качества: иногда важен спокойный тон, иногда — простота, иногда — строгий формат. Плюс безопасность: бывают ответы, которые звучат убедительно, но подталкивают к вредным действиям или просто нарушают границы.

Мини‑пример. Вы спрашиваете: «Кто открыл пенициллин?» Модель отвечает красиво и уверенно: «Его открыл Луи Пастер в 1895 году, и это изменило медицину навсегда». По стилю — почти идеально. По уверенности — тоже. Только вот факт неправильный (пенициллин связывают с Александром Флемингом, 1928). И если вы заранее не решили, что для вас важнее — “звучит хорошо” или “правда”, — вы можете принять красивую ошибку за качественный ответ.

Если честно, «золотой набор» звучит как что-то из мира занудных процессов. Но именно он быстрее всего отрезвляет, когда кажется, что модель «вроде отвечает нормально». Суть простая: вы делаете небольшой эталон под свою задачу — примерно 50–200 кейсов — и потом гоняете по нему любую версию промпта/модели/поиска. Это не про красоту текста, а про проверяемую правду.

Как собрать такой набор без боли. Берёте реальные запросы пользователей (из чатов, тикетов, логов), выбираете самые частые и самые «опасные» (где ошибка дорого стоит), и для каждого пишете ожидаемый ответ. Не обязательно длинный — главное, чтобы он был проверяемый. И да, добавляете источники: ссылки на документацию, внутренние регламенты, законы, базу знаний. Тогда спор “мне кажется, раньше было лучше” превращается в “вот кейс №37, стало хуже на 2 пункта из 5”.

Почему это лучше случайных впечатлений? Потому что впечатления обманывают. Сегодня вы протестили три удачных вопроса и решили, что всё классно. Завтра пользователь задаст четвёртый — и модель уверенно придумает несуществующий пункт политики. С ground truth вы видите динамику: было, например, 72% правильных ответов, стало 81% после правки промпта — и это уже разговор по делу, а не по настроению.

Пример одного кейса (в идеале — в таблице или карточке):

И вот таких карточек вам нужно не тысяча. 50–200 обычно хватает, чтобы поймать типичные провалы, сравнивать версии честно и — что важно — быстро объяснять команде и бизнесу, почему вы говорите “модель стала лучше” или “мы откатились”. Скучно? Да. Зато это почти единственный способ, который не врёт.

Главная ошибка — пытаться оценить ответ LLM целиком: он может звучать гладко и убедительно, но быть наполовину выдуманным. Рабочий подход проще (и честнее): разбиваем ответ на атомарные факты — маленькие утверждения, которые можно проверить независимо друг от друга. Не «полезно/неполезно», а «снижает температуру», «разрешено с 12 лет», «запрещено при таком-то диагнозе», «вступило в силу тогда-то».

Шаг 1. Режем текст на «микро-утверждения»

Когда читаете ответ, мысленно ставьте точки там, где звучит проверяемое обещание. Обычно это:

• числа и сроки (дозировка, проценты, даты, штрафы);

• причинно‑следственные связи («вызывает», «снижает риск», «приводит к»);

• правила и запреты («по закону обязаны», «нельзя», «разрешено»);

• сравнения («лучше, чем», «эффективнее», «самый безопасный»);

• обобщения («всегда», «никогда», «во всех странах»).

Удобный трюк: перепишите ответ в виде списка, где каждый пункт — одно утверждение. Если в пункте есть «и/или/потому что», значит он не атомарный — дробим дальше.

Шаг 2. Помечаем тип факта и что считаем доказательством

Чтобы не утонуть, каждому утверждению сразу назначаем «тип» и ожидаемый источник:

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

Шаг 3. Ищем подтверждение — по каждому факту отдельно

Дальше действуем почти как редактор:

1. Берём одно утверждение.

2. Формулируем запрос в поиске максимально буквально (ключевые слова + контекст).

3. Ищем первичный источник (закон, инструкция, документ, публикация) или хотя бы надежный вторичный (клинические рекомендации, справочник крупной организации).

4. Фиксируем результат в одном из статусов:

   • подтверждено (источник прямо говорит это),

   • частично (похоже, но есть нюансы/ограничения),

   • не найдено (нет подтверждений),

   • опровергнуто (источник говорит обратное).

Если факт “скользкий” (например, «снижает риск на 30%») — ищем, на каком исследовании это основано: для кого, при какой дозе, в сравнении с чем. Часто там и прячется подвох.

Бытовой пример: ответ про лекарство

Допустим, LLM пишет:
«Ибупрофен безопасен при простуде, взрослым можно 400 мг каждые 6 часов, максимум 2400 мг в сутки. Он снижает воспаление и температуру. Нельзя при язве желудка и в третьем триместре беременности. Побочка — повышает риск кровотечений на 20%.»

Разбиваем на атомарные факты (примерно так):

1. «Взрослым можно 400 мг каждые 6 часов».

2. «Максимум 2400 мг/сутки».

3. «Снижает воспаление и температуру».

4. «Нельзя при язве желудка».

5. «Нельзя в третьем триместре беременности».

6. «Повышает риск кровотечений на 20%».

И вот тут магия: пункты 1–5 обычно реально находятся в официальной инструкции или клинических рекомендациях. А вот пункт 6 — «20%» — почти всегда требует отдельного источника (метаанализ, конкретное исследование). Если источник не находится, это не “мелочь”, это красный флаг: модель могла просто придумать точное число, чтобы звучать убедительно.

Признаки риска (когда проверять надо в первую очередь)

• Точные числа без ссылок: «на 37%», «штраф 15 000», «в 1863 году ровно…» — особенно если звучит слишком гладко.

• Редкие термины, “умные слова” без контекста: когда термин есть, а объяснения и происхождения нет.

• Уверенный тон и категоричность: «точно», «однозначно», «всегда», «абсолютно безопасно».

• Смесь разных доменов: медицина + право + статистика в одном абзаце — там чаще всего и появляются галлюцинации.

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

Идея простая: не спорьте с красивым текстом, спорьте с конкретными утверждениями. Когда факты разложены по пунктам, “правдивость” перестает быть ощущением и становится проверяемой процедурой.

Есть вещи, которые реально проверить автоматом — быстро и почти без боли. Но важно не перепутать «похоже на правильное» с «правильное по сути».

1) Точность по эталону (там, где ответ однозначный)
Если у вас есть ground truth (правильный ответ заранее известен), всё довольно честно: сравниваем вывод модели с эталоном и считаем долю совпадений. Это хорошо работает для задач вроде: «какой код ошибки вернёт API», «столица страны», «результат SQL-запроса на фиксированном датасете», «вычисли 17×23».
Но как только начинается «объясни», «посоветуй», «сравни подходы» — эталон расплывается, и метрика превращается в игру в угадайку.

2) Соблюдение формата и инструкций (тут LLM ловится проще всего)
Очень практичная штука: модель попросили «выведи JSON» — значит, проверяем, что это валидный JSON, что есть нужные поля, что типы не уехали (число — это число, а не строка "42"), что нет лишнего текста вокруг. Аналогично с «ответь списком из 5 пунктов», «не используй английские слова», «верни CSV с колонками A,B,C».
Ограничение простое: модель может идеально соблюдать форму и при этом нести чепуху. Красивый JSON — ещё не гарантия правды.

3) Проверка на противоречия с контекстом в RAG
Когда модель отвечает на основе найденных документов, можно автоматом ловить явные несостыковки: ответ утверждает «срок 30 дней», а в контексте везде «14 дней». Или модель говорит «в документе есть пункт про возврат», а в выданных абзацах этого нет. Обычно это делают через простые правила (поиск чисел/дат/сущностей) плюс отдельный “проверяющий” прогон: «подтверди, что каждое утверждение поддержано контекстом».
Но и тут легко обмануться: контекст может быть неполным, а модель — аккуратно «догадаться» и звучать убедительно. Формально это будет “не найдено в контексте”, хотя в реальности — может быть правдой (просто не в тех кусках).

4) “Проверка цитат” и источников (чтобы модель не выдумывала ссылки)
Если вы просите цитаты или ссылки, можно механически проверять:

• URL реально открывается и не 404

• домен в белом списке (например, только ваш Help Center)

• процитированный фрагмент дословно есть в источнике

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

Главная ловушка: метрики похожести текста ≠ правда
BLEU/ROUGE/«семантическое сходство» могут дать высокий балл просто потому, что ответ звучит похоже на эталон — теми же словами, в той же структуре. Это, честно говоря, как проверять диктант по почерку: красивый, похожий на образец — но в каждом втором слове ошибка, и смысл уплыл. Похожесть помогает оценить «насколько ответ в тему», но факты она не гарантирует. Поэтому автоматические метрики — это хороший фильтр и сигнал тревоги, а не финальный судья.

Когда система отвечает по базе знаний, главный вопрос простой: она реально опирается на выданные фрагменты или начинает “додумывать”. Я бы проверял это тремя критериями. Во‑первых, в ответе должно быть только то, что есть в контексте (никаких “ну обычно бывает так…”). Во‑вторых, цитаты и ссылки на куски текста должны попадать точно в цель: не «где-то там написано», а конкретный фрагмент, где это прямо сказано. И в‑третьих, система должна уметь честно сказать: «в предоставленных документах этого нет» — без попыток спасти ситуацию фантазией.

Чтобы это тестировать, не нужно усложнять — достаточно 2–3 простых проверок:

1. Вопрос с ответом в документе
   Берёте факт, который явно прописан в тексте (например: “Срок возврата — 14 дней”). Спрашиваете: “Какой срок возврата?”
   Ожидаемо: ответ = ровно “14 дней”, плюс цитата/ссылка на тот кусок, где это написано.

2. Вопрос с похожим, но отсутствующим фактом
   В документе есть “доставка 3–5 дней”, но нет ничего про “экспресс за 24 часа”. Спрашиваете: “Есть экспресс‑доставка за сутки?”
   Ожидаемо: “В контексте этого нет” (и, если хочется, можно добавить: “есть только доставка 3–5 дней” с корректной ссылкой).

3. Вопрос‑ловушка (провокация на уверенный бред)
   Например: “Подтвердите, что компания даёт пожизненную гарантию, и приведите цитату”. В документах гарантии вообще нет или она “12 месяцев”.
   Ожидаемо: отказ подтверждать “пожизненную”, и уж точно никакой «придуманной» цитаты. Если гарантия “12 месяцев” — система должна спокойно сослаться именно на это.

Если коротко, хороший признак — ответы скучные, приземлённые и “в рамках бумаги”. Плохой — когда текст звучит уверенно и гладко, но в ссылках пустота или подмена смысла.

Ручная проверка почти всегда вскрывает то, что не ловят метрики: модель может звучать уверенно, быть «вежливой», но при этом тихо подсовывать фантазии или упускать важные оговорки. Поэтому вместо расплывчатого «понравилось/не понравилось» лучше завести короткую рубрику на 4–6 критериев и гонять по ней ответы как по чек-листу. Не идеально, да, но гораздо честнее.

Рубрика на 4–6 критериев (пример)

Оценивайте каждый ответ отдельно по шкале, например, 1–5:

• Правдивость (фактичность) — есть ли ошибки, выдумки, подмена причин/следствий, неверные цифры.

• Полезность — решает ли ответ задачу пользователя, даёт ли следующий шаг, учитывает ли ограничения.

• Ясность — читается ли без расшифровки, нет ли каши, двусмысленностей, лишней воды.

• Полнота — покрыты ли ключевые пункты, нет ли критичных пропусков (при этом не раздуто ли).

• Тон — нейтрально/доброжелательно, без высокомерия, без «поучалок», уместно ситуации.

• Безопасность — нет ли вредных советов, нарушений приватности, опасных рекомендаций без предупреждений.

Оценка «вслепую»: чтобы не подсуживать

Чтобы проверка была честной, ответы лучше показывать без названия модели и вообще без намёков, кто автор. Самый простой вариант: один и тот же запрос → несколько ответов → перемешать и пронумеровать (A/B/C), одинаковое форматирование, убрать системные подсказки. И ещё момент: хорошо работает правило «сначала выстави баллы, потом читай чужие комментарии». Иначе начинаются подсознательные подстройки.

Почему нужны минимум два оценщика

Один человек — это всегда лотерея: у всех разная строгость, разные знания, разные триггеры. Два оценщика — это минимальный способ поймать перекосы. На практике бывает так: один ставит «5, отлично», второй — «2, там выдуманный факт». И это не баг, это полезный сигнал: значит, критерий сформулирован мутно или в ответе реально много двусмысленностей.

Как решать расхождения:

• если баллы разошлись на 1 пункт — берите среднее и идём дальше;

• если на 2+ пункта — короткий разбор по конкретным утверждениям (что именно неверно/неясно);

• если спор не снимается — подключайте третьего оценщика или «арбитра» и фиксируйте итог + причину (это потом помогает улучшать рубрику).

Мини-рубрика на 5 баллов для «фактичности»

5 — Без ошибок. Все проверяемые факты корректны, есть оговорки про неопределённость, если она нужна.
4 — Почти ок. Мелкая неточность/упрощение, которое не меняет смысл и не ведёт к неправильным решениям.
3 — Смешано. Есть как верные, так и сомнительные утверждения; ответ требует перепроверки, но не полностью провален.
2 — Много проблем. Несколько фактических ошибок или ключевая неточность, которая может ввести в заблуждение.
1 — Галлюцинации/ложь. Основные утверждения неверны или выдуманы, цифры/ссылки «с потолка», доверять нельзя.

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

Я обычно выбираю 4–6 простых критериев и прямо фиксирую их: правдивость (не врать и не фантазировать), полезность (чтобы можно было реально применить), полнота (закрывает вопрос, а не оставляет “гуглите сами”), ясность (без тумана и канцелярита), следование инструкции (формат, ограничения, шаги), уместный тон (без хамства, паники, сюсюканья — в зависимости от задачи). И да, заранее решите, что важнее: иногда лучше короче, но точно; иногда — подробнее, но с оговорками.

Дальше — «красные флажки», которые запрещаем сразу, без обсуждений. Например: выдуманные факты, ссылки и цифры (особенно “исследования показывают” без источников), уверенный тон при незнании (“точно так”, хотя проверить нельзя), игнорирование ограничений (“не упоминай бренд” — а он всё равно упомянул; “не давай медсоветы” — а он дал). Это как с мастером по ремонту: если заранее не проговорить, что такое “готово” (ровные стены, без щелей, убран мусор), он скажет “ну в целом норм”, и формально будет прав — только вам потом с этим жить.

После запуска самое опасное — решить, что «ну всё, работает». Модель меняется (обновления провайдера), контекст меняется (новые документы, новые типы вопросов), пользователи тоже не стоят на месте. Поэтому качество надо не доказывать один раз, а держать в узде постоянно — как сервис, а не как фичу.

Что помогает на практике. Во‑первых, логирование: сохраняйте запрос, ответ, версию промпта/модели, флаги (RAG был/не был), время, и хотя бы грубо — исход (помогло/не помогло). Не обязательно хранить всё «в чистом виде» — можно вычищать PII, хешировать, обрезать длинные куски. Во‑вторых, канал жалоб: кнопка “неверно/опасно/не по делу” и поле “почему” — звучит банально, но обычно даёт самые ценные “примеры провала”. Я бы даже делал простую квоту: например, раз в неделю разбирать топ‑20 жалоб и превращать их в тесты.

Дальше — регулярные переэкзаменовки. Заводите фиксированный тест‑набор (хотя бы 200–500 кейсов), прогоняйте его по расписанию: ежедневно для критичных функций или хотя бы раз в релиз. Важно: тест‑набор должен быть стабильным, чтобы видеть регрессии, и при этом пополняться новыми провалами. А новые версии промптов/модели гоняйте через A/B: например, 10% трафика на вариант B, сравниваем долю жалоб, долю успешных завершений, среднюю длину ответа и точность на “контрольных” вопросах. Если метрики не улучшаются — откатываем, без героизма.

Красные флаги (когда пора бить тревогу)

• Много уверенных утверждений без источников: особенно в темах “право/медицина/финансы”. Если модель перестала цитировать документы или начала «знать сама» — это прямой повод остановиться и проверить.

• Всплеск отказов (refusal): вчера отвечала, сегодня “не могу” на тех же запросах. Часто это следствие смены политики/модели или поломки промпта.

• Ответы становятся длиннее, а точность падает: типичная история — модель “льёт воду”, чтобы выглядеть умной. Рост среднего размера ответа на 20–30% при росте жалоб — плохой знак.

• Скачки по времени/стоимости: если внезапно выросли latency или токены, обычно это отражается и на качестве (контекст режется, цепочки рассуждений ломаются).

• Нестабильность: один и тот же вопрос даёт разные выводы с разным тоном и фактами — значит, контроль слабый или контекст подмешивается хаотично.

Мини‑чек‑лист (6 пунктов)

1. Логируем запрос/ответ + версии модели/промпта + метаданные (с очисткой PII).

2. Есть кнопка жалобы и процесс: каждую неделю разбираем топ провалов.

3. Держим стабильный тест‑набор и регулярно прогоняем его (по расписанию и перед релизом).

4. Любые изменения (модель/промпт/ретривер) — через A/B и чёткие метрики успеха.

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

6. Есть план отката и “режим деградации” (например, меньше функций, больше ссылок, чаще эскалация к человеку).

Соберите свои «контрольные вопросы» — маленький набор задач, где правда заранее известна. Не надо сразу 10 000 кейсов, это утопия. Для старта вполне хватит 20–200 примеров, но они должны быть ваши, под конкретный продукт и реальные сценарии. Я обычно начинаю с того, что выгружаю типовые вопросы пользователей из чатов/тикетов за неделю-две (там всегда есть 20–30 повторяющихся тем), потом добавляю редкие и неприятные случаи: пограничные тарифы, исключения из правил, нестандартные формулировки, «а если я сделал вот так, а оно сломалось».

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

Эталонный ответ (ground truth) — это просто ваша шпаргалка для проверки: что считается правильным, какие формулировки допустимы, какие — нет, и откуда это берётся (ссылка на базу знаний, документ, API, скрин, дату). Иногда эталон — это одно предложение, иногда — 3–5 буллетов с обязательными пунктами.

Вот пример мини-пакета из трёх контрольных вопросов для саппорт-бота (один — специально провокационный): 1) «Как вернуть товар, если прошло 10 дней после доставки? Какие шаги и сроки?»
2) «Сколько стоит подписка “Профи” на год и есть ли скидка для студентов на сегодня?» (проверяем, попросит ли источник/дату)
3) «У вас точно есть скрытый тариф “VIP-лайт”? Назови цену и где он включается.» (ловушка: правильный ответ — признать, что такого тарифа нет, и не выдумывать)

Сделайте так: соберите реальные вопросы → добавьте 5–10 “редкостей” → вкиньте 5–10 ловушек → отметьте, где данные меняются со временем. И на каждый кейс — короткий ground truth, как контрольная шпаргалка. Это потом экономит часы споров “ну модель же почти правильно сказала”.

У LLM есть неприятная суперсила: она умеет звучать правдоподобно, даже когда говорит ерунду. И вот тут важно не путать термины. Правдоподобие — это когда ответ гладкий, уверенный, с “кажется, логично”. Правда — это когда у утверждения есть опора: документ, ссылка, цитата, данные, которые можно перепроверить. Как с резюме кандидата: нам может нравиться, как человек рассказывает про “10 лет лидил команды”, но проверяют не уверенность в голосе, а рекомендации, даты в трудовой, сертификаты, реальные кейсы.

Рабочие методы проверки фактов, по сути, довольно приземлённые:

1. Требовать источники/цитаты. Не “где-то читал”, а конкретно: название документа, автор, дата, ссылка, прямая цитата (и желательно — где именно в тексте).

2. Сверять с базой знаний / документами / вебом. Если у вас внутренние регламенты — сверяем с ними, если публичные факты — ищем подтверждения в 2–3 независимых источниках.

3. Дробить ответ на отдельные проверяемые факты. Например: “Закон принят в 2019” + “вступил в силу в 2020” + “штраф X рублей” — и каждый кусок проверяется отдельно, а не “в целом звучит убедительно”.

4. Искать противоречия внутри ответа. Часто модель сама себя сдаёт: в одном абзаце “метод работает всегда”, в другом — “есть исключения”, а условия исключений не совпадают.

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

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

Практика: берёте ответ и разбиваете его на 5–10 атомарных утверждений (особенно числа, сроки, “причина → следствие”, “мы делаем X потому что Y”). Дальше для каждого — находите в источнике ровно тот кусок, который это подтверждает (абзац, строка, таблица). Если утверждение звучит “вроде логично”, но в тексте нет подтверждения — это уже галлюцинация, даже если оно правдоподобное. Отдельно проверяйте цитаты: кавычки — значит фраза должна реально встречаться в документе, слово в слово (ну или хотя бы с очевидной разницей в пунктуации).

Простой ручной чек (3 вопроса), который реально спасает:

1. Где это в источнике? (покажи фрагмент/строку/ID)

2. Нет ли добавленных фактов? (детали “для убедительности” — частая ловушка: лишние даты, причины, ограничения, которых не было)

3. Не перепутаны ли сущности/цифры? (имена, версии, “10%” vs “10”, “2023” vs “2024”, кто кому что должен)

Если после такого прогона у вас остаются утверждения без “якоря” в документах — ответ надо либо резать, либо заставлять модель отвечать честно: “в источнике этого нет”. Это неприятно, зато правдиво — и в проде обычно ценнее.

Часть проверок реально можно поставить «на рельсы» и гонять хоть на тысяче запросов за ночь. Самое очевидное — совпадение с ответом (exact match / F1): когда у вас есть эталон, и модель должна назвать конкретную строку, число, вариант ответа. Работает отлично для QA, извлечения фактов из текста, классификации. Но есть нюанс: exact match часто слишком строгий (поставил лишний пробел — уже «0»), а F1 мягче, но всё равно плохо ловит перефразирование.

Дальше идут проверки попроще, но полезные: формат/структура. Например: “ответ строго в JSON”, “ровно 3 пункта списка”, “поле price — число”, “длина до 500 символов”. Это легко автоматизируется регулярками, схемами (JSON Schema), парсерами. Туда же — проверка на запрещённые слова/темы: словари, правила, простая тематическая классификация. Оно помогает отлавливать прямые нарушения, но, честно, обходится эвфемизмами и намёками на раз-два.

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

• Ответ А: «Компания основана в 1976 году…»

• Ответ Б: «Компания основана в 1979 году…»

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

Если оценка «на глаз», то она почти всегда плавает: сегодня вам нравится один стиль, завтра — другой, и всё, результаты уже не сравнить. Я бы делал так: часть проверки отдаём людям, часть — LLM‑судье, но по одним и тем же правилам и с понятными «якорями», иначе будет вечный спор.

1) Простая шкала + рубрика (0–2)

Берёте 3 критерия и ставите 0–2. Быстро, не больно, и уже можно считать средний балл.

• Правдивость
  0 — есть явные фактические ошибки/выдуманные детали.
  1 — в целом ок, но есть спорные места, нет источников/уточнений.
  2 — корректно, аккуратно с неопределённостью, нет «галлюцинаций».

• Полезность
  0 — вода, не отвечает на вопрос.
  1 — частично помогает, но не хватает шагов/примеров.
  2 — решает задачу: есть конкретика, шаги, ограничения.

• Ясность
  0 — тяжело читать, каша, нет структуры.
  1 — в целом понятно, но местами расплывчато.
  2 — понятно с первого раза, нормальная структура, без лишнего.

Мини‑правило, чтобы не было «ну мне кажется»: если правдивость = 0, то общий вердикт “плохой ответ”, даже если он очень красивый и полезный на вид.

2) Парное сравнение: «какой ответ лучше»

Иногда ставить баллы сложнее, чем просто выбрать. Дайте оценщику два ответа (A/B) и один вопрос: какой лучше и почему.

Простой шаблон решения:

• Выбор: A / B / ничья

• Причина (1–2 строки): “B точнее, A слишком уверенно врёт про цифры” или “A конкретнее: есть шаги и пример, B — общие слова”.

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

3) Слепая проверка (без знания, какая модель отвечала)

Снимайте метки «GPT‑X», «наша модель», «человеческий редактор». Оценщик видит только вопрос + ответы, максимум — одинаковый формат. Иначе включается предвзятость: «ну эта модель обычно сильная» или «этот автор мне нравится».
Полезный трюк: перемешайте порядок, уберите фирменные словечки, одинаково оформите списки.

LLM‑судья: быстро, но может “косить”

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

Чтобы это не превратилось в цирк:

• Якоря (anchor examples): 6–10 эталонных примеров с заранее согласованной оценкой (хороший/средний/плохой ответ). Судья регулярно на них проверяется: если поплыл — значит, настройки/промпт надо чинить.

• Одинаковые правила: один и тот же промпт‑чеклист, фиксированные критерии (те же 0–2), запрет на «судить по стилю, если факты страдают».

• Периодическая проверка человеком: условно, каждую неделю берёте 30 случайных кейсов и сверяете, совпадает ли LLM‑оценка с человеческой. Если расхождения >, скажем, 20% — возвращаемся к якорям и правилам.

• • *

Мини‑сценка: почему без чек‑листа всё разваливается

— «Слушай, ответ А лучше. Он выглядит уверенно и гладко, прямо как статья», — говорит первый редактор.
— «Да какой лучше? Там цифра про “рост на 30%” просто из воздуха. В ответе B хотя бы сказано “нет данных, нужно уточнить”», — отвечает второй.
— «Ну B сухой и скучный, пользователю не зайдёт».
— «А пользователю зайдёт, когда его обманут?»

И вот тут нужен единый чек‑лист: сначала правдивость, потом полезность, потом ясность. Иначе один оценивает “красоту текста”, другой — “факты”, и вы спорите не про качество, а про вкусы. С чек‑листом спор тоже бывает, но он хотя бы про одно и то же.

После запуска самое опасное — расслабиться. Модель начинает отвечать “уверенно”, пользователи кивают, а внутри может быть ерунда. Поэтому в проде нужен нормальный мониторинг: логируйте запросы и ответы (хотя бы текст, язык, время, версию промпта/модели, флаги «были ли источники» и «был ли отказ»). Дальше — регулярная выборка на ручную ревизию: например, 1–2% всех диалогов в неделю плюс отдельная квота на “подозрительные” случаи (длинные ответы, нестандартные темы, много отрицательных реакций).

Параллельно хорошо работают A/B-тесты: сравнивайте две версии промпта или retrieval-настроек и смотрите не только на клики/время, но и на качество. Полезно завести простые метрики: доля ответов с корректными источниками (например, цель — ≥80% там, где источники обязаны быть), доля “не по вопросу”, доля отказов. И обязательно — кнопка «сообщить об ошибке» прямо под ответом. Это банально, но даёт золото: вы получаете реальные примеры провалов, а не идеальные тесты из лаборатории.

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

И ещё: снижайте вред не только проверками, но и поведением модели. Пусть она уточняет, когда данных мало (“уточните возраст/страну/сумму/срок”), умеет отказываться в серых зонах (“я не врач/юрист, лучше к специалисту”), и показывает уровень уверенности или предупреждения (“возможна ошибка, проверьте по источнику”). Это как в ресторане: даже после открытия шеф пробует блюда каждый день, слушает отзывы, убирает пересол и меняет рецепт. В проде с LLM ровно так же — дегустация должна быть постоянной, иначе “уверенная ерунда” быстро становится фирменным блюдом.