Тестирование качества мультиязычного RAG: метрики и тесты

Что значит «качество» в двуязычном RAG на практике

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

На практике сотрудники жалуются не на «плохую модель», а на очень конкретные сбои:

• не нашел нужный документ или раздел;
• нашел похожее, но не про то (ошибка по смыслу);
• ответил верным содержанием, но не тем языком;
• перепутал термины на казахском и русском или «смешал» их;
• дал уверенный ответ без опоры на найденный текст.

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

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

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

Эти решения превращают «качество» из ощущения в проверяемые критерии.

Типы запросов, которые обязательно должны быть в тестах

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

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

Второй класс - смешанные формулировки. В одной фразе часто встречаются RU + KZ, а еще транслит, опечатки и разговорные сокращения. Например: «Маған керек акт сверки по контрагенту, где шаблон?» или «Сатып алу бойынша лимит кто утверждает?». Такие запросы быстро выявляют слабые места токенизации и словарей.

Полезно зафиксировать ролевые сценарии, чтобы покрыть разные задачи и стиль вопросов. Минимальный набор ролей:

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

Отдельная зона риска - узкая терминология и аббревиатуры. Это внутренние коды, названия систем, сокращения отделов, модели оборудования. Например, в компании вроде GSE.kz сотрудники могут спрашивать про «S200», «M200», «L200», «сервер стойка», «24/7 поддержка», а в документах это бывает оформлено по-разному на RU и KZ.

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

Как собрать тестовый корпус двуязычных документов

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

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

Отдельно подготовьте двуязычные пары и «неполные переводы». В реальности часть материалов бывает только на русском, часть - только на казахском, а часть - смешанная (заголовки на KZ, тело на RU, или наоборот). Старайтесь сохранять эту структуру как есть: она важна и для поиска по терминологии, и для смешанных запросов.

Практичный минимум для корпуса:

• 20-30 ключевых регламентов и инструкций (KZ, RU, смешанные);
• 30-50 FAQ и коротких справок (часто лучше всего выявляют ошибки);
• 10-20 типовых писем и формулировок (важны для точных цитат);
• 5-10 документов с частичными переводами (для проверки «дырок»);
• 5-10 устаревших версий (для тестов на актуальность).

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

Как сделать набор тестовых вопросов и ожидаемых ответов

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

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

Чтобы ожидания были проверяемыми, фиксируйте их не одним «идеальным ответом», а набором условий:

• какие источники обязаны быть найдены (конкретные документы или разделы), а какие допустимы как запасные;
• какие факты должны прозвучать (2-5 коротких пунктов) и какие формулировки допустимы;
• какой язык ответа ожидается (язык вопроса или язык последней реплики в диалоге);
• какие ограничения важны (например, «не придумывать сроки», «если данных нет - сказать, что не найдено в документах»);
• 2-3 приемлемых варианта ответа, если их действительно может быть несколько.

Простой пример для двуязычной базы: вопрос сотрудника «Серверлер S200 бойынша кепілдік қалай беріледі? 24/7 қолдау бар ма?» Ожидание можно описать так: система должна сослаться на материалы про линейку S200 и поддержку; в ответе обязаны быть упомянуты 24/7 техническая поддержка и наличие сервисной сети (без выдуманных сроков гарантии, если их нет в документах).

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

Метрики извлечения: проверяем, что система находит нужное

В RAG чаще всего ломается не генерация, а поиск: модель отвечает уверенно, но опирается не на те фрагменты. Поэтому в оценке качества сначала смотрят извлечение: нашлись ли правильные документы и попали ли они в верх выдачи.

Самая полезная метрика здесь - Recall@K. Она отвечает на вопрос: «Если правильный документ вообще есть в базе, попал ли он в первые K результатов?». Для двуязычной базы это критично: запрос на русском может требовать казахский регламент, и наоборот.

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

Когда нужно понять, насколько высоко поднимаются правильные источники, помогают ранжирующие метрики:

• MRR: на каком месте в среднем появляется первый правильный документ;
• nDCG: учитывает, что у ответа может быть несколько релевантных источников с разной «силой»;
• покрытие источников: доля вопросов, где в топ-K вообще нашелся хотя бы один правильный документ.

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

Не забывайте про скорость и стабильность поиска. Смотрите не только среднее время, а медиану и «хвосты» (например, 95-й перцентиль): пользователи замечают именно редкие, но долгие ответы. Если после обновления индекса хвосты растут, качество ощущается хуже, даже если Recall@K не изменился.

Метрики генерации: проверяем качество самого ответа

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

Факты только из источников

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

Полнота, язык и проверяемость

Чтобы проверка была быстрой и одинаковой у разных проверяющих, используйте простую рубрику (0-2 балла за пункт):

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

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

Терминология и словари: отдельные тесты для KZ и RU

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

Сначала соберите список терминов KZ и RU из реальных документов: названия должностей, подразделений, типов документов, продуктов и стандартов. Для каждого термина фиксируйте 2-3 варианта: перевод, синоним, частые написания (латиница/кириллица, слитно/через дефис, с точками). Например, внутри компании могут встречаться «S200», «С200» и «сервер S200», а для стандартов - «ISO 9001» и «ИСО 9001».

Полезно завести небольшой «словарный» набор вопросов, где правильный ответ зависит от точного понимания термина. Обычно достаточно 30-80 терминов, но они должны быть критичными.

Что именно тестировать

Проверьте, что система одинаково хорошо ищет и отвечает при разных формах одного понятия:

• синонимы и варианты написания (KZ/RU, кириллица/латиница);
• аббревиатуры и внутренние сокращения (полная форма и 1-2 коротких варианта);
• похожие по смыслу слова, которые нельзя путать (должность vs подразделение, приказ vs распоряжение);
• «шумные» совпадения, когда термин встречается в другом контексте.

Формы слов без завышенных требований

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

Простой сценарий для теста: сотрудник спрашивает «Кім жауапты за 24/7 қолдауды?» и «Кто отвечает за 24/7 поддержку?». В обоих случаях система должна извлечь один и тот же фрагмент политики или регламента и не подменить «поддержку» на «внедрение» только из-за похожих слов.

Смешанные запросы и переключение языка в диалоге

Смешанные запросы выглядят так: «Найди приказ по охране труда и дай summary на казахском» или «Сколько гарантия на сервер S200? жауапты бөлім кім?». Здесь важно заранее зафиксировать ожидаемое поведение: какой язык ответа главный, можно ли смешивать языки в одном ответе и что считать ошибкой.

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

Проверьте переключение языка по цепочке из 2-3 реплик. Например: сотрудник сначала спрашивает по-русски про закупочную форму, потом уточняет по-казахски, а затем просит коротко и снова по-русски. В тесте фиксируйте не только финальный ответ, но и то, сохранила ли система контекст.

Частичный перевод допустим, когда термин является официальным названием, кодом модели или юридической формулировкой. Например, «S200 Series», «ISO 9001» или название отдела лучше оставить как есть, но расшифровать рядом простыми словами.

Короткий набор проверок для тест-кейса:

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

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

Пошаговый процесс тестирования качества мультиязычного RAG

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

Дальше важно «заморозить» данные. Сохраните версии документов, по которым строится индекс, и отмечайте дату, источник и язык. Иначе будет непонятно, это улучшение модели или просто поменялся текст в PDF.

Практичный процесс:

• определите 8-12 сценариев и критерии «проходит/не проходит» (точность, полнота, язык ответа, обязательная цитата источника);
• соберите корпус и зафиксируйте его версию: файлы, OCR, разбиение на чанки, настройки индекса;
• подготовьте 50-150 вопросов, включая смешанные (KZ+RU) и с внутренней терминологией; разметьте ожидаемые документы и фрагменты;
• прогоните тесты и отдельно снимите метрики извлечения и метрики генерации;
• разберите провалы по категориям и внесите точечные изменения: чанки, фильтры языка, словарь терминов, промпт, ранжирование.

После правок повторите прогон на том же наборе. Если метрики выросли, но пользователю стало хуже, значит критерии приемки выбраны неверно.

Небольшой пример для компании вроде GSE.kz: вопрос «гарантия на S200 сервер қанша?» должен привести к правильному регламенту и выдать ответ на языке пользователя, сохранив точные сроки из источника. Такой кейс сразу проверяет и переключение языка, и терминологию, и честность цитирования.

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

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

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

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

Чтобы не размазывать ошибки:

• разделяйте проверки: сначала retrieval (нашли ли нужный фрагмент), потом generation (как сформулировали ответ);
• держите два набора: маленький «быстрый» и большой регрессионный, который нельзя менять каждую неделю;
• добавьте тесты на свежесть: один и тот же вопрос до и после обновления документа;
• проверяйте язык и терминологию отдельно: KZ-термины, RU-термины и смешанные запросы.

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

Быстрый чеклист перед внедрением и каждым обновлением

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

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

Минимум, который стоит проверить:

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

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

Практический прием: держите небольшой smoke-набор из 20-30 вопросов (поровну RU/KZ, часть смешанных) и гоняйте его при каждом изменении модели, индекса, словаря или набора документов. Это быстро показывает, что сломалось - поиск или формулировка ответа.

Пример реалистичного сценария: внутренний помощник для сотрудников

Представьте внутреннего помощника для сотрудников производственной и ИТ-организации в Казахстане, где документы и общение идут на русском и казахском. Его используют для быстрых ответов по регламентам, закупкам и ИТ-заявкам. На таких кейсах тестирование качества мультиязычного RAG чаще всего вскрывает скрытые проблемы.

Типовые вопросы выглядят буднично, но в них много «ловушек»: разные формулировки, аббревиатуры, смешение языков, местная терминология. Например:

• «Какой срок согласования заявки на закупку до 1 млн тенге?»
• «Маған ноутбук беру тәртібі қандай? Қандай құжат керек?»
• «Где посмотреть статус заявки в Service Desk и кто SLA владелец?»
• «Нужно ли согласование ИБ для установки ПО, если это обновление драйвера?»
• «Қоймаға қабылдау актісін кім бекітеді?»

А еще встречаются смешанные: «Жөндеу үшін RMA қалай ашамын и какие поля обязательны?» и «Для S200 серия серверов гарантия қанша жыл?».

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

Что обычно помогает: пересобрали разбиение на фрагменты (чтобы шаги процедуры не рвались), добавили словарь терминов и аббревиатур (SLA, RMA, ИБ, KZ/RU варианты), усилили проверку цитат (ответ без подтверждающих фрагментов помечается как рискованный).

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

Следующие шаги: как сделать тестирование регулярным процессом

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

Рабочее правило: один и тот же тестовый прогон делается (1) перед релизом, (2) сразу после обновления контента, (3) по расписанию, например раз в неделю, чтобы ловить тихие деградации.

Чтобы процесс прижился, роли лучше закрепить заранее:

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

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

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

Если вы планируете внедрение RAG и инфраструктуры под него, заранее продумайте, где будут жить данные, как масштабировать вычисления и как организовать поддержку. В таких задачах GSE.kz может помочь как системный интегратор: подобрать серверы и платформу под нагрузку, выстроить решение без привязки к одному вендору и обеспечить поддержку 24/7.