Парсер PDF заглох на полутора тысячах документов

Логистическая компания присылала PDF-инвойсы через Telegram. Нужно было вытащить поля (сумма, дата, адрес, номер маршрута) и загнать в Excel. Воркфлоу n8n: скачать, regex по PDF-тексту, обработать. Первые 500 документов прошли чисто. На 1500-м парсер начал выдавать мусор: номера из шапок, даты из подписей, адреса из примечаний вместо реальных адресов доставки.

Корень был двойной. Во-первых, PDF-строк не существует: это раскладка пиксельных прямоугольников, и один многострочный блок мог читаться как три отдельные строки с переносами. Regex ловил первое совпадение, не уточняя контекст. Во-вторых, макеты инвойсов оказались неодинаковыми: старые версии от одного поставщика, новые от другого. Один и тот же regex на обоих не работал.

Решение: инвентаризировал шаблоны (5 основных макетов), написал для каждого свой regex с уточнением контекста (не просто дата, а дата в строке с меткой типа "Дата отправки:"). Добавил Vision-проверку (Claude видит скан целиком) как фазу валидации: если парсер вытащил число, а Vision говорит "это не сумма в этом месте", строку помечаю в ручной очереди. Параллельно устранил конфликты bash-выражений в n8n: переменные $VAR конфликтовали с ${field}, перешел на явный синтаксис.

На второй прогон 1500 документов ушло чисто. Вручную дошло 14 (скос при печати или вообще не PDF), остальные 98.5% прошли с первого раза. Урок: макеты документов редко бывают одинаковыми, парсер без контекста ловит мусор, Vision тут не костыль, а надежный арбитр.

#n8n #парсинг #PDF #логистика #автоматизация #LLM #документы #OCR