Ссылка на источник не убирает выдумки. Она избавляет от необходимости верить на слово
Пятница, пятый час. Менеджер держит трубку у плеча и одной рукой листает 1С. Клиент спрашивает простую вещь: деталь не подошла, что есть взамен и когда будет. Аналог у вас есть — он записан в комментарии к карточке номенклатуры так, как его понял закупщик, который эту карточку заводил три года назад. Ещё пара аналогов лежит в голове у Наташи, но Наташа в отпуске. Менеджер говорит «я уточню и перезвоню», и все понимают, чем это обычно заканчивается.
Технология под названием RAG придумана ровно про этот момент. Ниже — как она устроена, где спотыкается и кому не нужна.
Почему обычная нейросеть здесь бессильна
Соблазн понятный: взять привычный чат и спросить у него. Но модель знает только то, на чём её обучали, — общие сведения из интернета. О вашей номенклатуре, ваших ценах и ваших остатках она не знает ничего.
Хуже того: не зная ответа, она нередко его придумывает — уверенно и правдоподобно. В болтовне это безобидно, в ответе клиенту стоит денег.
Что такое RAG без метафор
Расшифровывается как «генерация с опорой на поиск», и идея простая: прежде чем отвечать, система сначала находит в ваших данных подходящие куски, а потом просит модель сформулировать ответ по ним.
Порядок такой. Документы и описания режутся на фрагменты. Приходит вопрос — система ищет фрагменты, относящиеся к нему. Найденное отдаётся модели вместе с инструкцией отвечать только по этому. Модель формулирует ответ и показывает, из какого документа он собран.
Первая ловушка: поиск по смыслу и артикулы
Обычно на этом месте пишут, что система ищет «по смыслу, а не по совпадению слов», и ставят точку. У этого есть обратная сторона, и в торговле она стоит дорого.
На запросе «чем заменить прокладку ГБЦ» смысловой поиск работает прекрасно. На артикуле 2108-3512010 он работает плохо: для модели это просто последовательность цифр, и она с удовольствием подсунет похожий, но чужой код. А в торговле запчастями половина вопросов — именно про коды.
Поэтому поиск делают двойным: точный — по артикулам, кодам и названиям, смысловой — по описаниям и регламентам, а результаты сводят вместе. Это не усложнение ради красоты: ассистент, построенный на одном только смысловом поиске, будет уверенно ошибаться там, где ошибка заметнее всего.
Вторая ловушка: что нельзя класть в индекс
Данные в 1С бывают двух сортов, и обращаться с ними надо по-разному.
Текст — регламенты, описания номенклатуры, характеристики, история переписки — живёт долго и меняется редко. Его можно нарезать и сложить в поисковый индекс — заранее собранную картотеку, по которой ассистент ищет, чтобы не перечитывать всю базу на каждый вопрос.
Числа — остатки, цены, статусы заказов — меняются каждый час. Их в индекс класть нельзя: через час такой ответ станет ложью, причём ложью с красивой ссылкой на источник. Их спрашивают у 1С в момент вопроса, напрямую.
Правило простое: в индекс уходит то, что описывает товар. За тем, сколько его на складе и почём, ассистент каждый раз ходит в 1С.
Для тех, кто будет это эксплуатировать. Достать данные из 1С можно тремя путями: штатный интерфейс OData при опубликованной конфигурации — быстрее всего на старте; собственный HTTP-сервис в конфигурации — когда нужна своя логика на стороне 1С; выгрузка в промежуточную базу — когда боевую 1С трогать нельзя. Первый путь дешевле, третий спокойнее.
Индекс на небольших объёмах спокойно живёт как расширение того же PostgreSQL, отдельный сервис под него заводить не обязательно. Актуализация — по подписке на изменения или по отбору свежих записей: полная переиндексация каждую ночь работает, пока объём маленький, и перестаёт, когда он вырастет.
Права доступа решаются на уровне поиска, а не на уровне ответа. На каждом фрагменте лежит метка, кому он виден, и запрос уходит уже с правами спрашивающего. Фильтровать после поиска — значит молча опустошать выдачу: десять найденных мест окажутся чужими, и ассистент скажет «не нашёл» там, где данные есть. Фильтровать после генерации ещё хуже: закрытый фрагмент уже побывал в контексте модели и может протечь в формулировку. И отдельной строкой в смете: при смене прав фрагменты переиндексируют, иначе метки отстают от 1С.
Третья ловушка: инструкция не железная
Модели говорят: отвечай только по найденным фрагментам. Эта инструкция не приказ, а сильная просьба. Если нужный фрагмент не нашёлся, модель всё равно попробует ответить — так она устроена.
Лечится это двумя вещами. Первая: модели явно разрешают сказать «в данных этого нет» — без такого разрешения она будет выкручиваться. Вторая: список вопросов, на которых её проверяют перед запуском, и среди них обязательно должны быть вопросы, ответа на которые в данных нет. Именно на них видно, врёт система или честно разводит руками.
И про ссылку на источник — ту самую, ради которой всё затевается. Она не убирает выдумки: модель способна процитировать верный документ и всё равно перепутать в нём цифру. Меняется другое, и это важнее: вам больше не нужно верить ответу на слово. Под ним видно, откуда он собран, и это открывается за секунды.
Что это даёт в рабочий день
Менеджер спрашивает про аналоги и наличие и получает ответ, пока клиент на линии, а не после «я уточню».
Новый сотрудник спрашивает «как оформить возврат» у ассистента, а не у соседа, который третий раз за день объясняет одно и то же своими словами — каждый раз чуть иначе.
И Наташа уходит в отпуск, а вопрос про аналоги не ждёт её возвращения — в той части, которую кто-то однажды записал. То, что осталось у неё в голове, ассистент не найдёт: индексировать голову нечем. Зато он делает запись выгодной — записанное один раз отвечает дальше само. Посчитайте, сколько раз за прошлый месяц вопрос ждал одного конкретного человека: это и есть та часть работы, которая держится на нём, а не на вас.
Где граница
Ассистент силён там, где ответ уже существует в ваших документах и его надо найти. Он слаб там, где ответ надо вычислить или где нужно решение, а не справка.
И качество ответов упирается в качество данных жёстче, чем принято говорить. Если аналоги записаны в свободном комментарии разными людьми в разной манере — ассистент будет находить их примерно так же, как находит менеджер, то есть через раз. Разбор такого текста возможен, но это отдельная работа, и её стоит закладывать в проект, а не обнаруживать в середине.
Что мы здесь делали
Чтобы вы понимали границу. С 1С мы работаем давно и с разных сторон: связывали её со складом и маркетплейсами в B2B-платформе автозапчастей, строили поверх её данных систему заказа EorderPRO, делали складской учёт и терминалы сбора данных в типографии СтатусPRO — от приёмки до отгрузки. Эта часть — доставание данных, сопоставление, обмен — у нас отработана.
Обменов с 1С у нас несколько, и устроены они по-разному: самый старый, складской, работает в обе стороны, а это отдельный класс задач, потому что при расхождении кто-то должен решать, чья версия главная.
Вторая половина — ассистент, отвечающий по документам. Его мы держим у себя и пользуемся каждый день: он отвечает по внутренним регламентам и разбирает записи совещаний, работает на своём железе. Из этих двух половин — доставание данных и ответы по ним — ассистент поверх 1С и собирается.
Когда вам это не нужно
Если ассортимент до пятисот-тысячи позиций и один закупщик держит его в голове — живой человек тут быстрее ассистента и намного дешевле.
Если регламенты не написаны, а живут в устной традиции — сначала их надо написать, и никакой ИИ этот шаг не отменит. Ассистенту нечего индексировать.
Если вопросы приходят раз в день — окупаться нечему.
С чего начать
Соберите за неделю список реальных вопросов, которые сотрудники задают друг другу, — просто записывайте. Тридцать штук достаточно. Посмотрите, на сколько из них ответ уже лежит в ваших документах, а на сколько его нет нигде.
Это бесплатно, занимает неделю и отвечает на главный вопрос до всяких внедрений: есть ли у вас что индексировать. Если ответов нет в документах — проблема не в ИИ.
Пришлите тридцать вопросов
Те, что сотрудники задают друг другу каждую неделю. Скажем, на сколько из них ответ уже есть в ваших данных, а на сколько его придётся сначала написать.