В чём бизнес-задача

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

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

Три схемы, которые стоит сравнить

**1. Переводить документы до индексации.** Оригиналы остаются источником истины; рядом хранятся утверждённые переводы с одинаковыми идентификаторами разделов. Русский запрос ищет по русской копии. Плюс — понятная выдача для сотрудника. Минус — первоначальный перевод большого корпуса, повторный перевод изменений, хранение нескольких версий и редакторская проверка критических мест. Машинный перевод без контроля может изменить отрицание или артикул.

**2. Переводить вопрос при каждом запросе.** Поиск идёт по исходным английским документам; русский вопрос переводится один раз при обращении. Первоначальной переводной копии нет, обновления индексируются без отдельного перевода. Цена — дополнительный шаг на каждом запросе, задержка и риск неверно перевести термин пользователя. Итоговый ответ всё равно надо сформулировать по-русски и сверить с английским источником.

**3. Искать напрямую многоязычным эмбеддингом.** Документы и вопросы преобразуются одной совместимой моделью в векторы, индекс содержит фрагменты на исходном языке. Это убирает обязательный перевод на входе, но требует измерения качества именно на парах языков компании. Карточка BGE-M3 заявляет поддержку более 100 языков и вход до 8192 токенов, а также плотный и разреженный поиск; лицензия модели — MIT. Это характеристики инструмента, не обещание одинаковой точности для русского запроса по конкретным инструкциям.

В сентябрьском эксперименте Qdrant на наборе XRAG модель multilingual-e5-small находила релевантный фрагмент того же языка в первой десятке в 61% случаев, а соответствующий фрагмент другого языка — лишь в 8%. Это результат для одного набора данных и одной модели, не прогноз для российской фирмы. Исследование XRAG отдельно показывает: даже после корректного поиска генератор может ошибаться с языком ответа или рассуждением по разноязычным источникам. Поэтому качество поиска и качество ответа проверяются раздельно.

Модельный расчёт: где возникает расход

Возьмём **условный**, не принадлежащий реальной компании объём: 20 000 фрагментов документации по 1 000 знаков, 500 запросов в рабочий день, 22 рабочих дня в месяц и 10% обновляемого корпуса. Один вопрос для расчёта содержит в среднем 100 знаков. Цены на перевод, оборудование и труд здесь намеренно не подставлены: они зависят от среды, договора и качества.

  • Перевод всего корпуса потребует обработки примерно 20 млн знаков один раз; обновление 10% — ещё 2 млн знаков в месяц. Добавятся проверка и хранение параллельных версий.
  • Перевод вопросов потребует 500 × 22 × 100 = 1,1 млн знаков в месяц. Но перевод будет запускаться во время обращения и войдёт в задержку ответа.
  • Прямой многоязычный поиск не требует этих переводов для извлечения, зато надо один раз закодировать 20 000 фрагментов, затем кодировать каждый запрос, держать индекс и проверять межъязыковую выдачу. Русский ответ по английскому фрагменту всё равно может потребовать генерации или перевода и человеческого контроля.

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

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

Как устроить короткий пилот

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

Затем соберите 60–100 реальных обезличенных вопросов, включая вопросы по-русски с ответом только в английском документе, вопросы с точным артикулом и вопросы без ответа в базе. Для каждого вручную отметьте верный фрагмент и допустимую редакцию документа. Прогоните одинаковый набор через три схемы. Измерьте долю верных источников в первых пяти результатах, фактическую задержку, долю ответов с корректной ссылкой, число ручных исправлений и отказов. Проверяйте отдельно кросс-языковой поиск: высокий общий балл может скрывать провал именно на русско-английских парах.

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

Ограничения и решение

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

Редакторский вывод: для малого бизнеса разумный первый шаг — неделя сравнения трёх маршрутов на ограниченном наборе, а не массовый перевод архива. Утвердите пороги качества и времени ответа заранее. После пилота выбирайте самый дешёвый маршрут, который даёт проверяемый источник и укладывается в рабочий SLA, оставляя сотруднику право остановить неверный ответ. Роботу-стажёру можно поручить поиск; стопку переводов до потолка лучше не считать KPI.