Прекратите использовать степень магистра права как инструмент для решения гигантских проблем.

Как я превратил 100 неряшливых PDF-файлов в структурированные выводы, построив детерминированный цикл вокруг агентов.

Делиться

Недавно я работал над проектом, в котором мне нужно было преобразовать 100 неряшливых PDF-файлов с требованиями к соответствию в структурированные правила в формате JSON.

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

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

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

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

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

Итак, приступим.

Проблема

Все 100 PDF-файлов, с которыми я работал, были уже проанализированы и разбиты на фрагменты до того, как попали ко мне. Но исходное содержимое всё ещё было неряшливым. Там были маркированные списки, таблицы, артефакты распознавания текста, переведённые разделы, полуструктурированные заголовки, нижние колонтитулы, верхние колонтитулы, непоследовательное форматирование и специфические особенности документа.

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

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

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

В итоге сработало то, что в итоге и сработало.

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

Это произошло благодаря изменению формы проблемы.

Вместо того чтобы пытаться сделать агента умнее, я упростил ему работу.

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

В моем случае это означало временное локальное хранение соответствующих исходных данных.

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

Другой вариант — подготовить запрос заранее.

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

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

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

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

Именно здесь стало более очевидным разделение обязанностей.

Агент выполнял семантическую работу: понимал содержимое, определял релевантные части и создавал JSON-вывод.

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

Также за ходом работы над сценарием следил аранжировщик.

Обеспечение возможности аудита результатов

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

Это упростило проверку результатов. Вместо вопроса: «Правильно ли выглядит сгенерированное правило?», я мог задавать более точные вопросы, например: существует ли указанный фрагмент исходного кода? Действительно ли цитируемый исходный текст присутствует в этом фрагменте?

Я также мог бы поручить другому агенту выборочно проводить аудит более крупных и сложных документов, чтобы убедиться в сохранении важных нюансов.

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

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

Если у вас есть идеи, как я мог бы сделать это лучше, дайте мне знать!

Мой главный вывод

Оказалось, что нужно перестать рассматривать LLM как целостную систему.

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

По стечению обстоятельств, я занимался этим незадолго до участия в первой конференции AI Engineer Singapore, которая проходила с 15 по 17 мая 2026 года.

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

Это меня зацепило, потому что в эту ловушку очень легко попасть. Легко просто передать модели данные, схему, бизнес-правила, граничные случаи и ответственность за самопроверку. А потом расстраиваться, когда результат оказывается противоречивым.

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

Я поделюсь еще несколькими впечатлениями от конференции AI Engineer Singapore и семинаров, которые я посетил. Фрагмент выступления Джей-Джея на YouTube можно посмотреть здесь.

На этом всё. Надеюсь, это вам помогло, и до встречи в следующей статье 🙂

Клара Чонг. Все работы Клары Чонг.

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