Технологический стек — это бизнес-решение

Рынок корпоративного ИИ перегрет обещаниями. Демо-версии работают идеально, но при столкновении с реальными данными бизнеса — небрежными сканами, разнородными форматами, мультиязычными документами — точность падает, а проект превращается в бесконечный процесс доработок. В этот момент руководитель теряет контроль над сроками и бюджетом. Причина почти всегда не в слабости нейросетей, а в отсутствии правильной инженерной «упаковки» вокруг них.

Технологический стек — это не внутреннее дело разработчика. Архитектура напрямую определяет: как быстро вы получите первую рабочую версию; сколько будет стоить каждая итерация; насколько легко систему будет адаптировать к новым типам документов и языков. Неудачный выбор на старте делает продукт дорогим в поддержке и хрупким при масштабировании.

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

Второй перекос — пытаться закрыть задачу готовым SaaS-сервисом за $20 в месяц без проверки его поведения на ваших данных. Как показывает практика, с нестандартными сканами такие сервисы могут правдоподобно отрисовывать таблицу, но врать в цифрах и названиях. Для бизнеса, где ошибка в одной позиции спецификации грозит срывом сроков и финансовыми потерями, такой риск неприемлем.

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

Прозрачность. Вы всегда знаете, на каком шаге теряется точность, и можете адресно править логику — тюнить OCR-движок, не трогая нейросеть, или дообучать модель сопоставления, не переписывая весь пайплайн.

Заменяемость компонентов. Если под новый тип документов или язык нужен другой OCR-движок, вы меняете его, а не всю систему. Если появляется более сильная языковая модель, вы подключаете её на этапе сопоставления, не затрагивая остальное.

Предсказуемая стоимость развития. Каждый этап можно оценить и развивать независимо. Вы не попадаете в ситуацию, когда «надо переписывать всё».

В проекте для московской строительной компании, работающей с подрядчиками со всей России и из-за рубежа, конвейер был выстроен так:

Этап 1. Компьютерное зрение и OCR. Пользователь загружает изображение и выделяет область с таблицей — на листе могут быть печати, заметки, подписи. Алгоритмы компьютерного зрения нормализуют картинку, находят строки и столбцы, извлекают сырой текст. Это черновая работа — на выходе просто набор данных, без понимания их смысла. Команда перебрала несколько OCR-библиотек, чтобы найти самую точную именно для того типа сканов, с которым работал заказчик.

Этап 2. Интеллектуальное сопоставление. Нейросеть получает две сущности: список колонок из входящего документа и список колонок целевой таблицы заказчика. Задача — найти смысловые соответствия. «Масса единицы» у поставщика становится «Весом изделия» у заказчика. Слипшиеся данные вроде «Труба ДН677 600» разделяются на две колонки: наименование и техническая характеристика. Оркестрация — через LangChain, модели — YandexGPT и GigaChat. Это ключевой этап, где доменная специфика и мультиязычность обрабатываются не универсальным сервисом, а адаптированной моделью.

Этап 3. Верификация. Между этапами встроен экран подтверждения, где пользователь видит, что распозналось, сверяет с исходной картинкой и может поправить ошибки. Это не признак слабости системы, а страховочный пояс: он гарантирует корректность финального результата.

Этап 4. Выгрузка. Пользователь нажимает «подтвердить» и скачивает готовый Excel в едином корпоративном формате.

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

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

Вывод: для быстрого MVP и демо генерация кода — эффективный инструмент. Для масштабируемого корпоративного продукта — код должен проходить ревью. Это принципиальное требование к качеству, а не компромисс.

В проекте для строительной компании мы столкнулись с тем, что входные документы — это не цифровые PDF с текстовым слоем, а «мёртвые» сканы и фотографии, часто на русском и английском языках. Гипотеза «просто прочитать PDF» провалилась сразу. Это меняло архитектуру: требовалось не извлечение текста, а полноценное компьютерное зрение.

Мы построили конвейер, где за детекцию и OCR отвечали OpenCV и EasyOCR, а за интеллектуальное сопоставление колонок — связка LangChain с YandexGPT и GigaChat. Такое разделение позволило локализовать сложность: мы перебирали OCR-библиотеки для максимальной точности именно на сканах заказчика, не трогая логику нейросети, а смысловую модель настраивали отдельно. Результат превзошёл ожидания: заказчик был готов к 30% точности, а прототип показал значительно более высокие показатели. Полный разбор технологического решения — в кейсе: «ИИ для работы с документами: как мы заменили ручной ввод на ИИ-конвейер».

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

• Разбит ли процесс на независимые этапы? Если нет — вы рискуете получить «чёрный ящик», который невозможно отладить.
• Есть ли в пайплайне точка для ручной верификации результата? Это страховка на случай, если точность окажется ниже ожидаемой.
• Можно ли заменить один компонент (OCR-движок, языковую модель), не переписывая всю систему? Это вопрос стоимости будущих доработок.
• Осознанно ли выбраны инструменты прототипирования? Генерация кода ускоряет старт, но для продакшена требует ревью — понимает ли это команда?

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