RAG по регламентам качества
Регламенты, договорные условия поставщиков и инструкции по категориям собрали в базу с версиями. Поиск идёт по смыслу запроса, ответ возвращается со ссылкой на пункт документа, чтобы решение можно было проверить.
Кейс · Ритейл
Кейс внедрения ИИ в ритейле: разбор брака в сети
Разбор инцидента с браком в федеральной рознице стал в шесть раз быстрее: фотография и накладная распознаются автоматически, инцидент классифицируется по типу дефекта и виновной стороне, задача уходит ответственному, а SLA считается сам. До внедрения разбор шёл письмами и таблицами, срок фиксировали вручную и часто узнавали о просрочке уже от поставщика.
×6быстрее разбор одного инцидента с браком
2–4недели пилота на одной товарной категории
100%фотографий и накладных обрабатывается внутри контура
0запросов во внешние публичные сервисы
Задача: как разбирали брак до внедрения ИИ
Федеральная розничная сеть, несколько сотен точек и распределительные центры. Брак приходит с трёх сторон: от поставщика, из-за повреждений в логистике и по вине персонала на точке. Каждый случай нужно зафиксировать, отнести к виновной стороне, собрать доказательства и уложиться в срок претензии. Если срок пропущен, сумма списывается на убыток сети.
До внедрения точка отправляла фото и сканы накладных на общий почтовый ящик. Сотрудник качества открывал письмо, искал нужный пункт регламента, определял категорию дефекта, заводил задачу и писал ответственному. Один инцидент занимал десятки минут, а в пиковые дни очередь росла быстрее, чем разбиралась.
Главная потеря была не в скорости печати, а в поиске. Регламенты по категориям товара, договорные условия поставщиков и внутренние инструкции лежали в разных файлах и редакциях. Ответ на вопрос «как правильно» приходилось искать заново почти каждый раз, и решения по похожим случаям расходились между сотрудниками.
Что построили: шесть частей системы разбора брака
Каждый блок закрывает конкретный шаг процесса, который раньше делал человек вручную. Ни один из них не работает в отдельном окне — всё встроено в уже используемые системы.
01
02
OCR и классификация инцидентов
Фото дефекта, накладная и акт распознаются автоматически. Система извлекает номер поставки, артикул и количество, затем относит случай к типу дефекта и к предполагаемой виновной стороне: поставщик, логистика или точка.
03
Маршрутизация по ответственным
У каждой связки «категория дефекта — зона ответственности» есть владелец. Инцидент уходит ему с готовой карточкой: что случилось, какой пункт регламента применён, какие документы приложены, до какого числа нужно решение.
04
Контроль SLA
Срок считается от момента фиксации, а не от момента, когда до задачи дошли руки. За сутки до истечения система напоминает исполнителю, при просрочке эскалирует руководителю направления и помечает инцидент в дашборде.
05
Интеграция с ERP
Поставки, артикулы и остатки подтягиваются из ERP, результат разбора возвращается обратно: статус, сумма претензии, связь с документом поставки. Отдельного места, куда надо перебивать данные руками, не появилось.
06
Аналитический дашборд по точкам
Срез по точкам, поставщикам и категориям товара: где брак повторяется, у кого растут просрочки, какая доля инцидентов закрывается в срок. Данные обновляются ежедневно и используются на разборах с поставщиками.
Стек и где всё развёрнуто
Система стоит на серверах сети. Внешние API отключены сетевыми политиками: фотографии товара, накладные и договорные условия поставщиков не покидают периметр — это и коммерческая тайна, и предмет переговоров с контрагентами.
| Слой | Чем закрыт | Где работает |
|---|---|---|
| Текст и рассуждение | Открытые модели семейств Qwen и DeepSeek | GPU-сервер в ЦОД сети |
| Документы и фото | OCR-конвейер с постобработкой моделью | Тот же контур |
| Поиск по регламентам | Векторный индекс на multilingual-e5 и BGE-M3 | Внутреннее хранилище |
| Оркестрация | Координатор сценариев с журналом каждого действия | Контур сети |
| Учётные данные | ERP: поставки, артикулы, остатки, документы | Существующая инсталляция |
| Аналитика | Витрина данных и дашборд качества | Контур сети |
Результат ×6: что именно считали и за какой период
Целевая метрика была одна — среднее время от поступления инцидента до принятого решения с зафиксированной ответственной стороной. Замер «до» сняли по выгрузке из почтового ящика и таск-трекера за месяц, предшествующий пилоту, и согласовали с заказчиком письменно, до начала работ.
Замер «после» брали из тех же систем через месяц работы в продуктиве, чтобы эффект новизны успел сойти. В сравнение попали все инциденты, включая те, что система передала человеку: считать только удобные случаи означало бы получить красивую, но бесполезную цифру. Итог — ускорение в шесть раз на среднем инциденте.
Параллельно смотрели на качество: долю инцидентов, по которым решение переигрывали после эскалации. Пока эта доля не стабилизировалась, скорость мы не считали результатом — быстрый, но неверный разбор обходится дороже медленного. Похожий контур мы собираем и для задач документооборота: меняется набор документов, но не логика.
Ограничения и что не вошло в объём проекта
Часть работы сознательно осталась за людьми. Ниже — границы, которые мы зафиксировали на старте и не пытались размыть по ходу.
- Спорные претензии ведёт человек. Система готовит позицию и подбирает пункты договора, но переписку с поставщиком и торг по сумме оставили сотруднику.
- Плохие фотографии уходят на ручную проверку. Смазанный или тёмный кадр помечается как ненадёжный источник, а не превращается в догадку о дефекте.
- Сумма ущерба считается по правилам, а не моделью. Расчёт идёт по договорным условиям из ERP; генерация чисел моделью в этом сценарии запрещена на уровне конфигурации.
- Новые товарные категории требуют донастройки. Если у категории другая логика приёмки, регламент и перечень дефектов заводятся отдельно — это ещё 1–2 недели работы.
- Приёмку на точке не трогали. Пересчёт, сверка и физический осмотр остались процессом людей: ИИ включается с момента, когда инцидент уже зафиксирован.
- Прогноз брака по поставщикам не вошёл в объём. Истории за один сезон мало для выводов, к этой задаче вернёмся, когда накопится статистика.
Вопросы и ответы
Частые вопросы по кейсу разбора брака в ритейле
Что именно ускорилось в шесть раз?
Среднее время от фиксации инцидента с браком до принятого решения с назначенной ответственной стороной. Это не скорость ответа модели и не время, за которое она печатает текст. В замер входят распознавание документов, поиск нужного пункта регламента, классификация дефекта, назначение ответственного и постановка задачи со сроком. Раньше эти шаги сотрудник делал последовательно, переключаясь между почтой, файлами регламентов и учётной системой. Теперь карточка инцидента собирается автоматически, а человек проверяет готовое решение и подтверждает его.
Модель сама решает, кто виноват в браке?
Нет. Система предлагает версию — поставщик, логистика или точка — и обязательно показывает основание: пункт регламента, условие договора, данные поставки из ERP. Решение подтверждает сотрудник качества, и в претензию уходит именно его подтверждение. Права закрывать инцидент самостоятельно у системы нет: цена ошибки здесь измеряется не лишней минутой работы, а отклонённой претензией и суммой, списанной на убыток сети. Человек стоит на каждом необратимом шаге, включая отправку документов контрагенту.
Сколько времени заняло внедрение?
Диагностика с картой процесса и расчётом — 30–40 минут разбора плюс несколько дней на выгрузки из учётных систем. Пилот на одной товарной категории занял 2–4 недели: собрали базу регламентов, подняли распознавание документов и прогнали реальный поток инцидентов параллельно с людьми, не переключая процесс целиком. Выход первого контура в продуктив уложился в типовые 4–8 недель. Дальше расширение шло итерациями по одной-две недели: новые категории, новые правила SLA, доработки дашборда.
Почему сеть не взяла облачный сервис?
Через систему проходят фотографии товара, накладные, акты и договорные условия сотен поставщиков. Утечка такой информации — не только юридический риск, но и переговорный: условия закупки становятся видны тем, кому их видеть не следует. Поэтому модели, векторные индексы, журналы и интерфейсы стоят на серверах сети, а внешние API закрыты сетевыми политиками. Второй аргумент — экономика: поток инцидентов измеряется тысячами в месяц, при оплате по токенам счёт растёт линейно, собственный контур стоит фиксированно.
Можно ли повторить этот сценарий в другой компании?
Логика переносится, содержание — нет. Схема «распознали документ, нашли правило, классифицировали, назначили ответственного, посчитали срок» одинаково работает в рознице, дистрибуции и на производстве. Но база регламентов, перечень дефектов, договорные условия и структура учётной системы у каждой компании свои, и именно они определяют объём работы. Поэтому начинаем с диагностики на ваших данных и пилота на одном процессе: он показывает, сходится ли расчёт, до крупных вложений. Соседние проекты собраны в разделе кейсов.
Первый шаг
Бесплатный аудит: посчитаем эффект внедрения ИИ на ваших цифрах
30–40 минут разбора: смотрим ваши процессы, отмечаем, что можно передать ИИ, считаем ROI-модель на ваших объёмах и сроках. Вы уходите с расчётом и картой внедрения — даже если работать дальше не будете.
Читайте также
Цифровой отдел продажКвалификация лидов, автогенерация КП по прайсам и спецификациям, подсказка следующего шага менеджеру, CRM и 1С. КонверсиИИ в документооборотеСценарии ИИ в документообороте: классификация и маршрутизация входящих, извлечение реквизитов, проверка договоров, поискКейсыОбезличенные кейсы внедрения ИИ с метриками до и после: ритейл, производство, образование, маркетинг.