Свободный текст заявки лучше сопоставлять с номенклатурой 1С каскадом. Сначала код разбирает Excel или текст и выделяет название, количество и единицу. Затем проверяет известные соответствия клиента, ищет точные маркировки, делает нечёткий и смысловой поиск. Языковая модель получает только короткий список кандидатов и может выбрать один из них или отказаться. Размеры, модели и единицы проверяет код. Уверенные совпадения можно принять автоматически, спорные строки остаются менеджеру. Подтверждённые пары сохраняются в словарь только после проверки администратора. Для каждого решения нужен источник и понятный статус проверки.
Почему одного поиска по словам мало
Обычный поиск по подстроке пропускает синонимы. Векторный поиск понимает смысл, но может недооценить точную модель. LLM без списка кандидатов способна придумать позицию, которой нет в базе. Поэтому надежнее собрать несколько простых методов в последовательность и дать каждому свою роль.
В нашем проекте локальная копия справочника содержит больше 30 000 позиций. Система работает с выгрузкой 1С и не делает произвольных запросов в инфобазу во время каждого матчинга.
Шаг 1. Разобрать входной файл
До ИИ нужно правильно понять структуру заявки. Файл может содержать преамбулу, объединённые ячейки и разные названия колонок.
Парсер ищет шапку в первых строках и распознаёт варианты наименование, номенклатура, количество, ед. изм.. Строка становится шапкой только при наличии названия и ещё одной смысловой колонки. Если заголовки не найдены, код выбирает столбец по текстовому содержимому и отдельно защищается от числовых колонок.
Текстовый ввод тоже разбирается по правилам:
Вентилятор канальный SM 300 — 2 шт
Воздуховод D160, L=3000 — 9 м
Фильтр кассетный 500×300 4 штКоличество ищется в конце строки или в соседней ячейке. Числа внутри маркировки и размеров остаются частью названия.
Результат этого этапа имеет простую структуру:
{
"original_name": "Вентилятор канальный SM 300",
"quantity": 2,
"unit": "шт"
}Шаг 2. Проверить известные соответствия
У одного заказчика товар может годами называться одинаково. Нет смысла каждый раз вызывать модель.
Система сначала проверяет:
- жёсткий словарь конкретного клиента;
- ранее утверждённый кэш;
- общий словарь, если он разрешён для этого контекста.
Известная пара возвращается сразу. Словари перечитываются после изменения файла, поэтому новая запись начинает работать без старого кэша в процессе.
Главное ограничение: нельзя обучать такой словарь на каждом клике. Ошибка одного менеджера иначе станет автоматической ошибкой для следующих заявок.
Шаг 3. Собрать кандидатов несколькими способами
Если готового правила нет, система запускает три поиска.
Нечёткое совпадение
RapidFuzz сравнивает нормализованные строки и отбирает близкие названия. Перед этим раскрываются несколько рабочих сокращений, а кандидаты фильтруются по категории товара.
Этот слой быстрый, но одинаковые слова ещё не доказывают, что размер и модель совпадают.
Точная маркировка
Отдельный регулярный разбор извлекает токены вроде SM 300. Поиск учитывает границы токена, чтобы короткая модель не совпала с частью другого артикула.
Такой слой появился после реальной ошибки: смысловой поиск мог поставить выше товар с похожим описанием и потерять точную модель из заявки.
Смысловой поиск
Названия из справочника заранее преобразуются в embeddings и хранятся в ChromaDB. Для новой строки система получает ближайшие по смыслу позиции. В текущей реализации embeddings строятся через Gemini, а индекс хранится локально.
Если фильтр категории не дал результатов, поиск повторяется без него. Ошибка классификации категории не должна обнулить весь подбор.
Шаг 4. Дать LLM ограниченную задачу
Модель не ищет товар во всей базе и не сочиняет название. Она получает исходную строку и отобранных кандидатов:
Клиент запросил: «Вентилятор канальный SM 300»
Кандидаты из справочника 1С:
1. Вентилятор SM 300, 230 В
2. Вентилятор SMI 300 EC
3. Вентилятор SM 250, 230 В
Выбери один вариант или верни null.Ответ ожидается в JSON. Если модель возвращает лишнее пояснение, код выделяет JSON-объект. При timeout, ошибке API или отказе выбрать кандидата позиция не становится автоматически подтверждённой.
Такая постановка проще для контроля. Модель сравнивает варианты, которые действительно существуют в справочнике.
Шаг 5. Проверить числа и маркировки кодом
После LLM остаётся обычная валидация. Она нужна даже при высокой уверенности модели.
В рабочем матчинге автоматический зелёный статус требует высокого порога и совпадения значимых чисел. Если у кандидата есть размер, которого не было в запросе, автоподтверждение блокируется. Если модельные токены исходной строки и выбранной позиции различаются, результат понижается до жёлтого.
Количество тоже может потребовать преобразования. Например, клиент указывает метры, а в 1С товар учитывается штуками фиксированной длины. Такие правила должны быть написаны в коде и проверены для конкретной категории. LLM не должна сама решать, сколько упаковок получится из 200 штук.
Шаг 6. Показать человеку спорные строки
В интерфейсе используются три статуса:
- зелёный: правило или проверки дают достаточно оснований для автоматического выбора;
- жёлтый: кандидат есть, но его нужно подтвердить;
- красный: подходящей позиции нет либо менеджер её отклонил.
Для жёлтой строки менеджер выбирает предложенный вариант или ищет другой товар в выпадающем списке. Красная строка не должна молча превращаться в ближайший результат.
После подтверждения система формирует Excel с исходной фразой, выбранной номенклатурой, количеством, единицей и статусом. Отдельный аудит сравнивает исходное предложение ИИ с финальным решением менеджера.
Как система учится и не закрепляет ошибку
Подтверждение заявки и обучение словаря разделены.
Менеджер может закончить конкретный заказ. Новая пара после этого попадает в очередь администратора. Администратор видит исходную строку и выбранный товар, затем принимает, заменяет или отклоняет соответствие.
Только одобренная пара начинает давать мгновенный зелёный результат в следующих заявках. Для отдельных клиентов правила хранятся отдельно. Это полезно, когда одинаковое слово у двух заказчиков означает разные внутренние позиции.
Четыре ошибки, которые стоит проверить до запуска
Количество стало названием товара
Excel пришёл без ожидаемой шапки, и парсер выбрал числовую колонку. Мы добавили профилирование столбцов и повторный выбор, если большая часть значений является числами.
Модель потерялась в семантике
Слова категории оказались сильнее артикула. После этого маркировки стали искать отдельно и добавлять найденные позиции в список до LLM.
Похожий размер получил высокую оценку сходства
Текст почти одинаковый, но отличается диаметр или индекс модели. После поиска код отдельно сверяет числа и маркировки.
Отклонённая подсказка стала новым правилом
Менеджер убрал кандидата, а запасная логика вернула его в итог. Теперь у красной строки нет автоматического значения, а обучение проходит через очередь администратора.
API рабочего процесса
В найденной системе загрузка и обработка разделены. Это не даёт тяжёлой задаче стартовать до проверки входа:
POST /api/crm/chat/upload
→ preview_id и число строк
POST /api/crm/chat/start/{preview_id}
→ task_id
GET /api/crm/chat/task/{task_id}
→ прогресс и session_id
GET /api/session/{session_id}
→ кандидаты и статусы
POST /api/session/{session_id}/approve
→ подтверждённая сессия
POST /api/session/{session_id}/export-excel
→ итоговый ExcelЗагрузка, запуск обработки и просмотр прогресса в CRM требуют JWT. Изменение номенклатуры и очередь новых маппингов доступны администратору. Production URL, реальные IDs и секреты в статью не выносятся.
Как оценивать качество
Одной общей «точности» недостаточно. На размеченном наборе полезно считать отдельно:
- сколько строк разобрано без потери;
- долю автоматических зелёных совпадений;
- ошибочные зелёные, это самый дорогой класс;
- сколько жёлтых менеджер принял без изменения;
- сколько кандидатов он заменил;
- сколько красных действительно отсутствовало в справочнике;
- среднее время проверки одной заявки;
- число новых правил, которые администратор отклонил.
Особенно важно измерять ложные зелёные. Пустая строка заметна и уйдёт человеку. Уверенно выбранный неправильный товар может попасть в счёт.
Где проходит граница автоматизации
Модель помогает понять человеческую формулировку и сравнить кандидатов. Код отвечает за формат, числа, единицы, права и статусы. Менеджер решает спорные строки. Администратор контролирует, чему система научится на будущее.
В текущем проекте результатом является проверенный Excel. Прямого создания документа в 1С нет, и статья не должна его обещать.
Geron Labs может проверить такой каскад на обезличенной выгрузке и наборе реальных заявок. Для пилота достаточно справочника, нескольких типовых файлов и сотрудника, который знает цену неправильного сопоставления.