Какой API выбрать для RAG-проекта: проверяем критерии команды

Короткий ответ и граница сценария

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

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

Практический план

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

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

Сравнивайте кандидатов по этапам. Сначала retrieval: попадает ли нужный документ в верхнюю часть выдачи, можно ли объяснить его источник и не смешиваются ли закрытые разделы. Затем generation: сохраняется ли смысл, есть ли ссылка на отобранный фрагмент, умеет ли приложение показать «нет достаточных данных». Наконец, инженерная часть: формат ошибок, request ID, timeouts, политика повторов, контракт SDK и доступность тестового маршрута.

Стоимость считайте как диапазон своего сценария, а не как обещанную цену. Учтите индексирование, поиск, размер передаваемого контекста, повторные запросы и ручную проверку. Тарифы, валюты, model ID и условия могут меняться, поэтому источником расчёта служат актуальная консоль и договорные условия. Не переносите оценку из тестового набора на весь продукт без измерения распределения запросов.

Server-side граница и данные

Клиент передаёт только необходимый для продукта ввод. Backend получает tenant и права из своей сессии, применяет allowlist полей, формирует минимальный вызов и проверяет результат как недоверенные данные. Секрет RussiaAPI хранится только в окружении или защищённом server-side secret store.

Не записывайте ключи, cookies, Authorization, полный текст prompt, полный ответ модели, файлы или временные ссылки в обычную телеметрию. Для поддержки обычно достаточно request ID, версии адаптера, класса результата, времени и обезличенного идентификатора tenant. Политику хранения и доступ к журналам определяет ваша организация.

Наблюдаемость и доказательства

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

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

Проверка и обратимый rollout

Проверьте позитивный и негативный набор на synthetic test tenant: корректный сценарий, пустой ввод, неизвестный параметр, отсутствие прав, timeout и отмену. Фиксируйте дату, версию правила и ожидаемое безопасное действие. Тест показывает только поведение вашего сценария на момент проверки, а не постоянную характеристику модели или сети.

Включайте изменение на ограниченном сегменте через server-side feature flag. До rollout определите метрики, порог остановки и предыдущий проверенный путь. При аномалии выключите новый маршрут, сохраните минимальную техническую трассу и разберите причину без расширения логов пользовательским содержимым. Обсудите результат с владельцем продукта до следующего расширения: техническая проверка не отменяет ответственность за данные, пользовательские уведомления и допустимый сценарий.

Server-side пример

Пример показывает локальную защиту приложения. Ключи берутся только из окружения; перед запуском подтвердите маршрут, model ID и параметры в актуальном каталоге RussiaAPI.

export function selectRagRoute({ tenant, evaluation, policy }) {
  if (!policy.allowedTenants.has(tenant)) throw new Error('tenant_not_allowed');
  if (evaluation.retrievalRecall < policy.minRecall) return { route: 'manual_review' };
  if (evaluation.unsafeCitationCount > 0) return { route: 'citation_fix_queue' };
  return { route: 'limited_rollout', rolloutPercent: policy.initialPercent };
}
// Evaluation records contain synthetic IDs and metrics, never API credentials or document text.

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