Что произошло на самом деле

Девять малых и средних компаний участвовали в программе кантона Цюрих, где Swiss Data Science Center (SDSC) вместе с ними собрал открытый прототип RAG. Практический сценарий — поиск и сопоставление документов об экологических характеристиках упаковки: деклараций продукции, материалов поставщиков, корпоративных отчётов и нормативных текстов. В проекте он показан на примере PrimePack AG. Это именно совместное прототипирование, а не подтверждённое промышленное внедрение у всех девяти компаний.

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

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

Почему ответу недостаточно приложить ссылку

Ссылка на документ ещё не делает вывод верным. В карточке товара может быть заявление производителя, в отчёте — результат измерений для другой партии, а в регламенте — требование, которое не подтверждает соответствие товара. В учебном сценарии прототип должен различать подтверждённые сведения, заявления, пробелы и противоречия. В репозитории для этого показаны категории VERIFIED, CLAIMED, MISSING и MIXED в структурированном JSON-ответе.

Для бизнеса это означает отдельную цепочку проверок:

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

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

Что потребуется для повторения в небольшой компании

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

Далее нужен загрузчик PDF и таблиц, журнал обновлений, полнотекстовый и семантический поиск, генератор ответа и экран проверки. SDSC сравнивает обычный векторный поиск, поиск по ключевым словам и гибридную схему с Reciprocal Rank Fusion. Это не повод автоматически выбирать самый сложный вариант: на пилоте надо сравнить, какие документы и фрагменты реально находятся по типовым запросам, включая артикулы, сокращения и формулировки поставщиков.

Интеграция с ERP или CRM на первом этапе может быть только читающей: подтянуть SKU и статус товара, не разрешая модели менять мастер-данные или отправлять клиенту ответ без подтверждения. Для сохранения решения полезны идентификатор товара, вопрос, ссылки на версии документов, оператор и отметка времени. Лишь после проверки качества можно обсуждать автоматическое создание черновика в рабочем процессе.

Локальная модель — не то же самое, что полностью локальный контур

Репозиторий SDSC показывает запуск генерации через Ollama. Но демонстрационный шаг построения текстового индекса в README описан с OpenAI embeddings; рядом есть и варианты локальных компонентов. Поэтому переключатель генератора на Ollama сам по себе не доказывает, что документы и запросы не уходят во внешние сервисы. Для российского бизнеса с закрытыми договорами и спецификациями это принципиально.

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

Как измерить пользу и не придумать результат

Авторы прототипа заложили оценку faithfulness, релевантности ответа, точности и полноты найденного контекста, а также синтетический набор вопросов. Такие метрики помогают сравнивать конфигурации, но синтетические вопросы не заменяют реальные спорные запросы от клиентов. Независимый профиль NIST для генеративного ИИ также рекомендует тестирование, оценку и проверку систем с учётом их применения.

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

Экономику можно оценить модельно. Допустим, команда обрабатывает 100 таких запросов в месяц, ручной поиск и сверка занимают 12 минут на запрос, а проверка черновика RAG — 7 минут. Тогда потенциальная экономия составляет 500 минут, или 8 часов 20 минут в месяц, до вычета времени на загрузку документов, исправления и поддержку системы. Это не результат швейцарского проекта и не прогноз для конкретной компании. При малом потоке запросов отдельный сервер может не окупиться; при высокой цене ошибочного заявления важнее качество доказательств, а не минуты.

Следующий шаг

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

Фото картона — иллюстративное, не изображает участников швейцарского проекта. Автор: Henry Söderlund; CC BY 2.0; выполнен квадратный кроп.