Где возникает расход
Когда компания собирает локальную базу знаний из договоров, инструкций, прайс-листов и актов, цена проекта часто начинается не с языковой модели. Сначала документы нужно получить, разобрать и связать с версией, владельцем и правами доступа. Если таблица превратилась в строку без заголовков или OCR потерял одну цифру, поиск может вернуть убедительный, но неверный фрагмент. Ускорение такого процесса не равно экономии.
Docling — пример открытого инструмента для этого этапа. По документации проекта, конвертер выбирает обработчик и конвейер по формату, собирает единое представление Docling Document, после чего его можно экспортировать или разбить на фрагменты. Поддерживаются в том числе PDF и офисные форматы; для старых бинарных файлов нужны дополнительные компоненты. Это не готовая корпоративная база знаний: индексацию, разграничение доступа, обновления и проверку ответа строят отдельно.
Преимущество локальной обработки состоит не в магическом качестве распознавания, а в контроле маршрута данных. Документация Docling описывает предварительную загрузку моделей в локальный каталог. Отправка пользовательских данных внешним сервисам требует явного включения соответствующей опции. Но слово «локально» нужно подтверждать настройками всей цепочки: OCR-движка, скачивания весов, журналов, хранилища, индекса и конечной LLM.
Что считать до покупки сервера
Возьмём модельный, а не наблюдавшийся у какой-либо компании процесс: 1 200 документов в месяц, в среднем по четыре страницы. Сотрудник вручную тратит четыре минуты на подготовку одного документа к поиску: проверяет название, тип, дату, значимые поля и прикрепляет его к нужному разделу. При полной стоимости часа 900 ₽ это 80 часов, или 72 000 ₽ в месяц. Число не включает первоначальную оцифровку бумаги и работу над вопросами пользователей.
Предположим, что после локального парсинга человек разбирает 15% исключений по пять минут и выборочно проверяет ещё 10% документов по две минуты. Получается 15 часов на исключения и четыре часа на выборочную проверку — всего 19 часов, или 17 100 ₽. На амортизацию существующего оборудования, эксплуатацию, хранение и поддержку в этой модели отнесём ещё 18 000 ₽ в месяц. Условный ежемесячный расход составит 35 100 ₽, разница с ручным сценарием — 36 900 ₽.
Если интеграция обошлась в 180 000 ₽, простое отношение разовых затрат к условной месячной разнице даёт около 4,9 месяца. Это не обещание окупаемости Docling и не рыночная цена внедрения. Все ставки, объёмы, доли ошибок и затраты здесь придуманы только для демонстрации формулы. Собственные цифры могут радикально изменить вывод. Если документы уже поступают в чистом структурированном виде и ручная подготовка занимает минуту, экономить почти нечего. Если поток состоит из плохих сканов с таблицами, очередь проверки может стать длиннее исходной работы.
Особенно важно не спрятать стоимость ошибки в «средней точности». Например, в этой же модели 12 неверно извлечённых документов с прямым ущербом по 5 000 ₽ добавят 60 000 ₽ расходов и уничтожат всю расчётную экономию. Частота 12 случаев здесь тоже не измерена: это стресс-сценарий, который показывает, почему нужно отдельно оценивать критические поля, а не только красивый Markdown. Ошибка в номере детали, сумме, сроке действия или пункте договора имеет иную цену, чем потерянный перенос строки.
Где парсер заканчивается и начинается RAG
Рабочий маршрут выглядит так: файл попадает в контролируемое хранилище, где ему назначают идентификатор, версию, источник и список допущенных сотрудников. Затем парсер извлекает текст, структуру и таблицы; проверка отмечает неудачные страницы и критические поля. Только после этого фрагменты попадают в индекс. Поиск должен фильтровать результаты по правам пользователя и актуальной версии документа. Генератор ответа получает найденные фрагменты с указанием источника, а не весь архив без разбора.
На каждом шаге есть отдельный владелец ошибки. Docling не решает, кому можно видеть договор; это задача хранилища и поискового слоя. Он не гарантирует, что устаревший прайс удалён из индекса; нужен механизм обновления и удаления. Он не подтверждает юридическую силу извлечённого текста; для спорных сумм и условий нужен человек и оригинал. Поэтому экономику надо сравнивать для всей цепочки «документ — проверка — поиск — ответ», а не для одного вызова OCR.
Обновления также стоят денег. Для повторной загрузки нужны правила: считать ли новый файл новой версией, что делать с дубликатами, удалять ли старые фрагменты, кто отвечает за ошибочный источник. На пилоте удобнее взять один тип документов и одного владельца процесса. Не стоит сразу превращать весь файловый сервер в индекс: объём вырастет раньше, чем появится проверяемое качество.
Ограничения, которые видно на тестах
Независимый небольшой открытый тест DocCrush сравнил четыре парсера на шести PDF. В нём Docling успешно обработал все шесть и хорошо справился с финансовыми таблицами и чистым сканом, но плохо — со сложным документом, насыщенным изображениями. Это полезное предупреждение, а не универсальный рейтинг: набор мал, оценки структуры частично подготовлены с помощью ИИ и ожидают человеческой проверки. Результат нельзя переносить на русские договоры, накладные и сканы без собственного набора испытаний.
Отдельно проверьте языки OCR, качество исходных сканов, рукописные пометки, поворот страниц, объединённые ячейки и таблицы на нескольких листах. Быстрый парсер может быть достаточен для простых текстовых PDF, а более тяжёлый конвейер — оправдан лишь для документов, где важна структура. Сравнивайте не только секунды на страницу, но и затраты на исправление результата, долю непрочитанных файлов и скорость нахождения ответа сотрудником.
Для изолированного контура заранее определите, где лежат веса моделей и как они обновляются, какие компоненты имеют исходящий доступ, сколько памяти и процессорного времени съедает пакетная обработка, что пишется в логи. Коммерческое использование кода Docling разрешено MIT-лицензией, но лицензии отдельных моделей и зависимостей нужно проверять отдельно. Если это не сделано до закупки, оценка ежемесячных затрат будет неполной.
Пилот без большого бюджета
Соберите 100–200 документов одного процесса: типовые, сканы, таблицы и заведомо неудобные исключения. Сохраните оригиналы и подготовьте эталон по важным полям и 20–30 реальным вопросам сотрудников. Замерьте ручное время на документ сегодня. Затем прогоните локальный конвейер и фиксируйте отдельно время машины, время проверки, долю исключений и критические ошибки. На вопросы отвечайте с указанием документа и страницы; ответ без проверяемого источника считайте неуспешным.
Решение о внедрении принимайте по двум воротам. Первые — качество: допустимая доля пропущенных критических полей и неверных ответов задана владельцем процесса заранее. Вторые — деньги: фактическая экономия человеко-часов покрывает эксплуатацию, интеграцию и стоимость исправлений за приемлемый срок. Если первые ворота не пройдены, положительный расчёт часов не имеет смысла. Если вторые не пройдены, локальный RAG может остаться полезным поисковым экспериментом, но его не стоит продавать как экономию.
Фото: Skot / Wikimedia Commons, CC BY-SA 4.0. Квадратная обложка получена кадрированием фотографии; производная обложка распространяется на тех же условиях. Фото показывает оцифровку книги, а не работу Docling или результат описанного модельного расчёта.