Что именно проверяли

В исследовании EASI-RAG, опубликованном в 2025 году, описана экологическая аналитическая лаборатория во Франции примерно с 200 сотрудниками. Её операторы искали ответы в рабочих процедурах. Авторы и компания проверили, может ли RAG-помощник быстро находить нужные места в документах и отвечать на обычные вопросы сотрудников. Название лаборатории не раскрыто, а её документы не опубликованы по соображениям конфиденциальности. Это документированный опыт одной организации, а не обещание для всех лабораторий.

Команда состояла из двух пользователей — представителей группы из 15 человек, опытного эксперта по процедурам, руководителя подразделения и двух разработчиков из внутренней ИТ-команды. У разработчиков раньше не было опыта с RAG. Корпус был сравнительно скромным: девять файлов, из них семь Word и два Excel, суммарно 137 страниц и около 29,7 тыс. токенов. Один Word-документ занимал 95 страниц. Часть файлов содержала изображения; одни таблицы были понятными, другие — с объединёнными ячейками и смыслом, переданным цветом.

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

Почему первая версия ошибалась

Авторы начали с простой схемы: загрузка файлов, фрагменты фиксированной длины около 1000 токенов, поиск по эмбеддингам, три найденных фрагмента и генерация ответа. Эмбеддинги считались небольшой моделью all-MiniLM-L6-v2. Поиск и обработка документов укладывались в обычный компьютер с 8 ГБ памяти и без GPU; генерация шла через внешнюю модель gpt-3.5-turbo по API. Поэтому называть этот эксперимент полностью локальным было бы неверно.

Пользователи составили 42 рабочих вопроса и ещё восемь, ответа на которые в документах не было. Эксперт заранее указал верные ответы и их расположение. В первой проверке из 50 вопросов авторы насчитали 17 правильных ответов, 19 допустимых неполных ответов или признаний неопределённости и 14 ошибочных. Среднее время ответа было около двух секунд. Скорость здесь не спасала: в рабочей процедуре ошибочная инструкция важнее красивого диалога.

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

Исправления были в данных и проверке, не в «самой мощной модели»

Команда добавила подготовку таблиц: для одного Excel-файла каждую строку сделали отдельным фрагментом и повторили в нём названия столбцов. Второй короткий лист с цветом и отметками вручную превратили в текстовое описание. Документы стали делить по разделам и подразделам, а не только по счётчику токенов. К плотному поиску добавили BM25, чтобы редкие точные термины не терялись; затем расширили число извлекаемых фрагментов. В запрос к генератору добавили требование опираться только на найденные материалы.

По публикации, после этих изменений среднее время ответа осталось около двух секунд. Авторы приводят 44 правильных, семь допустимых и ноль ошибочных ответов. Здесь есть редакционная оговорка: эти категории суммарно дают 51, хотя исходный тестовый набор описан как 50 вопросов. В статье нет объяснения расхождения, поэтому точную итоговую долю правильных ответов мы не пересчитываем и число «ноль» относим только к описанной контрольной проверке. Исследование RAGTruth, опубликованное на ACL, независимо напоминает, что RAG снижает, но не устраняет риск утверждений без опоры на источник.

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

Что известно об экономике — и чего мы не знаем

От начала проекта до первого рабочего запуска прошло три недели. Авторы оценивают труд команды примерно в 70 человеко-часов, из них около 50 часов — работа двух разработчиков. В исследовании указаны небольшие прямые расходы на API-вызовы, но они относились к тогдашней модели и ценам; переносить эту сумму на другой год, поставщика или локальную модель нельзя. Время операторов, стоимость поддержки, обновление инструкций и цена потенциальной ошибки требуют отдельного учёта.

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

Как перенести подход в российский контур

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

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

Практический первый шаг: возьмите 5–10 действующих файлов и 30–50 вопросов одного процесса. Сначала проверьте обычный поиск по заголовкам и ключевым словам. Затем добавьте извлечение фрагментов и генерацию только там, где это действительно сокращает время без опасных ошибок. Показывайте ссылку на утверждённую версию процедуры и оставляйте сотруднику возможность открыть первоисточник. Научный кейс полезен именно тем, что ограничивает роль модели: она помогает найти и объяснить правило, а ответственность за правило и действие остаётся у людей.