RAG и данные

RAG и embeddings API для русских документов: как построить проверяемый поиск

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

Опубликовано 25 августа 2026 · 11 минут чтения · Ключевой запрос: RAG embeddings API русские документы

Определите задачу и границу данных

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

Не отправляйте в RAG всё подряд. Удалите дубли, устаревшие версии, секреты, персональные данные и документы без ясного основания для обработки. Для российских и трансграничных данных требования зависят от контекста, договора и применимого права; эта статья не является юридической консультацией. Проверьте с юристами и владельцем данных правила доступа, хранения, удаления и возможной передачи до загрузки корпуса.

Подготовьте русскоязычные документы

Качество поиска начинается до embeddings. Извлекайте текст с сохранением заголовка, версии, даты, владельца, языка и прав доступа. Сканы нуждаются в OCR и выборочной проверке: ошибка распознавания фамилии, номера договора или термина может сделать фрагмент не находимым. Таблицы, списки и код лучше хранить так, чтобы не смешивать несвязанные строки. Нормализация пробелов и кодировок полезна, но не должна незаметно менять смысл исходного документа.

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

Embeddings и поиск — отдельный контракт

Embeddings превращают текст в числовое представление для поиска близких фрагментов. Они не доказывают истинность документа, не заменяют права доступа и не гарантируют одинаковое качество для всех терминов. Перед использованием конкретной embedding-модели подтвердите её наличие и параметры в текущем каталоге RussiaAPI. Название OpenAI-совместимого маршрута не означает, что каждая модель, размер вектора или дополнительная возможность совпадает с другим сервисом.

Ниже приведён упрощённый серверный пример: он создаёт embedding для обезличенного тестового фрагмента и проверяет, что ответ имеет ожидаемую форму. Endpoint и model ID задаются через окружение. Добавьте свой vector store, аутентификацию и политику доступа отдельно; не отправляйте ключ или сырой закрытый документ в клиентский код.

const required = ['RUSSIAAPI_API_KEY', 'RUSSIAAPI_BASE_URL', 'RUSSIAAPI_EMBEDDING_MODEL'];
for (const name of required) if (!process.env[name]) throw new Error(`Missing ${name}`);

const response = await fetch(`undefined/embeddings`, {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.RUSSIAAPI_API_KEY}`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    model: process.env.RUSSIAAPI_EMBEDDING_MODEL,
    input: 'Обезличенный тестовый фрагмент документа.'
  }),
  signal: AbortSignal.timeout(15_000)
});
if (!response.ok) throw new Error(`Embedding request failed: ${response.status}`);
const data = await response.json();
if (!Array.isArray(data?.data?.[0]?.embedding)) throw new Error('Unexpected embedding response');
console.log({ dimensions: data.data[0].embedding.length });

На production-данных фиксируйте версию модели и схему индекса. Смена embedding-модели обычно требует отдельного переиндексирования и сравнения результатов, а не замены одной переменной на лету. Храните mapping между документом, версией, фрагментом и вектором, чтобы удалить или обновить записи без полной реконструкции базы.

Добавьте фильтры до генерации ответа

Векторная близость не должна обходить ACL. Сначала ограничьте поиск по организации, роли, проекту, языку, статусу документа и разрешённой версии, затем ранжируйте оставшиеся фрагменты. Идентификатор пользователя берите из своей сессии, а не из поля, которое прислал браузер. Если результат недоступен роли, он не должен попадать ни в prompt, ни в лог, ни в список «похожих документов».

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

Оцените RAG до подключения пользователей

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

Не подменяйте оценку одним понравившимся диалогом. Сравните разбиение, overlap, фильтры, top-k и шаблон ответа по одному изменению за раз. Версии набора, индекса и prompt должны быть воспроизводимыми. Если качество снижается после обновления модели или SDK, вернитесь к предыдущей конфигурации и разберите разницу на тестах. Методика выбора моделей по измеримым критериям собрана в статье о выборе модели для API.

Эксплуатация: обновления, наблюдаемость и стоимость

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

Для наблюдаемости достаточно агрегировать request ID, версию индекса, число найденных фрагментов, статус фильтров, задержку, модель и класс результата. Не логируйте полный текст пользователя, Authorization или закрытые chunks по умолчанию. Бюджетируйте отдельно embedding при загрузке и генерацию при ответе; это делает стоимость понятной и позволяет заметить, когда повторная индексация или слишком большой top-k расходует ресурс без улучшения качества.

Чек-лист RAG для русских документов

1. Для корпуса определены владелец, права, допустимые данные, срок хранения и удаление.
2. Текст прошёл извлечение и выборочную проверку OCR; у каждого chunk есть источник, версия и ACL.
3. Model ID и формат embedding подтверждены текущим каталогом, а ключ хранится на сервере.
4. Поиск сначала фильтрует доступ, затем ранжирует; при недостатке доказательств система честно отказывает.
5. Есть оценочный набор, версии индекса, метрики качества, контролируемый rollout и rollback.

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

FAQ

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

• Контекстное окно и бюджет токенов
• JSON Schema и проверка ответа
• Логи без утечки данных
• Документы RussiaAPI