Всем привет, с вами Низамов Илья. Сегодня расскажу как я за полтора месяца ежедневной работы разработал свой сервис по распознаванию документов на локальном компьютере с помощью ИИ.

Для корректного сравнения не хватает метрик точности и качества. Демо показать можно достаточно быстро на базовых нейросетках, в этом проблем нет. Но будет ли количество ручной работы на реальных данных достаточным для нужд предприятия - не вполне понятно (за нейросеткой ошибки так или иначе придется править). Облачные сервисы не просто так не запускаются локально, для достижения реально хорошего качества могут потребоваться такие вложения в оборудование, что это ни один проект с ИИ не окупит, и это я уже не говорю про необходимость выбора типа документа вручную, и разнообразных вариантов шаблонов документов, которые простыми охватывающими прямоугольниками не описываются

В langfuse можно составить тестовый датасет и прогонять его используя различные нейронки и подходы в улучшении изображений. Конкретно для этого проекта будет достаточно 3-4 видеокарты класса 3090 или 4090. И естественно ни одна модель не может дать 100% распознавания, даже облачная, и в последнее время все больше небольших моделей с очень неплохим качеством работы.

Плюс учитываем зарплату сотрудника, который целыми днями сидит и вводит в 1С данные со сканов. Думаю если прикинуть в годовом эквиваленте, то получится как раз стоимость среднего сервера.

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

И да, этот проект не про обработку 1000 сканов в минуту, там безусловно нужны совершенно другие мощности, проще платить за облачный сервис.

На получение алгоритма, который достаточно хорошо обрабатывает все пограничные кейсы, может потребоваться длительное время, как минимум на разметку данных и эксперименты. Учитывая, что решение предполагает несколько шагов (как минимум, определение типа документа, распознавание текста и последующий анализ), нужно будет составление нескольких датасетов, которые в идеале будут из вашего домена. Каждая последующая итерация экспериментов (80->90% качества, 90->95, 95->97 и тд) может требовать одинаковых, если не больших усилий, это полноценное RnD с непредсказуемым заранее результатом. Не вполне понятно, зачем организации, для которой деятельность по внесению документов в базу не является основной, тратить порядка миллиона только на оборудование (которое после получения первых результатов уйдет на продовый инференс, а значит на последующие эксперименты его уже не останется), если есть возможность купить готовое коробочное решение у вендора по сопоставимой цене. Те же бывшие Abbyy, ныне ContentAI или SmartEngines вполне себе селфхост предоставляют

Конкретно в этом примере, для обучения по паспортам понадобилось 15 сканов и модель стала выдавать очень хорошие результаты. Пробовал аналогичную задачу на транспортных накладных, там понадобилось около 200 сканов. Для разметки датасетов можно применять различные автоматизированные методики, в том числе с помощью облачных моделей. А можно где-то посмотреть эти коробочные решения, просто все что я пробовал с сайта Abbyy, там есть триал режим, давало такой себе результат.

Про оборудование. Если наша задача только допустим водительское удостоверение, и путевой лист. Сканы делает оператор с хорошим качеством. Для разделения совмещенного скана берем обученную yolo и обработку делает qwen vl 7b, работать будет на одной 3090 за 70тыс. Никаких миллионов тут не надо.

Касательно распознавания документов есть вопрос про юридическую сторону. Мы не стали внедрять механизмы сканирования и распознования потому что юристы и бухгалтера сказали, нам нужны бумажные документы. А раз нужны бумажки, то смысл тратить время на их сканирование? Юрист говорит, что нельзя отсканировать и выкинуть оригинал. И мы тогда бросили саму идею сканирования, зачем вообще вся эта возня если бумажки все равно надо хранить? Пусть сидят со своими бумажки, пусть вводят вручную. У кого какой опыт с такими проблемами? Если действительно нужно хранить бумажные документы, то может и распознавание не нужно?

Если у вас хватает бухгалтеров вводящих все ручками, то ничего внедрять не надо. Ко мне же приходят клиенты с задачами, когда они не хотят раздувать штат. Им проще заплатить за проект годовую зарплату сотрудника и потом оплачивать доступ к chatgpt для работы сервиса.

Тоже вот касательно распознавания документов. Почти вся первичка отправляется в ЭДО, и затем там уже подвязывается в 1с. Если кому нужен бумажный документ то он печатается. И не всегда название в условной накладной соответствует наименованию в 1с и пусть оно хоть 100 раз будет распознано, товар все равно связывается руками. В конце концов так или иначе все будет маркированно и по факту без ЭДО получить/отгрузить товар не получится, а ЭДО это по сути прямое заведение докумена в 1с А с 2026г планируется введение единого справочника наименований товаров, который должны будут использовать все организации.

Вопрос немного вне контекста, не знаю где его тут задать. У меня есть платная подписка на спонср на одного товарища. 5 лет ежедневно выходят тексты. чтение на 10 минут. Мне нужно чтобы нейронка делала поиск по этим текстам тематический. Можно ли все это сделать на локальных мощностях? допустим загрузить тексты в RAG и искать ламой? Или же тут стоимость железа будет таковой что проще купить подписку на облачный ИИ и ему этот раг давать? Что не хочется. Что скажешь по личному опыту?

Попробуй классический RAG, база FAISS для хранения и поиска, для эмбедингов подойдут локальные модели с https://huggingface.co/, если надо просто найти текст статьи то llm тут даже не надо. Если хочешь получить выжимку или в чате потом обсудить то и локальная модель справится, если видео карта есть хорошая.

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

В общем спасибо. покопаю

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

хмм.. Тогда на какой границе надо начинать думать о RAG?

Когда это не личный проект, а что-то более продуктовое, где отправлять на каждый запрос пачку документов в ллм уже слишком накладно + можно эвристиками сократить перебор, например если в статьях есть теги - то оставлять только те статьи, которые вам релевантны по тегам Векторный поиск рискует пропустить важную информацию, что для задачи «извлечь всю информацию как можно полнее» критично