Если вы делаете RAG-поиск по документации или базе знаний, рано или поздно сталкиваетесь с проблемой: хорошо найти — это ещё не значит хорошо ответить.

База знаний, RAG, найденные чанки, LLM формирует ответ. Но пользователь не видит чанки, DCG или Recall@10. Он видит только итоговый текст. А здесь и начинаются сложности. Даже если нужные фрагменты найдены, модель может их проигнорировать, ответить на другом языке, добавить «от себя» или выдать уверенный, но бессмысленный текст. И доказать, что после правок стало лучше, — отдельная задача.

Ранее мы улучшали retrieval: чанкование, метаданные, гибридный поиск, реранкинг. Но когда поиск стал стабильным, встал вопрос: как оценить качество самого ответа?

С чего всё началось

Изначально у нас была базовая система:

• Сбор бенчмарка вопросов.
• Хранение эталонных ответов.
• Прогон retrieval.
• Анализ топ-чанков.
• Подсчёт метрик вроде recall и DCG.

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

Проблемы генерации

Модель может:

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

Retrieval может быть идеальным, а ответ — неприемлемым. Значит, нужно оценивать не только найденное, но и сгенерированное.

Шаг 1. LLM-as-Judge

Первая идея — сравнить ответ модели с эталоном. Но нас интересовало не буквальное совпадение, а смысл. Поэтому мы перешли к схеме LLM-as-Judge: на вход — вопрос, эталон, ответ модели; на выходе — оценка.

Это работало лучше, чем текстовые метрики: модель-судья не штрафовала за разные формулировки, если смысл был верным. Но у подхода была проблема: одна общая оценка (например, 75 из 100) не объясняла, почему ответ не идеален.

Шаг 2. Разбили качество на подметрики

Мы выделили три ключевых аспекта:

• Coverage — насколько ответ охватывает эталон по смыслу. Если в эталоне было несколько ключевых пунктов, а модель упомянула только часть, coverage падает.
• Groundedness — насколько ответ опирается на предоставленный контекст. Важно, чтобы модель не додумывала «по себе», а использовала найденные чанки.
• Factuality — корректность фактов относительно эталона. Ответ может быть полным и обоснованным, но содержать ошибки.

Теперь вместо одного числа — понятная картина: где именно система проседает.

Шаг 3. Сделали судью предсказуемым

Чтобы judge-модель оценивала стабильно, мы внесли два изменения:

• Передавали судье не только ответ, но и реальные чанки — в виде нумерованного списка. Это позволило точно проверять groundedness.
• Перевели judge в JSON-режим. Теперь на выходе — структурированные данные: оценки по каждой метрике, комментарии. Это упростило автоматизацию и сравнение.

Шаг 4. Добавили проверки, которые судья может пропустить

Некоторые ошибки лучше ловить в коде:

• Язык ответа. Если сценарий русскоязычный, а модель отвечает по-английски — это провал. Мы добавили флаг language_ok и включили его в итоговый скор.
• CJK-символы. У некоторых моделей в ответах появлялись иероглифы. Это артефакт, портящий восприятие. Мы добавили отдельную проверку на наличие таких символов.

Шаг 5. Собрали итоговый скоринг

Мы объединили три метрики в один балл с весами:

• Factuality — 0.40
• Groundedness — 0.35
• Coverage — 0.25

Фактическая корректность важнее всего, затем — опора на контекст, затем — полнота. Далее — штрафы:

• Неверный язык — снижение балла.
• Наличие CJK-символов — снижение балла.

Результат приводится к шкале: 0 / 25 / 50 / 75 / 100. Шкала грубая, но понятная и воспроизводимая. Точность вроде 78.43 не даёт реального преимущества.

Шаг 6. Создали валидатор для честного сравнения

С ростом числа конфигураций ручное сравнение стало невозможным. «Модель» — это не только архитектура, но и квантизация, провайдер, задержка, judge-модель и т.д.

Мы создали rag-validator — сервис, где можно:

• Выбрать набор вопросов.
• Выбрать конфигурацию модели.
• Прогнать бенчмарк.
• Сохранить: вопрос, эталон, ответ, чанки, подметрики, итоговый балл.
• Сравнить результаты в таблицах.

Только с таким стендом сравнение стало объективным.

Результаты тестов

Мы увидели:

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

Одна и та же модель в разных условиях ведёт себя по-разному.

Выбор для локального запуска

Облачные Qwen3.5 MoE лидируют, но нам нужна модель, которую можно запустить локально в пределах 40 ГБ VRAM без потерь в качестве.

Qwen3.5-9B FP16 оказалась слабой. Qwen3.5-27B FP8 — лучше, но медленная. Gemma 4 31B и 26B A4B — без существенного выигрыша.

Лидером стала Qwen3.5-35B-A3B-GPTQ-Int4: высокое качество и хорошая скорость.

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

Главный вывод

Выбирать модель по общей таблице — плохая идея. Важно, как она работает в вашем сценарии. Именно это и определило наш выбор.

Что дальше

Модели быстро обновляются. Мы будем регулярно тестировать их на своём бенчмарке.

Наш сервис оценки позволяет:

• Отслеживать результаты.
• Сравнивать модели и версии.
• Добавлять новые кандидаты.
• Детально анализировать ответы, контекст и метрики по каждому вопросу.

Методика будет развиваться: уточним метрики, добавим новые показатели и улучшим проверку, чтобы результаты точнее отражали качество LLM в задачах Gramax.

Если вы делаете RAG-поиск по документации или базе знаний, то рано или поздно упираетесь в проблему: хорошо найти — это еще не хорошо ответить.

База знаний, RAG, найденные чанки, LLM строит ответ. Но пользователь не знает ни про DCG, ни про Recall@10, ни про чанки вообще. Он видит только то, что написано в итоговом ответе. А проблемы начинаются именно здесь. Нашел нужные чанки — молодец. Но модель может их проигнорировать, ответить на другом языке, добавить что-то от себя или выдать уверенный текст с иероглифами посередине. И как потом доказать, что после правок стало лучше — тоже не очевидно.

В прошлой статьемы разбирали, как улучшали сам retrieval: чанкование, метаданные, гибридный поиск, реранкинг. Но после того как с поиском более-менее разобрались, встал другой вопрос —как вообще понять, хороший ли ответ получает пользователь?

Привет, меня зовут Дима, я делаю ИИ-функции вGramax. В этой статье расскажу, как мы выстроили методику оценки ответов RAG-поиска. Заодно поделюсь, какая модель прямо сейчас дает лучший результат на наших задачах.

С чего все началось

Стартовая точка у нас была вполне обычная. Кое-что уже работало:

• Собирать бенчмарк вопросов.
• Хранить эталонные ответы.
• Прогонять retrieval.
• Смотреть, какие чанки попали в топ.
• Считать метрики вроде recall и DCG.

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

Модель в любой момент может:

• Не использовать важный фрагмент из контекста.
• Упростить ответ так, что потеряется половина сути.
• Добавить лишние факты от себя.
• Ответить красиво, уверенно и неправильно.
• Неожиданно уйти в другой язык.
• Выдать экзотические символы там, где их никто не звал.

Retrieval хороший, а продуктовый результат — нет. И это значит, что нужно оценивать не только то, что нашли, но и то, что в итоге написали. Первая наивная идея: давайте сравнивать ответы с эталоном. Логика простая: есть вопрос, есть эталонный ответ, есть то, что выдала модель. Берем и сравниваем.

Шаг 1. Подключили LLM-as-Judge

Нас интересовало не буквальное совпадение слов, а смысловое качество ответа. Поэтому быстро пришли к схеме LLM-as-Judge. Раз оценивать нужно по содержанию — пусть проверяет модель, которая умеет работать с текстом. Судье на вход: вопрос, эталон, ответ модели. На выходе — оценка.

Работало заметно лучше любых текстовых сравнений — судья хотя бы не штрафовал за другие формулировки, если по смыслу ответ верный. Но довольно быстро выяснилось, что и у этого подхода есть свой затык.

Главная проблема одной общей оценки: одно число вроде 75 из 100 — удобно для таблицы, но для работы бесполезно. Непонятно, почему 75, а не 100.

• Ответ неполный?
• Он не опирается на найденные чанки?
• Есть фактическая ошибка?
• Модель ответила не тем языком?
• Она слишком много додумала от себя?

Одно число все смешивает в кашу. Хочешь улучшать систему — нужны отдельные оси.

Шаг 2. Разложили качество ответа на части

Одна общая оценка говорит, что ответ плохой, но не объясняет, где именно. Мы решили разбить качество на части и остановились на трех подметриках.

1. Coverage.Насколько ответ покрывает эталон по смыслу. Здесь важно не совпадение по словам, а то, донесла ли модель ключевые факты, которые ожидались в ответе. Если в эталоне было несколько важных пунктов, а модель упомянула только часть из них, значит coverage будет проседать.
2. Groundedness.Насколько ответ опирается на тот контекст, который был передан модели. Для RAG это особенно важно. Ответ может выглядеть убедительно, но на деле быть построен не по найденным чанкам, а скорее по «общим знаниям» модели. В таком случае система вроде бы использует базу знаний, но по факту начинает додумывать сама.
3. Factuality.Насколько ответ корректен по фактам относительно эталона. Это отдельная метрика, потому что ответ может хорошо опираться на контекст, но оставаться неполным. Или наоборот — быть полным, но содержать одну-две фактические ошибки. Бывает и так, что ответ звучит уверенно и гладко, но по сути в нем есть неточности.

Вместо одного числа — понятное разложение: где именно просело — в полноте, в опоре на контекст или в фактах.

Шаг 3. Поняли, что судье тоже нельзя верить на слово

Дальше встала задача сделать так, чтобы judge-модель оценивала предсказуемо — а не как придется.

Во-первых, мы начали передавать судье реальные чанки.

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

Во-вторых, мы зафиксировали формат ответа судьи.

Чтобы не разбирать каждый ответ руками, перевели judge-модель в JSON-режим. На выходе получали структурированный результат примерно такого вида:

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

Шаг 4. Добавили то, что judge сам не всегда ловит

Не все стоит отдавать судье. Некоторые вещи надежнее проверять в коде напрямую. У нас таких было две.

Язык ответа

Если у нас русскоязычный сценарий, а модель отвечает по-английски — это уже провал, неважно насколько ответ точный по смыслу. Для пользователя это просто неверный результат. Вынесли проверку языка в отдельное полеlanguage_okи стали учитывать в итоговом скоре.

Иероглифы и другие CJK-символы

В тестах у некоторых моделей в ответах появлялись иероглифы — CJK-символы там, где им совершенно нечего делать. Это артефакт вывода, который портит ответ даже при правильном содержании.

На судью в этом случае не рассчитывали — сделали отдельную проверку в коде. Есть символы — фиксируем.

Шаг 5. Собрали итоговый скоринг, который можно воспроизводить

К этому моменту у нас сложилась уже нормальная схема. Берем три основные метрики:

• factuality
• groundedness
• coverage

Дальше считаем итоговый балл по весам:

• factuality — 0.40
• groundedness — 0.35
• coverage — 0.25

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

• Если ответ не на том языке — снижаем балл.
• Если в ответе нашли CJK-символы — тоже снижаем.

А потом приводим результат к шкале:0 / 25 / 50 / 75 / 100.

Шкала грубая, да. Но зато понятная и воспроизводимая. На практике оказалось, что делать вид, будто 78.43 чем-то принципиально точнее 75 не стоит.

Шаг 6. Поняли, что без отдельного валидатора все это нормально не сравнить

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

• Сама модель
• Квантизация
• Локальный или облачный запуск
• Провайдер API
• Разная задержка
• Разные judge-модели

Руками это сравнивать уже невозможно. Поэтому собрали отдельный сервис — стенд, где можно:

• Выбрать набор вопросов
• Выбрать конфигурацию chat-модели
• Прогнать один и тот же бенчмарк
• Сохранить вопрос, эталон, ответ, реальные чанки, подметрики judge и итоговый балл
• Потом сравнить все это в таблицах

Так появился rag-validator. Только с ним сравнение моделей стало хоть сколько-то честным — все прогонялись по одной схеме, а не оценивались по принципу «вроде вчера эта отвечала лучше». Сам валидатор покажу в конце.

Что показали реальные прогоны

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

• Размер модели
• Архитектура
• Квантизация
• Локальный или облачный запуск
• Конкретный провайдер
• judge-модель
• Задержка и скорость ответа

Название вроде само по себе мало что говорит. Одна и та же модель в разных условиях дает разный результат.

Что в итоге выбрали для локального запуска

В общей таблице наверху, конечно, облачные Qwen3.5 MoE. Но нам была нужна не самая сильная модель вообще, а та, которую можно нормально запустить локально в пределах 40 ГБ VRAM и при этом не потерять в качестве ответов.

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

Сразу стало понятно, что Qwen3.5-9B FP16, которую мы держали локально, уже не тянет. Qwen3.5-27B FP8 выглядела заметно лучше — и у GPT-5.1, и у DeepSeek V3.2 это было согласованно. Стало ясно: если менять локальную модель, смотреть надо как минимум в сторону 27B.

Кстати, иероглифы в ответах — это была только 9B. В облаке такого не было. Мелочь, но в рабочем сценарии неприятная.

Параллельно прогнали еще несколько кандидатов: Gemma 4 31B, Gemma 4 26B A4B, Qwen3-32B. Ничего неожиданного — результаты либо слабее, либо без достаточного выигрыша, чтобы что-то менять. После облачного этапа круг сузился до тех, кого уже имело смысл разворачивать локально.

Финальная таблица по локальным кандидатам

Таблица получилась довольно наглядная.

• Qwen3.5-9B — уже слабовата.
• Qwen3.5-27B FP8 — по качеству хороша, но работает слишком медленно.
• Gemma 4 31B — нормальный вариант, но без особых причин переходить именно на нее.

А вот Qwen3.5-35B-A3B-GPTQ-Int4 выбилась вперед: и качество лучше, и отвечает быстрее.

Локально оставляем Qwen3.5-35B-A3B-GPTQ-Int4.

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

Главный вывод, если совсем коротко: выбирать модель по общей таблице — плохая идея. Имеет смысл только то, как она ведет себя в твоем конкретном сценарии. У нас именно это и решило выбор.

Как будем с этим работать в будущем

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

Для этого мы подготовили сервис оценки, который позволяет:

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

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

Открыто, бесплатно, и с сообществом

• Смотрите наш сайт —https://gram.ax
• Проверяйте исходники вGitHubиGitVerse
• Вступайте в комьюнити —https://t.me/gramax_chat