Мы не смогли найти на рынке готовых решений, которые решают эту задачу с достаточным качеством. Тесты показали, что существующие инструменты затрагивают только один аспект сложности. Инструмент, отвечающий всем аспектам сложности, требует исследовательской и инженерной работы. Модели Google продемонстрировали наилучшую производительность и экономическую эффективность. Окончательное решение будет работать на платформе Google Vertex AI.

Аспекты сложности:

• Оптическое распознавание символов (OCR)
• Счет-фактура или другой документ
• Строки в счете-фактуре
• Поля в строках счета-фактуры
• Общие поля для счета-фактуры
• Многостраничные счета-фактуры
• Общие поля для страниц счета-фактуры
• Форматы счетов-фактур

Что нам нужно, чтобы начать:

• Список приоритетных полей
• Список всех полей
• Примеры наиболее распространенных или сложных (среди распространенных) форматов счетов-фактур для этапа ДЕМО
• Полный спектр счетов-фактур, на которых нам нужно продемонстрировать эффективность на этапе MVP
• Четкие и измеримые показатели/критерии качества
• Ограничения стоимости на страницу (если есть)

Мы провели серию тестов на наборе из 165 отсканированных документов, включая счета-фактуры и другую документацию. Были использованы новейшая модель OpenAI и специализированная модель Google.

Наблюдения и выявленные проблемы:

• Модели могут идентифицировать счета-фактуры/не счета-фактуры с высокой точностью (>90%) без дополнительных инструкций. Ожидается, что простые меры повысят точность до 95-99%.
• Модели хорошо обрабатывают одностраничные счета-фактуры в одном формате.
• Модели эффективно обрабатывают серию счетов-фактур в нескольких форматах без структурирования полей.
• Распознавание текста безошибочно и менее подвержено опечаткам в исходных документах.
• Качество выполнения сложных инструкций (распределение полей) снижается с увеличением количества обрабатываемых страниц одновременно.
• Пакеты многостраничных счетов-фактур могут содержать сотни страниц, что требует либо постраничной обработки с последующей обработкой текста и метаданных, либо разработки решения для идентификации и обработки многостраничных счетов-фактур.
• Модели точно определяют количество товаров в упаковке, если это указано в описании, и извлекают это в отдельное поле, если это указано в инструкции.
• Учитывая потенциальные сотни форматов счетов-фактур, предпочтительным является решение, независимое от предварительно настроенных сопоставлений. Необходимо изучить поведение системы. Предполагается, что может потребоваться векторная база данных. Это выполнимо при работе с векторными вложениями из текста. Может потребоваться разработка пользовательского преобразователя для векторизации отсканированных счетов-фактур.
• Поля, относящиеся к нескольким строкам или страницам счетов-фактур, также могут представлять собой инженерную проблему, которую необходимо решить.

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

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

Этапы:

1. Демо

• Выбор решения, которое потенциально превосходит текущее.
• Демонстрация на ограниченном количестве вариантов.
• Только обязательные поля строки (название, количество, цена за единицу, итог, дата).
• Только наиболее распространенные общие поля счета-фактуры (VATID, итог, нетто, брутто, идентификатор клиента, телефон, IBAN, название поставщика, дата счета-фактуры).
• Оценка реальных узких мест.
• Гипотеза архитектуры.
• Решение может работать на одном агенте или может потребоваться разделение на несколько; может быть добавлена VDB, может появиться кластеризация формата/полей счета-фактуры, может потребоваться пользовательский преобразователь/векторизатор для изображений счетов-фактур.

Продолжительность: 5-10 рабочих дней Стоимость: €2400

2.MVP

• Разработка решения, соответствующего метрикам и работающего с расширенным диапазоном форматов. Устранены узкие места.
• Предположительно готовое решение без интеграции в бизнес-процессы компании. Продолжительность: 10-15 рабочих дней Стоимость: €6000 Продолжительность и стоимость являются предварительными. Они не изменятся, если задача и условия останутся неизменными.

3.Развернутое решение

• Интеграция в бизнес-процессы компании.
• Изменение решения на основе результатов работы в рамках бизнес-процессов.
• Развертывание решения на серверах компании.
• Обработка ошибок бизнес-процесса.
• Отладка и запуск. Продолжительность: 10-15 рабочих дней Стоимость: €6000 Продолжительность и стоимость являются предварительными.

ОКОНЧАТЕЛЬНЫЕ СРОКИ И СТОИМОСТЬ
Продолжительность: 25-40 рабочих дней Стоимость: €14 400

Альтернативный подход
Если вам нужен более подробный, поэтапный подход для отдельных функций, вот наше предложение для детектора счетов-фактур.
В этом случае мы предлагаем работу в почасовых пакетах, начиная с 40 часов по ставке 60 евро в час. Мы предоставляем регулярные отчеты с обоснованиями, где вы можете увидеть и оспорить затраченные часы. Часы могут быть использованы для улучшения существующего решения и разработки других функций. Неиспользованные часы не истекают в течение 12 месяцев.
Разработка решения для обнаружения счетов-фактур/не счетов-фактур Тестирование и настройка на больших наборах данных Интеграция в существующую платформу Усовершенствования после внедрения с учетом реальных процессов
Продолжительность: 10-25 рабочих дней Стоимость: 50-80 часов
Несмотря на то, что альтернативный подход может снизить риски, мы считаем этот подход менее рациональным по сравнению с разработкой и внедрением всего решения. В этом случае мы будем совместно проводить исследования и инженерные разработки по всем задачам, а затем совместно внедрять их.

Если вам нужно такое или иное решение с использованием AI в бизнес процессах, записывайтесь на звонок: https://calendly.com/vpesh/30