Гайд · TNWS AI

Как исключить документ другой локали из RAG-ответа на русском языке

6 мин—

Проверяем locale у найденных документов до генерации русскоязычного ответа: сопоставление версий и точный негативный пример.

Задача и граница применения

Не подмешивать в русскоязычный ответ инструкцию из другого языкового или регионального каталога с иными условиями. Поле locale должно быть проверенным метаданным источника, а не догадкой языкового детектора по двум предложениям. Для запроса ru-RU в примере допускается только точное совпадение ru-RU. Это строгая политика для гипотетического регламента: если продукт официально разрешает fallback на ru или en, его нужно описать отдельно. Здесь en-US документ имеет схожее название, но другой текст; модель не должна видеть его только потому, что он занял первое место в общей выдаче. Не считайте en-US и ru-RU автоматически взаимозаменяемыми даже при одинаковом названии документа. Если источники имеют разные даты действия, локаль лишь один из необходимых фильтров. Негативный тест можно усилить: подменить locale у D-EN на ru-RU и убедиться, что текущий код примет его; это показывает зависимость от качества метаданных и необходимость редакционного контроля. Не пытайтесь компенсировать неверную разметку настройкой промпта: модель уже получила ошибочный источник. Этот практический сценарий рассчитан на команду, которая контролирует данные для поискового слоя RAG и может хранить синтетические фикстуры в репозитории. Он не требует отправлять реальные клиентские документы стороннему сервису. Все ID, вопросы и численные результаты ниже сконструированы только для демонстрации. Проверка официальной документации Python и синтаксиса GitHub Actions: 19.09.2026; в собственном окружении перепроверьте версии перед запуском.

Как подготовить фикстуру

D-EN en-US говорит «Support until Tuesday», D-RU ru-RU говорит «Поддержка до пятницы». Для запроса ru-RU остаётся только D-RU. Сначала отделите эталон, согласованный человеком, от фактической выдачи поисковой системы. Не исправляйте gold по результатам модели: иначе тест перестанет быть независимым. Стабильный идентификатор вопроса позволит повторить сбой без публикации текста закрытой заявки. Если документы меняются, записывайте номер версии индекса и дату действия содержимого, иначе повторная проверка через месяц будет сравнивать разные базы.

Шаблон входа для переноса примера на свою коллекцию: для каждого вопроса заведите поля id, question, expected_doc_ids, retrieved_doc_ids и, где требуется, index_version. Согласуйте с предметным владельцем, что именно считается релевантным, доступным и актуальным источником. Это рабочая схема сбора данных, а не универсальный формат API. В таблице ревью отдельно отметьте спорные случаи, которые нельзя разрешить одной лишь строковой операцией.

Пошаговая проверка

  1. Создайте файл scripts/check_retrieval.py; скопируйте Python-шаблон целиком. Использованные названия библиотечных функций сверены с официальными страницами в конце статьи.
  2. Запустите python scripts/check_retrieval.py локально. Сопоставьте консольный вывод с ожидаемым результатом в описании входа; демонстрация обязана проходить без внешнего API и ключей.
  3. Проверьте, что locale приходит из редакционного каталога и проверяется при индексации. Запустите скрипт для ru-RU, затем повторите для en-US и убедитесь, что состав выдачи изменился ожидаемо. В рабочей системе фильтруйте по locale на уровне поиска, а перед генерацией повторно контролируйте выбранные документы. Не переводите en-US регламент машиной как замену отсутствующему ru-RU: условия могут различаться независимо от языка. Если локальных источников нет, верните явный статус и запросите редакционную проверку.
  4. Для регрессии положите тот же файл в репозиторий и добавьте workflow из второго блока в .github/workflows/rag-retrieval.yml. Проверка запускается на pull_request с разрешением contents: read; не передавайте в неё настоящие секреты и закрытые документы.
  5. Откройте job retrieval-check в Actions на конкретном коммите. Сравните исходные ID и обнаруженные нарушения с локальным прогоном. При расхождении проверьте версию фикстур и скрипта, а не меняйте эталон до выяснения причины.
# scripts/check_retrieval.py
rows=[{"id":"D-EN","locale":"en-US","text":"Support until Tuesday"},
      {"id":"D-RU","locale":"ru-RU","text":"Поддержка до пятницы"}]
def select(rows,requested):
    if requested not in {"ru-RU","en-US"}:
        raise ValueError("unsupported locale")
    return [r for r in rows if r.get("locale")==requested]
chosen=select(rows,"ru-RU")
assert [r["id"] for r in chosen]==["D-RU"]
assert "Support" not in repr(chosen)
print("Allowed IDs:",[r["id"] for r in chosen])
name: RAG retrieval contract
on:
  pull_request:
permissions:
  contents: read
jobs:
  retrieval-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-python@v7
        with:
          python-version: '3.13'
      - run: python scripts/check_retrieval.py

Реалистичный пример результата

Вход: D-EN en-US говорит «Support until Tuesday», D-RU ru-RU говорит «Поддержка до пятницы». Для запроса ru-RU остаётся только D-RU. После запуска ожидается исход, явно проверяемый инструкциями assert в коде. Не публикуйте вымышленное значение как измеренную характеристику вашей поисковой системы. Для рабочего отчёта приложите версию индекса, выбранные фильтры, размер размеченного набора, дату фиксации эталона и список ID провалившихся случаев. По каждому ID откройте первичный документ, прежде чем менять конфигурацию ранжирования: неправильно размеченный источник может выглядеть как технический дефект.

Типовые ошибки и ограничения

Совпадение locale не доказывает фактический язык или актуальность содержания. Региональная применимость и пользовательские права требуют отдельных метаданных. Проверка строки в repr — только демонстрационный негативный assert, не полноценный аудит утечек. При расширении теста сначала добавьте отрицательный случай: намеренно испортите один элемент фикстуры и убедитесь, что проверка обнаружила его. Затем верните исходный набор и проверьте положительный случай. Это важнее зелёного CI на данных, где ошибка случайно отсутствует. Не логируйте полный ответ модели, содержимое закрытых документов или персональные сведения только ради диагностики.

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

Чек-лист финальной проверки

  • Задача теста и применимость понятны владельцу корпуса.
  • Входные ID и эталон не взяты из ответа оцениваемой модели.
  • Демо запускается локально и даёт ожидаемый результат.
  • Преднамеренно неверный вход обнаруживается проверкой.
  • Зафиксированы версия индекса, редакция документов и условия доступа.
  • В логах CI нет приватных документов и секретов.
  • Разделены ошибка поиска, ошибка эталона и ошибка генерации.
  • После исправления проверены соседние пограничные случаи.

FAQ

Почему не доверять определению языка по тексту?

Короткие документы и названия могут давать ошибочную локаль; используйте утверждённые метаданные.

Можно ли fallback на общий ru?

Да, только по заранее согласованной политике применимости.

Что делать с двуязычным документом?

Оформить явно две локальные редакции или проверяемую политику общего источника.

Достаточно ли locale для допуска?

Нет, проверьте также права доступа, дату и версию.

Что делать, если тест не прошёл

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

Официальные первоисточники

Проверено 19.09.2026: документ 1, документ 2, документ 3, документ 4. Описание и примеры написаны самостоятельно; при переносе на другое окружение перепроверьте названия функций и синтаксис workflow.

Читайте также

Комментарии

Пока тихо. Скажите первое слово