Я дважды создавал один и тот же инструмент для извлечения B2B-документов: правила против LLM.

Практическое сравнение извлечения PDF-файлов на основе правил с использованием pytesseract и подхода на основе LLM с Ollama и LLaMA 3, основанное на реалистичном сценарии B2B-заказа.

Делиться

Представьте следующую ситуацию: вы работаете в операционном отделе компании среднего размера. Каждый день ваша команда обрабатывает бланки заказов от разных B2B-клиентов. Все они поступают в формате PDF. И теоретически, все они содержат одну и ту же информацию: идентификатор клиента, номер заказа на покупку, дату доставки и заказанные товары.

Однако на практике каждый документ выглядит немного по-разному: один клиент указывает номер заказа на покупку в верхнем левом углу, другой — в нижнем правом. Некоторые пишут «Номер заказа на покупку», другие используют «Идентификатор заказа», «Ссылка на заказ» или что-то совершенно другое.

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

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

Именно эту проблему я и воссоздал для данной статьи.

Мы сравниваем два разных подхода к извлечению структурированных данных из форм заказов B2B:

1. Традиционный подход, основанный на правилах, с использованием Pytesseract и правил регулярных выражений.
2. Подход на основе LLM с использованием pytesseract, Ollama и LLaMA 3

Цель этой статьи не в том, чтобы показать, что программы LLM в целом лучше. Это не всегда так.

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

Оглавление
1 – Пошаговое руководство
2 – Прямое сравнение
3. В каких случаях НЕ следует использовать LLM?
4 – Заключительные мысли
Где продолжить обучение?

1 – Пошаговое руководство

Мы поэтапно воспроизводим оба подхода. Сначала мы создаём два образца PDF-файлов, содержащих одну и ту же бизнес-информацию, но с разным форматированием. Затем мы извлекаем данные один раз с помощью традиционного алгоритма оптического распознавания текста и регулярных выражений, а другой раз — с помощью алгоритма оптического распознавания текста и LLM. Это позволяет нам сравнить оба подхода в идентичных условиях.

• Традиционный подход, по сути, задает следующий вопрос:
  «Могу ли я найти именно тот шаблон, который я запрограммировал?»
• Вместо этого, подход, основанный на модели LLM, задает следующий вопрос:
  «Могу ли я понять значение этого поля в контексте?»

→ 🤓 Полный код можно найти в репозитории GitHub 🤓 ←

Перед началом — Подготовка к мероприятию

Пип против Анаконды

В этом руководстве мы используем pip, стандартный менеджер пакетов Python. Это означает, что мы устанавливаем все библиотеки непосредственно через командную строку с помощью команды `pip install …`. pip уже автоматически включается при установке Python. Если вы знакомы с руководствами по Python, работающими с Anaconda, это просто еще один способ достижения той же цели (используя `conda install …`). В статье «Экосистема анализа данных на Python — руководство для начинающих» вы найдете более подробную информацию о начале работы с Python. Кроме того, на устройствах Microsoft мы используем терминал CMD (клавиша Windows + R > щелкните cmd).

Создайте и активируйте новую виртуальную среду.
Создайте новую среду Python с помощью python –m venv b2bdocumentextractor (вы можете изменить имя) в терминале и активируйте её с помощью b2bdocumentextractorScriptsactivate .

Необязательно: проверьте Python и pip.

 python --version pip --version

Вы должны увидеть версию Python и версию pip.

Шаг 1 – Установите Tesseract

Tesseract — это движок оптического распознавания текста (OCR). Это инструмент, который фактически считывает текст с изображений или отсканированных PDF-файлов с помощью OCR. pytesseract — это всего лишь мост Python для Tesseract. Это означает: наш код Python может взаимодействовать с Tesseract через pytesseract, но фактическое распознавание текста осуществляется самим Tesseract. Без предварительной установки Tesseract pytesseract работать не будет.

Сначала мы скачиваем последнюю версию .exe-файла для Windows 64 и запускаем установщик:
GitHub – Tesseract в UB Mannheim

Важно: запомните путь установки:

 C:Program FilesTesseract-OCR

В командной строке (CMD) мы проверяем установку с помощью следующей команды:

 "C:Program FilesTesseract-OCRtesseract.exe" --version

Если всё прошло успешно, мы должны увидеть соответствующую версию Tesseract.

Шаг 2 – Установка Poppler

Далее устанавливаем pdf2image. Это наша библиотека для преобразования PDF-файлов в изображения, и для её работы требуется Poppler в фоновом режиме. Poppler — это библиотека с открытым исходным кодом для рендеринга PDF-файлов, используемая для отображения PDF-файлов.

Для этого мы скачиваем последнюю версию Poppler, распаковываем ZIP-файл и перемещаем распакованную папку на диск C: .
Релизы GitHub-Poppler для Windows

Внутри папки щелкните «Библиотека» > «bin» и сохраните путь к папке на диске C:. На моем компьютере это выглядит так:

 C:Usersschuepoppler-26.02.0Librarybin

Кроме того, мы добавляем путь в переменную PATH, чтобы Windows знала, где находится Poppler.

Подсказка для новичков:
Нажмите клавишу Windows и найдите пункт «Изменить переменные среды». Затем нажмите «Изменить системные переменные среды». После этого нажмите «Переменные среды». В разделе «Пользовательские переменные» выберите переменную PATH, нажмите «Изменить», затем «Создать» и вставьте путь.

Теперь перезапустите командную строку, чтобы изменения вступили в силу.

Шаг 3 – Установка библиотек Python

Теперь установим все необходимые библиотеки Python. Перед этим обязательно активируйте среду Python:

• pytesseract: Мы устанавливаем эту библиотеку в качестве моста между Python и Tesseract. Tesseract уже установлен в качестве движка распознавания текста, но Python может взаимодействовать с ним напрямую только через pytesseract.
• pdf2image: pytesseract — это движок оптического распознавания текста (OCR), то есть он распознает текст по пикселям изображения. Он не может напрямую считывать структуры PDF-файлов. Поэтому pdf2image выполняет промежуточный шаг: он отображает каждую страницу PDF-файла как изображение, подобное скриншоту, чтобы pytesseract мог проанализировать его впоследствии. Примечание: если бы у нас были цифровые PDF-файлы (то есть PDF-файлы, в которых можно выделять и копировать текст), мы могли бы напрямую извлекать текст, используя такие библиотеки, как pdfplumber или PyMuPDF. Однако, поскольку мы предполагаем, что на практике формы заказов B2B часто представляют собой сканированные изображения, мы используем обходной путь через pdf2image.
• pillow: pdf2image и pytesseract используют эту библиотеку обработки изображений в фоновом режиме (мы не видим ее прямого использования в коде) для корректной обработки изображений.
  fpdf2: Мы используем эту библиотеку для автоматического создания двух тестовых PDF-файлов (макет A и макет B) с помощью скрипта для примера статьи.
  ollama: Эта библиотека позволяет нашему скрипту на Python отправлять сообщения в LLM и получать ответы.

Шаг 4 – Установите Ollama и скачайте LLaMA 3.

После успешной установки библиотек мы устанавливаем Ollama и LLaMA 3 в качестве LLM. Ollama — это инструмент, позволяющий запускать LLM совершенно бесплатно, локально на нашем ноутбуке и без ключей API.

Сначала установим Ollama. Если вы еще этого не сделали, вы можете скачать установщик для Windows с сайта Ollama и запустить его.

После этого мы загружаем LLaMA 3, используя следующую команду:

 ollama pull llama3

В зависимости от скорости вашего интернет-соединения этот этап может занять некоторое время, поскольку загружается примерно 4,7 ГБ данных. Однако в терминале отображается индикатор выполнения.

После этого мы проверяем, всё ли сработало:

 ollama list

Если вы видите что-то похожее на скриншот, значит, всё прошло успешно.

Шаг 5 – Создайте папку проекта и сгенерируйте тестовые PDF-файлы.

Для этого сравнения мы создаем две формы заказа B2B для компаний Alpha GmbH и Beta AG, содержащие одну и ту же информацию, но использующие разные макеты. В этом примере мы предполагаем, что формы заказа представляют собой сканированные файлы, поэтому мы предварительно установили библиотеку pdf2image (для цифровых PDF-файлов это также возможно с помощью таких библиотек, как pdfplumber или PyMuPDF).

Сначала создадим папку проекта, чтобы хранить в ней все файлы:

 mkdir document_extractor cd document_extractor

Далее создадим новый файл с именем create_test_pdfs.py и вставим в него следующий код, который вы можете найти в этом GitHub-Gist. Сохраним этот файл в ранее созданной папке document_extractor:

https://gist.github.com/Sari95/a52a62eb78e0604c4d8c64f5cdd1160a

Теперь вернёмся в терминал и выполним файл:

 python create_test_pdfs.py

Внутри папки теперь можно увидеть два только что созданных PDF-файла:

В двух PDF-файлах проблема уже видна:

• Они содержат одну и ту же информацию.
• Однако в PDF-файлах используются совершенно другие названия полей и другой формат даты.

Подход 1: Традиционный способ (pytesseract + правила регулярных выражений)

Традиционный подход работает в два этапа:

1. Сначала мы преобразуем PDF-файл в изображение. Затем используем Pytesseract для чтения изображения и извлечения исходного текста с помощью OCR (оптического распознавания символов). Проще говоря, OCR означает, что инструмент «смотрит» на изображение и пытается распознать буквы по пикселям. Это очень похоже на то, как люди расшифровывают рукописные заметки.
2. На втором этапе мы используем регулярные выражения. Это регулярные выражения, которые ищут определенные шаблоны в тексте. Например, мы можем определить: «Найти все, что идет после PO Number: ».

Уже на этом втором этапе мы можем определить первую проблему: что произойдет, если клиент просто напишет «Номер заказа» вместо «Номер заказа на покупку:»?

В этом случае регулярное выражение ничего не находит. Тогда мы можем (или должны) добавить новое правило.

Выполните скрипт 1 для подхода 1.

Далее мы создадим новый файл с именем approach1_traditional.py, содержащий следующий код, который вы можете найти в GitHub-Gist в той же папке:

https://gist.github.com/Sari95/aa2be6938fbcb1c7f94b053d9046f55d

Теперь снова запустим файл в терминале:

 python approach1_traditional.py

Результат подхода 1

В варианте компоновки А всё работает идеально:

Для варианта B? Ни одно поле не распознается, и все значения возвращают «None»:

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

Подход 2: Новый путь (pytesseract + Ollama + LLaMA 3)

Во втором подходе мы сохраняем этап оптического распознавания символов (OCR), но заменяем жесткие правила регулярных выражений на LLM:

1. pytesseract по-прежнему считывает текст из PDF-файла.
2. Вместо того чтобы указывать коду «Поиск номера заказа на покупку:», мы говорим магистру права: «Вот документ заказа. Извлеките для меня эти поля, независимо от того, как они названы».

Программа LLM понимает семантический контекст. Она признает, что «номер заказа» и «номер заказа на покупку» означают одно и то же, даже без явного правила.

Выполните скрипт 2 для подхода 2.

Теперь создадим новый файл с именем approach2_llm.py, содержащий следующий код, который вы можете найти в репозитории GitHub в той же папке:

https://gist.github.com/Sari95/d4e9e83490a9fbf34a3776d1604f8742

Теперь снова запустим файл в терминале. Убедитесь, что Ollama по-прежнему работает в фоновом режиме:

 python approach2_llm.py

Результат подхода 2

Теперь мы видим, что оба варианта оформления распознаны корректно:

Для обоих макетов информация из полей с разными именами корректно извлекается и присваивается, несмотря на то, что ни одно регулярное выражение не было скорректировано и новый шаблон не был создан. LLM понимает оба макета, поскольку считывает контекст. Кроме того, формат даты из макета B напрямую нормализуется, чтобы соответствовать формату из макета A.

2 – Прямое сравнение

После обоих тестов быстро становится ясно одно: технически оба подхода решают одну и ту же проблему.

Оба подхода имеют свои преимущества и недостатки:

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

3. В каких случаях НЕ следует использовать LLM?

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

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

В некоторых ситуациях традиционный подход может оказаться более подходящим вариантом:

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

   Почему?

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

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

2. Скорость и пропускная способность имеют решающее значение:
   В нашем примере LLM обрабатывает один документ за 20–40 секунд.

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

   В компании среднего размера, вероятно, обрабатывают заказы, накладные, счета-фактуры, таможенные документы, сопроводительные документы и т. д. И не 10 раз в день, а 10 000 раз в день.

   В этой ситуации время выполнения вычислений внезапно становится реальной проблемой инфраструктуры. Системы, основанные на регулярных выражениях, работают значительно быстрее, в то время как LLM-системы требуют больше оперативной памяти, большей мощности ЦП/ГП и часто дополнительных механизмов организации очередей или пакетной обработки.

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

   Регулярные выражения явно детерминированы: одна строка кода выдает один четко объяснимый результат. Модели с линейным обучением (LLM), напротив, работают вероятностно: модель интерпретирует контекст и возвращает наиболее вероятный результат. Именно это делает модели LLM гибкими, но в то же время и более сложными для проверки.

4. У компании отсутствует необходимая инфраструктура:
   В нашем примере мы использовали Ollama. Начало работы было в целом простым. Тем не менее, не следует недооценивать, что потребление памяти, ресурсы графического процессора, мониторинг или время отклика под нагрузкой могут выглядеть совершенно иначе при работе с LLM.

В своем блоге Substack Data Science Espresso я делюсь практическими руководствами и краткими новостями из мира науки о данных, Python, искусственного интеллекта, машинного обучения и технологий — для любознательных умов, таких как вы.

Ознакомьтесь с материалами и подпишитесь на обновления на Medium или Substack, если хотите быть в курсе событий.

4 – Заключительные мысли

Выбор правильного подхода — это не обязательно технический, а скорее стратегический вопрос.

Традиционный подход пытается явно описать каждый возможный документ. Подход, основанный на LLM, вместо этого стремится понять смысл и контекст. Для небольших и стабильных сред традиционный подход часто оказывается вполне достаточным. Чем больше вариантов компоновки и граничных случаев появляется, тем сложнее поддерживать правила в долгосрочной перспективе. Именно здесь LLM начинают представлять интерес.

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

Где можно продолжить обучение?

• Учебное пособие DataCamp – распознавание текста в Python с помощью Pytesseract
• Блог IBM – Что такое OCR?
• CoderPad – Полное руководство по регулярным выражениям (Regex)
• Ollama – Начать

Сара Шюрх. Все работы Сары Шюрх.

Источник: towardsdatascience.com