AI

Назад

OCR + LLM + RAG в логистике: архитектура системы, которая обрабатывает накладную за 15 секунд вместо 15 минут

VibeLab

Поделиться

Средний логистический оператор тратит 12–15 минут на ручную обработку одной транспортной накладной. При 300 документах в день это 75 человеко-часов — почти 10 штатных единиц, занятых перепечатыванием данных из бумаги в ERP. В этой статье разберу архитектуру связки OCR → LLM → RAG, которую мы собрали для автоматизации трёх ключевых процессов: обработки CMR, диспетчеризации заявок и клиентской поддержки.

Проблема: почему классический OCR не справляется с логистикой

Транспортная накладная — формально простой документ: отправитель, получатель, груз, маршрут, дата. Но в реальности вы получаете мятые сканы, рукописные пометки и три разных формата CMR от разных перевозчиков.

Типичные узкие места:

  • Ввод данных из накладных в TMS/ERP — оператор переносит 15–25 полей вручную. Ошибки в 3–7% случаев, каждая — потенциальный штраф или задержка.
  • Диспетчерские запросы — заявки приходят по email, WhatsApp, телефону в свободной форме. Диспетчер тратит 5–10 минут на структурирование каждой.
  • Клиентская поддержка — «Где мой груз?» занимает 3–5 минут на один звонок: открыть TMS, найти заказ, свериться с GPS, сформулировать ответ.

Экономика: 300 накладных × 15 минут = 75 часов ежедневно. При стоимости оператора ~250 000 руб/мес (с налогами и рабочим местом) — порядка 2,5 млн руб/мес только на ввод данных. Прибавьте пересортицу, штрафы за некорректные CMR, потерянные заявки — ещё 500–800 тыс.

Классический OCR (Tesseract, ABBYY) распознаёт текст, но не понимает его. Он выдаст строку ООО Транслогистик, г. Москва, ул. Складская 12 — но не определит, отправитель это или получатель. Для документов со свободной вёрсткой это критичная разница.

Архитектура: три контура на общей RAG-инфраструктуре

Решение — не «поставить чат-бота» и не «подключить нейросеть к сканеру». Это три взаимосвязанных контура, которые усиливают друг друга через общий vector store.



Контур 1: OCR + LLM для документов. Сканированные накладные и CMR → структурированные данные. Пайплайн: сканирование → распознавание текста → извлечение полей через LLM → валидация → запись в ERP/TMS.


Контур 2: RAG-система для диспетчеризации. Входящие заявки в свободной форме автоматически парсятся, классифицируются и превращаются в задачи. Модель опирается на базу знаний компании.


Контур 3: Чат-бот с доступом к TMS. Клиенты и водители получают ответы на типовые вопросы за секунды. Бот обращается к TMS и GPS-данным в реальном времени.


Одна инвестиция в vector store — три точки возврата.


Контур 1: пайплайн обработки документа в деталях


Шаг 1. Предобработка изображения


Нормализация решает до 80% будущих ошибок OCR. Минимальный набор:




Минимальное разрешение — 300 DPI. Если документ приходит в меньшем — масштабируем. Без этого точность OCR падает на 10–15%.


Шаг 2. OCR-распознавание


Для русскоязычных документов варианты:


    

  • Google Document AI / Yandex Vision — 96–98% accuracy на качественных сканах. Облако.
    • 

  • Tesseract + русская модель — 90–94%, зато on-premise.
    • 

  • EasyOCR — компромисс, 92–95%, работает локально, проще в настройке.
    • 





Для продакшена мы остановились на EasyOCR для on-premise сценариев и Yandex Vision для облачных. Tesseract заметно проигрывает на рукописных пометках.


Шаг 3. LLM-извлечение полей


Здесь магия. LLM получает «сырой» текст и промпт со схемой, возвращает структурированный JSON:




Использование response_format с Pydantic-моделью гарантирует валидный JSON на выходе — не нужно парсить ответ регулярками.


Шаг 4. Валидация через RAG


Здесь подключается общий vector store. Извлечённые данные сверяются с:


    

  • Справочником контрагентов — fuzzy-match по названию компании и ИНН. Если sender_name отличается от ближайшей записи в базе на >15% (по Levenshtein), документ уходит на ручную проверку.
    • 

  • Историей накладных — если по тому же маршруту и контрагенту за последний месяц средний вес был 5 тонн, а сейчас пришло 50 — флаг.
    • 

  • Справочником маршрутов — валидация пары «откуда–куда».
    • 





Бенчмарки моделей


Мы протестировали несколько моделей на датасете из 500 русскоязычных транспортных накладных:


ПараметрGPT-4oClaude SonnetMistral LargeFine-tuned Mistral 7B
Точность извлечения полей94–97%93–96%89–93%95–98%
Стоимость на 1000 документов~$15–20~$12–18~$8–12~$1–2 (свой GPU)
Latency (один документ)3–5 сек3–6 сек2–4 сек1–2 сек
On-premiseНетНетДа (через vLLM)Да


Для продакшена с высоким объёмом fine-tuned Mistral 7B — оптимальный выбор. Точность на уровне GPT-4o при стоимости на порядок ниже. Для старта или малых объёмов — GPT-4o через API, чтобы не возиться с инфраструктурой.


Контур 2: RAG-диспетчеризация заявок


Диспетчер получает заявку вида: «Нужно забрать 2 паллета из Подольска завтра утром, доставить в Казань до пятницы. Термо не нужен, но хрупкое.» Из этого нужно создать структурированную задачу в TMS.


RAG-пайплайн:


    

  1. Парсинг заявки — LLM извлекает: откуда, куда, что, когда, требования.
    2. 

  2. Обогащение из базы знаний — поиск по vector store: ближайшие тарифы на направление, доступные машины, история аналогичных перевозок.
    3. 

  3. Формирование задачи — структурированный объект для TMS с предзаполненными полями.
    4. 

  4. Оценка стоимости — на основе RAG-контекста модель предлагает ценовой диапазон.
    5. 





Время обработки заявки: 10–20 секунд вместо 5–10 минут. Диспетчер переходит из режима «ввожу данные» в режим «проверяю и подтверждаю».


Контур 3: чат-бот с доступом к TMS


Клиент спрашивает «Где мой груз по заказу TL-2024-1587?» Бот:


    

  1. Извлекает номер заказа из вопроса.
    2. 

  2. Запрашивает статус в TMS через API.
    3. 

  3. Получает GPS-координаты транспорта.
    4. 

  4. Формулирует ответ на естественном языке.
    5. 



Время ответа: 5–10 секунд вместо 3–5 минут на звонке.


Для реализации хорошо подходит function calling — LLM вызывает нужные API-функции как tool calls.


Стоимость и окупаемость


Примерные затраты на внедрение для среднего логистического оператора (200–500 документов/день):


СтатьяСтоимость
Разработка (MVP, 2–3 мес.)2–4 млн руб
Инфраструктура (GPU-сервер или облако)100–300 тыс руб/мес
API LLM (при облачном варианте)50–150 тыс руб/мес
Поддержка и доработка150–300 тыс руб/мес


Экономия:


    

  • Сокращение ручного ввода: ~2,5 млн руб/мес
    • 

  • Снижение ошибок: 500–800 тыс руб/мес
    • 

  • Ускорение диспетчеризации: 300–500 тыс руб/мес
    • 

  • Снижение нагрузки на поддержку: 200–400 тыс руб/мес
    • 



Итого экономия: 3,5–4,2 млн руб/мес. Окупаемость MVP: 1–2 месяца после запуска.


Грабли и уроки


    

  1. Качество сканов решает всё. Если на вход подаётся фотография накладной, снятая на телефон при плохом освещении — никакая модель не поможет. Инвестируйте в нормальные сканеры и инструкции для сотрудников.
    2. 

  2. Fine-tuning нужен не сразу. Начните с GPT-4o / Claude через API. Fine-tune имеет смысл при >100 документов/день и стабильном формате.
    3. 

  3. Валидация важнее распознавания. LLM будет галлюцинировать. RAG-валидация через справочники ловит 90% таких случаев.
    4. 

  4. Human-in-the-loop обязателен на старте. Первые 2–3 месяца все результаты проходят проверку оператором. Это же источник данных для fine-tuning.
    5. 





Если работаете над подобной задачей — пишите в комментариях, обсудим детали. Особенно интересен опыт с on-premise моделями для обработки конфиденциальных документов.




Подписывайтесь на наш канал: @vibelogia


Поделимся опытом


hello@vibelab.ru


8 800 201 85 68


Написать в Telegram