Оценка качества ответов LLM: тест-пакет и A/B смены модели

Что значит качество ответов LLM для организации

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

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

Единичные примеры не заменяют системный тест. Они не покрывают разнообразие запросов и контекста. Один человек проверил 10 вопросов - все выглядит отлично. Но на сотом возникнет редкий кейс: неоднозначная формулировка, устаревший регламент, конфликт источников или просьба «сделай как в прошлый раз». Хороший тест-пакет ловит такие вещи заранее.

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

Для бизнеса качество обычно означает сочетание критериев: точность (без выдуманных фактов), проверяемость (понятно, откуда взят ответ), безопасность (нет лишней информации и опасных советов), полезность (ответ закрывает задачу), тон (соответствует роли: поддержка, финансы, HR).

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

Какие департаменты включать и как выбрать приоритеты

Тест-пакет стоит начинать не с выбора модели, а с людей, которые будут жить с ответами каждый день. Важнее покрыть реальные рабочие сценарии, чем собрать «красивые» вопросы.

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

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

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

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

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

Пошагово: как собрать тест-пакет эталонных вопросов

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

Дальше нужен материал из реальной жизни. Возьмите обращения пользователей за последние 1-3 месяца: письма в общий ящик, тикеты, чаты, заметки колл-центра, вопросы из внутренних каналов. Берите не только частые запросы, но и те, где цена ошибки выше (финансы, закупки, безопасность, HR).

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

На старте помогает простой каркас:

• выберите 8-12 тем (например: закупки, договоры, командировки, IT-поддержка, склад)
• для каждой темы соберите 10-20 вопросов разных типов
• отметьте сложность (A/B/C) и риск ошибки (низкий/средний/высокий)
• сохраните исходный канал и дату (без персональных данных)
• ограничьте размер набора на старт (например, 150-300 вопросов), чтобы его реально прогонять

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

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

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

Эталонные ответы и источники: как сделать проверяемо

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

Как описывать эталон

Эталонный ответ лучше хранить не как один «идеальный текст», а как набор требований. Это дает свободу формулировок и снижает количество ложных «неверно», когда модель сказала то же самое другими словами.

Обычно достаточно:

• «ожидаемого итога» в 1-2 фразы
• обязательных фактов: числа, сроки, роли, условия, ограничения
• допустимых вариантов (например: «можно выбрать А или Б при условии Х»)
• границ ответа: что нельзя утверждать (например: «гарантируем поставку за 24 часа»)
• правил на случай неопределенности: какие уточняющие вопросы модель обязана задать

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

Как прикладывать источники и проверять ссылки

У каждого обязательного факта должен быть якорь на источник: документ, раздел или пункт, версия и дата. Удобно добавлять короткую цитату (1-2 строки) рядом с эталоном, чтобы проверяющий не «искал по памяти». Корректной ссылкой считайте не «согласно регламенту», а то, по чему человек реально найдет место: название документа + пункт (или раздел) + версия/дата.

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

Политика обновления проста: если меняется регламент, меняются и тесты. Назначьте владельца документа, который раз в месяц проверяет актуальность версий и помечает эталоны как «обновить до даты Х». Если изменения частые (например, в проектных отделах и интеграции), полезно хранить историю версий эталона, чтобы понимать, почему оценка «вдруг ухудшилась» после обновления правил.

Метрики и шкалы: чем измерять качество

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

Практичный набор метрик чаще всего включает:

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

Проверяемость полезно выделять отдельно. Если сотрудник спрашивает: «Какие документы нужны для закупки оборудования по нашему регламенту?», модель должна опираться на внутренний регламент закупок, а не на «обычно принято». Если источник не указан или указан не тот, даже грамотный текст часто нельзя выпускать в работу.

Отдельный блок - безопасность. Тут оценивают не стиль, а риски: запрещенные советы (например, обход проверок), утечки персональных данных, разглашение внутренних сведений, уверенные ответы там, где нужно сказать «не знаю» и запросить уточнение.

Для частично правильных ответов удобна простая шкала 0-2:

• 0: неверно или опасно
• 1: частично верно, но есть пропуски или нет подтверждения источником
• 2: верно, полно, проверяемо и безопасно

Экспертная оценка нужна там, где много нюансов: юридические формулировки, финконтроль, медицинские данные, сложные закупки. Для типовых FAQ, форматирования писем, поиска документа и базовых справок часто хватает чеклистов, если источники подключены и реально проверяются.

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

Чтобы прогон был честным, сначала «заморозьте» условия: один и тот же промпт, одинаковые системные правила, одинаковые инструменты (например, доступ к базе знаний) и одна температура. Иначе вы сравниваете не модели, а настройки.

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

Удобно вести единый протокол на каждый тест-кейс:

• вопрос и контекст (роль пользователя, канал, язык)
• ответ модели (как есть, без правок)
• источники или цитаты, если они требуются
• оценка по шкале и причина
• комментарий: что именно не так и как исправить

Офлайн и онлайн прогоны

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

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

Хранение и сравнение по месяцам

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

A/B при смене модели: как сравнивать честно

Честное A/B сравнение нужно, когда вы меняете не только саму LLM, но и то, как она работает в вашем контуре. Иначе легко приписать модели то, что изменилось из-за промпта, базы знаний или настроек выдачи. Если ваша цель - измерить качество, сначала зафиксируйте все остальное и сравнивайте один фактор за раз.

Что именно фиксируем

Перед прогоном договоритесь, что считается «вариантом A» и «вариантом B». Обычно сравнивают изменения в модели или провайдере, системном промпте и шаблоне ответа, базе знаний и правилах поиска, ранжировании фрагментов (что попадает в контекст), настройках безопасности (фильтры, запреты, политика отказа).

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

Как принять решение

Критерии победы задавайте не через «в среднем лучше», а через пороги. Например: точность не ниже N, доля опасных советов - строго ниже M, процент ответов с корректными ссылками на источник - не ниже K. Полезно смотреть отдельно по сегментам: финансы, закупки, HR, техподдержка. Одна и та же модель может быть сильной в одном департаменте и заметно слабее в другом, и это теряется в общей средней.

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

Частые ошибки и ловушки при оценке LLM

Самая частая ошибка - перепутать, что именно вы улучшаете. Команде может нравиться, что модель отвечает быстро и уверенно, но пользователям важнее точность и проверяемость. Если боль в ошибочных фактах, метрики скорости и «красоты текста» только отвлекают.

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

Слишком общие вопросы тоже портят картину. Формулировки вроде «расскажи про закупки» или «объясни политику компании» трудно проверять фактами, и оценка превращается во вкусовщину. Лучше задавать вопросы, где есть конкретная проверка: сумма, срок, исключение, шаг процесса, ссылка на пункт документа.

Когда тест-пакет перестает быть тестом

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

Путаница с источниками и версиями

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

Быстрый чеклист перед релизом или сменой модели

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

Проверьте шесть вещей, без которых результаты тестов обычно «плывут»:

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

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

Небольшой ориентир: в компании с разными функциями (например, у производителя и интегратора вроде GSE.kz) часто всплывает перекос, когда модель отлично отвечает по IT, но путается в закупочных правилах или финансовых формулировках. Чеклист помогает увидеть это до релиза.

Пример: как компания оценивает ассистента для финслужбы и закупок

Представим внутреннего ассистента для финансов и закупок в производственной компании вроде GSE.kz: сотрудник пишет вопрос в чат, а ассистент отвечает по правилам согласований, оплат и закупок. Цель тестов простая: ответы должны быть точными, проверяемыми и безопасными, без выдуманных правил и «советов на глазок».

Тест-пакет собрали из реальных обращений за 2-3 месяца и добавили вопросы, которые часто приводят к ошибкам. В итоге получился набор, где важны и факты, и аккуратные формулировки.

Примеры вопросов из тестов:

• Какой лимит закупки возможен без тендера и кто утверждает?
• Какой маршрут согласования для договора с новым поставщиком?
• Дай шаблон письма поставщику о переносе срока поставки.
• Когда ожидается оплата по счету, если он уже согласован?
• Какие документы нужны для закрытия аванса?

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

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

После прогона приняли решения:

• дополнили базу знаний «пограничными» кейсами и примерами
• усилили запреты на обещания по срокам оплат и «догадки» по лимитам
• добавили правило: при неясном контексте задавать 1 уточняющий вопрос
• повторили A/B на обновленном наборе и зафиксировали улучшения

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

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

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

Закрепите процесс и ответственность

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

• владелец департамента раз в месяц добавляет 5-15 новых реальных вопросов в тест-пакет
• координатор раз в неделю делает короткий прогон и собирает проблемы в один список
• источники (политики, регламенты, прайс-листы) хранятся с версией и датой
• любое изменение промпта, инструмента поиска или модели проходит через тесты
• есть единое место, где видна история результатов и причины падений

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

Внедряйте через пилот и пороги качества

Держать качество проще, когда есть понятные пороги и постепенное расширение:

• пилот на 1-2 департаментах с ограниченным кругом задач
• порог качества для релиза (например, точность по критическим вопросам и отсутствие ошибок с источниками)
• ограниченный запуск на часть пользователей и сбор обратной связи
• расширение на новые департаменты только после двух стабильных прогонов подряд

Если параллельно нужно выстроить инфраструктуру для AI, хранение и версионирование источников, а также надежный контур для прогонов и мониторинга, это часто делают вместе с GSE.kz (gse.kz) как с производителем и системным интегратором, который также предоставляет 24/7 техническую поддержку. Главное, чтобы техническая часть поддерживала дисциплину обновлений и проверок, а не подменяла ее.