Georeis

Georeis — сервис для курьерских служб и небольших автопарков, который превращает список адресов доставки в реальный маршрут по дорогам. Диспетчер загружает фотографию путевого листа или вводит адреса вручную, система распознаёт список, сверяет его с собственной адресной базой, строит порядок объезда точек с учётом дорожной сети и обещанного клиенту времени, а если водителей несколько — распределяет заказы между ними.

Продукт закрывает узкую, но постоянно повторяющуюся задачу небольших логистических команд: превратить неструктурированный список адресов — часто просто фотографию бланка — в готовый к исполнению маршрут, а не заставлять диспетчера вручную перепечатывать адреса и прикидывать порядок объезда «на глаз».

Искусственный интеллект используется в одном конкретном месте — распознавании адресов на фотографии путевого листа с помощью vision-модели. Сам расчёт маршрута — не генеративный ИИ, а классические алгоритмы оптимизации: задача маршрутизации транспорта с ограничением грузоподъёмности и временными окнами доставки, решаемая на собственном графе дорог.

Ключевое архитектурное решение — весь стек маршрутизации (граф дорог, решатель маршрутов, кэш геокодирования) развёрнут на собственной инфраструктуре, а не вызывается через внешние картографические API. Единственный внешний сервис — геокодер для российских адресов, и он используется только как резерв, когда адреса нет в собственной базе.

Задача

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

Список адресов обычно приходит неструктурированным — фотография бумажного бланка, а не готовый файл, и кто-то должен вручную перепечатать 10–20 адресов, прежде чем начать думать о маршруте.

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

Как только в игру вступает больше одной машины, задача усложняется на порядок: нужно решить, кому какие точки достанутся, с учётом грузоподъёмности и текущей загрузки каждой машины. Вручную это делать долго, и с ростом парка процесс не масштабируется. Без пересчитанного расписания диспетчер не может сказать клиенту точное время визита, а без собственной адресной базы каждый новый путевой лист заново прогоняется через внешний геокодер, даже если адрес уже встречался накануне.

Решение

Основная цепочка продукта:

Фото/ручной ввод → извлечение и подтверждение адресов → геокодирование → расчёт маршрута → распределение по водителям → выдача маршрута.

Фотография или текст превращается в структурированный список адресов, который проверяет человек, прежде чем список попадёт в расчёт. Каждый адрес сверяется с собственной растущей базой, и только если совпадения нет — уходит запрос во внешний геокодер. Ядро продукта строит порядок объезда точек по реальному графу дорог с учётом временных окон и распределяет точки между водителями, если их больше одного.

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

Как работает

Приём заказов: фото путевого листа и ручной ввод

Диспетчер создаёт задачу маршрутизации двумя способами — загружает фото путевого листа или вводит адреса текстом. Для фото запускается фоновая обработка: vision-модель распознаёт построчный список адресов и фиксирует номер строки на снимке для каждого адреса, чтобы порядок в интерфейсе совпадал с оригиналом. Оригинал снимка сохраняется и может быть переоткрыт для повторного распознавания. Модель развёрнута локально; внешний платный сервис распознавания оставлен только как резерв на случай сбоя.

Проверка и подтверждение адресов

Прежде чем попасть в расчёт маршрута, все адреса проходят экран ручной сверки: статус по каждой строке, правка текста, фильтр «только расхождения». Автоматическое совпадение засчитывается только при точном совпадении нормализованной строки с уже подтверждённым адресом в базе — никакой нечёткий мэтчинг не влияет на маршрут автоматически. Цена ошибки в логистике высокая, поэтому человек остаётся в контуре принятия решения.

Собственная адресная база и внешний геокодер как резерв

Перед обращением к внешнему геокодеру система сначала ищет точное совпадение в своей базе; результат внешнего запроса сохраняется обратно для повторного использования. База копится с первого дня работы. Чем дольше работает диспетчерская, тем меньше она зависит от внешнего геокодера: повторяющиеся адреса — постоянные клиенты, склады, магазины сети — в логистике встречаются часто и после первого распознавания обрабатываются мгновенно из собственной базы.

Расчёт маршрута с учётом дорог и временных окон

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

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

Распределение заказов между несколькими водителями

На странице распределения диспетчер видит пул заказов и список водителей и одной кнопкой из нескольких алгоритмов получает превью распределения — с метриками по весу, объёму, пробегу и времени — прежде чем что-либо сохранится. Точку можно вручную перекинуть другому водителю кликом на карте, задать общую точку отгрузки, включить обязательный возврат на склад.

Разные алгоритмы решают разные приоритеты: минимум суммарного времени в пути (решатель работает сразу для всех водителей и машин), распределение по районам (географическая кластеризация без учёта дорожного графа), выравнивание нагрузки поровну по пробегу или по весу (та же кластеризация плюс перебалансировка точек между водителями). Диспетчер получает объяснимый вариант, а не «чёрный ящик», и правит только то, что не подходит.

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

Приложение водителя как связанный продукт

Каждый построенный маршрут выдаётся в отдельное приложение водителя — список точек, карта, ручной реордер, открытие маршрута во внешних картографических приложениях. Это отдельный продукт со своим интерфейсом, но общим backend с диспетчерской частью — фронтенды специально не сцеплены друг с другом, чтобы развиваться независимо.

Ключевые особенности

Человек подтверждает адреса перед расчётом маршрута — автоматическое распознавание лишь черновик, ни один маршрут не строится по неподтверждённому адресу.

Собственная адресная база растёт с каждым использованием — повторяющиеся адреса после первого распознавания обрабатываются мгновенно, без платного геокодера.

Приоритет «окно важнее километров» — написанная логика, а не настройка стороннего API, что в облачном роутинг-сервисе третьей стороны настроить было бы невозможно.

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

Грузоподъёмность и мультирейс учитываются автоматически — если заказы не помещаются в одну машину, система сама делит их на последовательные рейсы.

Данные клиентов не покидают собственную инфраструктуру — адреса, маршруты и фото путевых листов хранятся на собственном сервере, за исключением резервного обращения к внешнему геокодеру.

Техническая реализация

Мультирейс реализован через несколько последовательных маршрутных слотов с одним депо на одного физического водителя — стандартный решатель не поддерживает нативно сценарий «съездил, вернулся, поехал снова» в рамках одной машины, поэтому это смоделировано на уровне продукта и показывается диспетчеру как «Рейс 1», «Рейс 2» для того же водителя.

Извлечение адресов из фото, геокодирование и расчёт маршрута выполняются в фоновой обработке, не блокируя интерфейс диспетчера: тяжёлые операции поставлены в очередь и обрабатываются асинхронно.

Backend и связанные сервисы — дорожный граф, решатель маршрутизации, база данных и хранилище фотографий — развёрнуты на собственной инфраструктуре, а не вызываются через облачные API картографических провайдеров. Это одновременно вопрос соответствия требованиям к обработке персональных данных (адреса и маршруты не покидают периметр без необходимости) и вопрос контроля над логикой — приоритет «окно важнее километров» на стороннем облачном сервисе не настраивается, а на собственном стеке это написанная и проверяемая функция.

Диспетчерская панель и приложение водителя — два отдельных фронтенда на общем backend, архитектурно организованном как единое приложение, а не набор микросервисов — выбор в пользу скорости запуска и простоты сопровождения на раннем этапе с сохранённой возможностью дальнейшего разделения.

Текущее ограничение: авторизация построена на общем токене доступа, а не персональной учётной записи каждого диспетчера или водителя — это защита от случайного стороннего доступа, но не полноценная модель разграничения прав. Персональная авторизация — запланированный этап.

Технологический стек

Решатель задачи маршрутизации (VRP/TSP/CVRP/VRPTW) — построение порядка объезда точек с учётом грузоподъёмности и временных окон, self-hosted.

Дорожный граф и матрицы расстояний — расчёт времени и расстояния между точками по реальной сети дорог, self-hosted, на собственном OSM-графе.

Vision-модель — распознавание списка адресов на фотографии путевого листа, развёрнута локально, с платным облачным резервом на случай сбоя.

FastAPI + Pydantic — API-слой backend.

SQLAlchemy + PostgreSQL + PostGIS — хранение адресов, маршрутов, организаций и водителей, включая геопространственные данные.

Очередь фоновых задач — асинхронная обработка фото, вызовы vision-модели, геокодирование и расчёт маршрута без блокировки интерфейса.

Объектное хранилище — хранение оригиналов загруженных фотографий путевых листов.

Внешний геокодер — нормализация российских адресов, вызывается только как резерв.

Next.js / React — два отдельных фронтенда: диспетчерская панель и приложение водителя, на общем backend.

Docker Compose — контейнеризация и деплой на собственную инфраструктуру.

Что получилось

Диспетчеру больше не нужно перепечатывать список из 10–20 адресов с фотографии — только проверить и при необходимости поправить то, что распознала модель.

Маршрут строится с учётом реальной дорожной сети и жёстких временных окон клиентов, с явным приоритетом «окно важнее километров», а не компромиссной формулой, скрытой внутри стороннего сервиса.

Распределение заказов между несколькими водителями делается одним из нескольких алгоритмов с превью результата, а не назначением точек вручную одну за другой.

Собственная адресная база растёт с каждым днём работы и снижает зависимость от внешнего платного геокодера на повторяющихся адресах.

Данные клиентов — адреса, маршруты, фотографии путевых листов — хранятся на собственной инфраструктуре и не передаются во внешние сервисы, кроме резервного обращения к геокодеру.

Числовых метрик экономии времени или денег на реальных клиентах пока нет: продукт проверялся на демонстрационной организации и внутренних тестовых данных, а не в масштабном промышленном внедрении.

Где можно использовать

Курьерские службы и службы доставки, где диспетчер ежедневно получает список адресов и строит по нему маршрут для одного или нескольких водителей.

Небольшие автопарки, где нужно распределять заказы между водителями с учётом грузоподъёмности и загрузки каждой машины.

Компании, для которых важно соблюдение временных окон доставки, а не только минимизация общего пробега.

Бизнесы, которым принципиально, чтобы адреса клиентов и маршруты не передавались во внешние облачные картографические сервисы, и организации, которые хотят снизить объём ручного ввода данных за счёт распознавания адресов по фотографии.