SANRI — настольное приложение, которое мы сейчас разрабатываем вместе с Александром Калиновским. Его цель — упростить получение товаров у поставщиков, привести товарные данные и карточки к лучшему виду и распределить их по торговым площадкам. Для совместной работы в программу встроена CRM.
Программа написана на C# и развивается как настольное приложение для Windows. Ниже — два экрана текущей версии: работа с номенклатурой и настройки агента Codex.
Один процесс вместо разрозненных операций
Поставщики передают данные в разном виде. До появления товара на площадке нужно привести названия и свойства к понятной структуре, подобрать категорию, подготовить карточку и учесть требования канала продаж. При большом ассортименте повторять эту работу вручную для каждой позиции становится сложно.
Мы развиваем SANRI вокруг всей этой цепочки: получение данных → подготовка и улучшение → распределение по площадкам. Встроенная CRM добавляет командную часть: система должна быть рабочим пространством для людей, которые ведут этот процесс вместе.
Каталог как основа системы
В SANRI разделены товар и его торговые предложения — SKU. Общая карточка хранит название, бренд, категорию и тип. Предложения связывают её с данными поставщиков и каналами продаж. В текущем интерфейсе доступны дерево категорий, поиск, фильтры, настройка столбцов и статусы классификации.
Это важное различие: загрузить внешний каталог недостаточно для публикации. Сначала данные нужно связать с внутренней номенклатурой, классифицировать и проверить. Встроенная справка описывает отдельные этапы сопоставления свойств, предпросмотра и заполнения характеристик.
Характеристики — отдельная сложная задача
Выбор категории определяет, куда попадёт товар. Но для полноценной карточки нужно ещё разобраться в его свойствах. Поставщики называют одну характеристику по-разному, используют разные единицы и форматы значений. Торговые площадки добавляют собственные справочники и обязательные поля. Простое копирование здесь не решает задачу.
В SANRI предусмотрены общий справочник характеристик и свойства на уровне товара или конкретного SKU. Связь свойства с конечной категорией определяет, где оно применимо. Сопоставления с характеристиками поставщиков настраиваются в источниках данных, а заполнение выполняется отдельной командой после предпросмотра предложенных значений.
Для нас улучшение карточки означает работу со всей этой структурой: название, категория, тип, подтверждённые характеристики и данные для публикации. Если значение отсутствует или противоречит источнику, его нужно уточнить. Правдоподобное предположение ИИ не должно превращаться в выдуманное свойство товара.
Codex решает прикладную задачу
В разделе агентов есть подбор категории и типа товара через Codex, а также отдельный сценарий через ChatGPT. Для Codex предусмотрены выбор модели и уровня рассуждения, ограничение количества товаров за запуск, планировщик и журнал.
Сценарий работает с названием товара. Сначала рассматриваются типы по уже классифицированным товарам поставщика; если подходящих вариантов нет, используется полный справочник. Так ИИ получает контекст существующего каталога, а результат должен соответствовать его структуре.
Предусмотрены разные режимы: сохранить аналитику или автоматически присвоить тип. В аналитическом режиме каталог не меняется. Автоприменение требует права изменения данных. Это позволяет отделить исследование ответа модели от его влияния на рабочую базу.
Ответ модели можно разобрать
Экран «Работа моделей» содержит предложение по номенклатуре, вкладки ответа, входных данных и диагностики. Для оценки предусмотрены варианты «Правильно», «Неправильно» и «Нужна проверка». Такой интерфейс нужен, чтобы сравнивать результат с предметной областью, а не судить о качестве по убедительности текста.
Сейчас это описание устройства текущей версии. Оно не является отчётом об измеренной точности классификации: для такого вывода нужна отдельная проверка на наборе товаров.
Контроль перед изменением и публикацией
По встроенной справке, правки ячеек сначала становятся черновиками. Их можно применить или отменить; одновременное изменение записи другим пользователем должно приводить к сообщению о конфликте. Для публикации предусмотрены проверки категории, типа, размеров упаковки, массы и фотографий.
Отдельно описан повторный запуск: сверка по постоянным ключам и продолжение незавершённых шагов. Для ряда полей предусмотрено сохранение ручных изменений на сайте. Это как раз те детали, которые превращают интеграцию в инструмент повседневной работы.
Почему этот проект для меня важен
SANRI объединяет несколько направлений моей практики: каталоги, интеграции, прикладной ИИ и командную работу. Вместе с Александром Калиновским мы развиваем систему, которая помогает пройти путь от данных поставщика до подготовленного предложения на площадке. Пользователь должен видеть исходные сведения, изменения и результат обработки.