Векторный поиск в 1С без облаков: локальный AI-сервис для прайсов поставщиков

Как найти нужный товар за 0.1 секунды среди миллионов позиций поставщиков, когда у всех разные названия, артикулы и сокращения? Кейс интеграции локального AI (Hybrid Search) в 1С для мгновенного поиска по “сырым” прайс-листам.

Классическая ситуация в отделе продаж: звонит клиент и спрашивает условный “Перфоратор Бош на аккумуляторе, желтый”.

Менеджер открывает 1С, смотрит остатки — нет в наличии. Что происходит дальше в 90% компаний?

1. Менеджер говорит: “Нет в наличии”. Компания теряет деньги.

2. Менеджер начинает судорожно открывать 10-20 прайс-листов поставщиков в Excel, нажимать Ctrl+F и перебирать варианты: “Bosch”, “Бош”, “Перф. аккум”, “GBH”… Это долго, неудобно, и клиент часто уходит, не дождавшись.

Для решения этой проблемы был выбран принципиально иной подход. Вместо попыток “нормализовать” и загружать в справочник Номенклатуры весь массив данных из прайсов (забивая базу), разработан умный поисковый движок, который работает поверх этих файлов.

В этой статье рассматривается архитектура AI - Price Search — локального микросервиса для 1С, который позволяет искать товары по смыслу, а не только по точному совпадению букв.

Главная идея: Продавай то, чего у тебя нет

Основное предназначение системы — дать менеджеру возможность видеть складские остатки всех поставщиков так же легко, как собственные.

Принцип работы для пользователя:

1. В систему (через веб-интерфейс или 1С) загружаются “сырые” прайсы поставщиков (Excel/CSV). Объем данных практически не ограничен.

2. Нейросеть “читает” их и превращает названия в векторы смыслов.

3. Менеджер в 1С вводит запрос так, как слышит от клиента (даже на сленге): “акум для шурика бош”.

4. Система за доли секунды выдает список: у кого из поставщиков есть этот товар, как он там называется и сколько стоит.

Ключевая особенность — системе всё равно, как товар назван у поставщика. В приводимом примере в запросе нет ни одного слова, которое бы совпадало с результатом по буквам!

• Запрос: “акум для шурика бош”

• Найдено (Топ-1): “Аккумулятор для шуруповерта BOSCH 2.0Ah 14.4V Ni-Cd”

• Найдено (Топ-2): “Аккумулятор для шуруповерта BOSCH 1.5Ah 12V Ni-Cd”

Программа успешно распознает профессиональный сленг:

• “акум” ≈ “Аккумулятор”

• “шурик” ≈“шуруповерт”

• “бош” (кириллица) ≈ “BOSCH” (латиница)

Менеджер мгновенно видит лучшую цену, делает наценку и продает товар, даже не создавая его карточку в базе до момента сделки.

Ликбез для 1С-ника: Векторный поиск, метаданные и «склейка» полей

Многие 1С-специалисты воспринимают нейросети как некий «чёрный ящик», где результат получается непредсказуемо. На практике в прикладных задачах всё гораздо прозаичнее: нейросеть — это всего лишь способ по-другому представить строку, чтобы потом строго математически сравнивать её с другими строками.

В нашем решении используются три базовых концепции, которые легко ложатся на привычное мышление 1С-разработчика.

1. Гибридный вектор: смысл + точность

Для 1С строка — это последовательность символов. Запрос вида: ПОДОБНО "%Герметик%" ищет совпадение букв, но ничего не знает о смысле.

Векторный поиск работает иначе: строка преобразуется в набор чисел, которые описывают её смысловое положение в многомерном пространстве. Чтобы одновременно решать две задачи — понимать смысл запроса и не терять точные артикулы, мы используем гибридный подход (Hybrid Search), где работают две модели параллельно. С точки зрения архитектуры 1С это можно воспринимать как дополнительный поисковый индекс, который работает не по символам, а по смыслу строки.

Модель смысла (Dense Vector)

Компактная нейросеть преобразует наименование товара в вектор из 384 чисел. Это практичный компромисс между качеством и скоростью: такой размер позволяет работать на обычном сервере без GPU и при этом уверенно различать смысловые категории товаров.

С точки зрения 1С-ника это можно сравнить с ситуацией, когда разные строки фактически относятся к одному логическому виду номенклатуры, даже если совпадений по символам нет. Например, модель понимает, что:

• «Смартфон Apple»

• «Apple iPhone»

• «Айфон 15»

...относятся к одному и тому же типу товара, несмотря на различие языка и формулировок.

Модель точности (Sparse Vector)

Вторая модель работает как страховка. Она выделяет редкие и значимые токены — артикулы, коды, уникальные обозначения брендов.

По сути, это «умный аналог полнотекстового индекса»: если в запросе есть конкретный код (GBH-2-26, 08346, 2900001871), система гарантированно поднимет именно его, а не просто «похожий по смыслу» товар.

Как происходит поиск (без магии)

Ключевая идея — математическая близость векторов. Упрощённо представим, как система «видит» товары:

Товар A: «Герметик санитарный» → [0.10, 0.90, ...]

Товар B: «Силикон для ванной» → [0.12, 0.88, ...]

Товар C: «Клей ПВА» → [0.80, 0.10, ...]

Теперь представим, что пользователь вводит поисковый запрос: «герметик». Этот запрос также преобразуется в вектор, например: [0.11, 0.89, ...]`.

Первые два товара находятся рядом в одном смысловом кластере («материалы для герметизации»). Третий — в совершенно другой области.

При поиске:

1. Запрос пользователя преобразуется в векторы теми же моделями.

2. База данных считает расстояние между векторами.

3. Результаты сортируются с учётом:

• смысловой близости;

• точных совпадений по ключевым токенам.

Итог: «Силикон для ванной» окажется выше «Клея ПВА», даже если слово «герметик» в названии отсутствует.

2. Векторные базы данных: где это хранится

Обычные SQL-СУБД не предназначены для быстрого расчёта расстояний между тысячами или миллионами векторов. Поэтому используются два подхода:

• Специализированные векторные БД (Qdrant, Chroma, Weaviate) — отдельные движки, оптимизированные под такие операции. В текущей реализации используется этот вариант.

• Расширения для классических БД (например, pgvector для PostgreSQL), когда векторы хранятся рядом с обычными данными.
   

3. Payload и «склейка» полей: куда делись цены и остатки

Частый вопрос:

«Если всё превратили в цифры, как система знает цену и остаток?»

Ответ простой — векторы и данные хранятся отдельно. Каждая запись состоит из:

• Вектора — для поиска.

• Payload (метаданных) — исходных колонок прайса в виде JSON (цена, остаток, срок поставки, комментарии и т.д.).

При загрузке прайса:

1. Формируется поисковый образ — склеенная строка: Наименование + Артикул + Бренд + Штрихкод.

2. Именно она преобразуется в векторы.

3. Все колонки сохраняются в Payload без изменений.

Когда поиск находит нужный вектор, система сразу возвращает весь Payload — без дополнительных SQL-запросов и повторного поиска.

Итог для 1С-специалиста

Если упростить до привычных терминов 1С:

• Вектор — это нормализованное представление строки для поиска по смыслу.

• Hybrid Search — сочетание семантического поиска и строгого отбора по артикулам и кодам.

• Payload — обычные данные прайса, которые не участвуют в поиске, но всегда возвращаются в результатах.

Где этот подход не нужен

Важно понимать, что векторный поиск — не замена всем сценариям.

Этот подход избыточен, если:

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

В таких случаях классический полнотекстовый поиск будет проще и дешевле.

Данный инструмент ориентирован именно на работу с «сырыми», разнородными прайсами поставщиков, где традиционные методы перестают быть эффективными.

Умный алгоритм ранжирования (Ranking)

Чтобы обеспечить предсказуемость работы системы в бизнес-задачах, была выстроена жесткая иерархия ранжирования (версия 2.6). Это предотвращает “галлюцинации” ИИ.

При поиске система проверяет кандидатов по 4 уровням приоритета:

• Уровень 1: Точная фраза (Phrase Match). Если введен запрос “Айфон 15 черный”, и в прайсе есть строка, содержащая эти слова именно в таком порядке — этот товар получает безусловный приоритет.

• Уровень 2: Все слова (Word Coverage). Если слова в прайсе перепутаны местами (“15 черный айфон”), но присутствуют все — позиция занимает второе место в выдаче.

• Уровень 3: Точный код/Артикул. Если введен набор цифр/букв (например, 2900001871), и он найден в артикуле — товар поднимается в топ.

• Уровень 4: Семантика (Магия AI). Если точных совпадений нет, задействуется нейросеть для поиска товаров, близких по векторному представлению. Например, по запросу “телефон яблоко” будет найден “Smartphone Apple”.

Технический стек

• Backend: Python + FastAPI (обработка запросов).

• AI Engine: PyTorch + модели E5 (для смысла) и SPLADE (для точности).

• База данных: Qdrant (векторная БД, обеспечивающая поиск по миллионам товаров за 0.05 сек).

• Frontend: Внешняя обработка 1С (через HTML-поле) или Web-интерфейс.
   

Примеры из жизни (Кейсы)

Система прошла тестирование на базе из 100 000+ товаров (строительные материалы, электроника, запчасти).

Кейс 1: “Менеджер не знает, как это пишется”

Запрос: колодки опель В прайсах поставщиков часто встречается разнородное написание: Opel, GM, множество лишних цифр и кодов. Результат: Алгоритм отсеивает “мусорные” коды, определяет контекст (автозапчасти) и выдает релевантный список тормозных колодок именно для Opel, игнорируя похожие слова в описании масел или фильтров.

Кейс 2: Семантический поиск и перевод (Zero-shot match)

Запрос менеджера: телефон айфон 15 желтый 256. В прайсе поставщика эта позиция заведена на английском, а слова “телефон” вообще нет: Smartphone Apple iPhone 15 256Gb Yellow.

Результат: Для обычного символьного поиска это разные товары (нет совпадений русских слов). Для нейросети это 100% смысловое попадание:

• телефон ≈Smartphone

• айфон ≈ Apple iPhone

• желтый ≈ Yellow

Менеджер находит товар мгновенно, хотя в запросе все слова отличаются от названия в базе.

Кейс 3: “Шпаклевка” или “Шпатлевка”? (Вариативность написания)

Запрос: шпаклевка (через “к”). В прайсах поставщиков этот товар может быть записан как угодно: Шпатлевка, Шпаклёвка, или даже с опечатками. Для обычного строгого поиска это разные слова.

Результат: AI-модель понимает семантическую суть продукта. По запросу с буквой “к” она уверенно находит позиции, написанные через “т” (Шпатлевка универсальная), так как векторное представление (смысл) у этих слов практически идентично. Пользователю не нужно угадывать, как именно кладовщик поставщика завел карточку товара.

Кейс 4: Гибридный запрос (Точный код + Подбор аналогов)

Часто возникает задача не просто найти конкретную деталь по артикулу, но и подобрать к ней сопутствующие товары или аналоги (cross-sell).

Запрос: 08346 амортизатор ваз 2180 Здесь 08346 — это точный артикул из прайса, а остальной текст задает контекст поиска.

Результат: Система работает комплексно.

1. На первом месте выдается точное совпадение по артикулу (благодаря алгоритму Sparse/Keyword).

2. Следом идут семантически близкие позиции (благодаря Dense-вектору): передние левый и правый амортизаторы на ту же модель автомобиля.

Менеджер получает возможность предложить клиенту не только одну запчасть, но и полный комплект (“в круг”).

Пример выдачи:

1. [ТОЧНО] Амортизатор ВАЗ 2180… задний… 08346 — 3 850 ? (Искомая деталь)

2. [93%] Амортизатор ВАЗ 2180… передний… левый… — 5 560 ? (Допродажа)

3. [93%] Амортизатор ВАЗ 2180… передний… правый… — 5 560 ? (Допродажа)

Производительность: Нужна ли видеокарта?

Проект находится в стадии R&D, поэтому производительность отдельных этапов напрямую зависит от доступных вычислительных ресурсов.

Поиск:
После построения индекса поиск работает быстро (~0.1 сек) даже на обычном CPU. Для работы менеджеров видеокарта не требуется.

Загрузка прайсов (векторизация и индексация):
На этапе загрузки и переиндексации больших прайс-листов видеокарта даёт существенное преимущество.
Например, индексация прайса объёмом ~9 000 строк с длинными наименованиями:

• на GPU занимает порядка 1–2 минут;
• на CPU может занимать 10–15 минут.

Скорость напрямую зависит от длины и сложности наименований. Простые прайсы с короткими названиями обрабатываются заметно быстрее.

Вывод:
Для повседневной работы и поиска GPU не требуется.
Однако при регулярной загрузке и переиндексации крупных прайс-листов наличие видеокарты становится существенным преимуществом.

Возможным направлением дальнейшего развития является вынесение этапа векторизации в отдельный сервис с возможностью выбора между локальной и удалённой (облачной) обработкой.
 

Зачем это нужно бизнесу?

1. Скорость ответа клиенту. Возможность ответить на запрос моментально, удерживая клиента.

2. Расширение ассортимента. Продажа товаров со складов поставщиков происходит так же уверенно, как со собственного склада.

3. Снижение порога входа. Новым сотрудникам не требуется учить наизусть специфические названия в базе, поиск возможен “своими словами”.
    

Интеграция с 1С: Готовое API и внешняя обработка

Несмотря на статус R&D, архитектура системы изначально строилась как API-first. Это значит, что любые функции (поиск, загрузка, управление) доступны для внешних систем, и система готова к бесшовной интеграции.

Уже сейчас разработана внешняя обработка для 1С. Она подключается к локальному сервису по REST API и выводит результаты поиска прямо в нативный интерфейс 1С Предприятие.
 

Как это выглядит сейчас:

1. Менеджер открывает обработку в 1С.

2. Вводит поисковый запрос.

3. Получает таблицу с ценами и остатками поставщиков, не переключаясь в браузер или Excel.

На текущий момент в обработке реализован интерфейс Поиска. Загрузка прайсов осуществляется через веб-интерфейс, однако API для переноса функционала загрузки внутрь 1С уже полностью готов.

Заключение и вопросы к профессиональному сообществу

На данный момент проект находится в стадии активного R&D и представляет собой рабочий прототип, в рамках которого исследуется архитектурный подход к использованию локальных нейросетей, векторных баз данных и гибридного поиска. Задача работы с прайсами поставщиков используется как наглядный прикладной сценарий для проверки и оценки этого подхода.

В текущем виде реализованы:

• загрузка прайсов в форматах Excel/CSV;
• построение гибридного индекса (векторный + полнотекстовый поиск);
• поиск с учетом морфологии, синонимов и смысловой близости;
• интеграция с 1С через HTTP-сервисы.

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

Чтобы превратить текущий прототип в полноценное тиражное решение (production-ready), потребуются дополнительные ресурсы и время, поэтому дальнейшее развитие напрямую зависит от практической востребованности подхода.

В связи с этим особенно важна обратная связь от профессионального сообщества:

1. Насколько в вашей практике актуальна задача поиска по «сырым», разнородным прайсам поставщиков?
2. Насколько критична скорость загрузки и переиндексации прайсов при работе с большими объёмами данных?
3. Есть ли в вашей инфраструктуре GPU, или предпочтительнее вариант с вынесением ресурсоёмких этапов (векторизации) в облачный сервис?
4. Видите ли вы практический смысл доводить такой прототип до состояния «коробочного» решения?

Буду признателен за любые мнения, опыт и конструктивную критику в комментариях.