Пошаговые инструкции intermediate 13 мин

Как сделать ИИ-агента для документов: PDF, OCR, таблицы и RAG

Пошаговая инструкция по AI-агенту для документов: парсинг PDF, OCR, таблицы, metadata, chunking, RAG, источники, structured extraction и human review.

RAG AI-агенты Инструкция документы PDF OCR structured extraction

ИИ-агент для документов кажется простым: загрузили PDF, спросили вопрос, получили ответ. На практике самые частые ошибки появляются раньше модели: PDF плохо распарсился, таблица превратилась в кашу, OCR перепутал символы, страницы потеряли порядок, а RAG нашел не тот фрагмент. Поэтому документного агента нужно строить как pipeline: загрузка, парсинг, очистка, chunking, metadata, retrieval, ответ или structured extraction.

Короткая версия: определите тип документов, выберите parser, проверьте OCR и таблицы, сохраните metadata, сделайте RAG-индекс, возвращайте источники и отдельно тестируйте извлечение данных по схеме.

Что мы собираем

Соберем схему ИИ-агента, который умеет работать с PDF, DOCX, таблицами, сканами, инструкциями, договорами и базой документов.

  • Загружает файлы.
  • Распознает тип документа.
  • Извлекает текст, таблицы и metadata.
  • Делит документ на фрагменты.
  • Индексирует документы для RAG.
  • Отвечает с источниками.
  • Извлекает структурированные поля.
  • Отдает сомнительные случаи человеку.

Шаг 1. Разделите сценарии

Не смешивайте “чат по документам” и “извлечение полей” в одну мутную задачу. Это разные режимы.

  • Document Q&A: пользователь задает вопрос, агент отвечает по документам.
  • Summarization: агент делает краткое резюме документа.
  • Structured extraction: агент извлекает номер договора, дату, сумму, стороны, сроки.
  • Comparison: агент сравнивает две версии документа.
  • Compliance check: агент проверяет документ по списку правил.
  • Routing: агент определяет тип документа и отправляет в нужный workflow.

У каждого режима должны быть свои критерии качества и формат ответа.

Шаг 2. Определите типы документов

Качество pipeline зависит от документов. Обычный текстовый PDF, скан договора и Excel-таблица требуют разных подходов.

  • Текстовый PDF: чаще можно извлечь текст без OCR.
  • Скан PDF: нужен OCR.
  • PDF с таблицами: нужен parser, который сохраняет структуру.
  • DOCX: обычно легче, чем PDF.
  • XLSX/CSV: лучше обрабатывать как таблицы, а не как обычный текст.
  • Фото документа: нужен OCR и контроль качества распознавания.

Сделайте тестовую папку из 20-30 реальных файлов, а не только идеальные примеры.

Шаг 3. Выберите parser

Parser превращает файл в структурированный текст. Это один из самых важных компонентов документного агента.

  • LlamaIndex удобен для ingestion, документов, индексов и RAG.
  • Unstructured хорошо подходит для partitioning разных типов файлов.
  • Docling полезен для сложных PDF, layout, таблиц, OCR и структурированного представления.
  • Tesseract OCR можно использовать для базового распознавания сканов.
  • Для простых DOCX и TXT иногда достаточно стандартных библиотек.

Не существует одного parser, который идеально разбирает все документы. Для production часто делают несколько стратегий по типу файла.

Шаг 4. Проверьте качество извлечения

Перед RAG посмотрите, какой текст реально получился после парсинга. Если текст плохой, модель будет отвечать плохо.

Проверьте:

  • сохранился ли порядок чтения;
  • не исчезли ли заголовки;
  • таблицы не превратились ли в нечитаемую строку;
  • страницы не перемешались;
  • OCR не заменил цифры и буквы;
  • колонтитулы и номера страниц не стали отдельными “важными” фрагментами;
  • подписи, сноски и приложения не потерялись.

Сделайте ручной просмотр 5-10 сложных документов. Это быстро покажет слабое место pipeline.

Шаг 5. Сохраните metadata

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

{
  "doc_id": "contract_2026_001",
  "title": "Договор поставки №1",
  "source_path": "/docs/contracts/contract_001.pdf",
  "page": 7,
  "section": "Ответственность сторон",
  "document_type": "contract",
  "updated_at": "2026-05-22",
  "access_level": "internal"
}

Без metadata агент не сможет нормально объяснить, откуда взял ответ, и не сможет фильтровать документы по правам.

Шаг 6. Настройте chunking

Chunking для документов сложнее, чем “каждые 800 токенов”. В договорах важны разделы, в инструкциях - шаги, в таблицах - строки и заголовки.

  • Делите по заголовкам и смысловым блокам.
  • Сохраняйте page number и section.
  • Не отрывайте таблицу от ее заголовка.
  • Добавляйте overlap для длинных абзацев.
  • Для таблиц храните строку вместе с названиями колонок.
  • Для договоров сохраняйте номер пункта.

Плохой chunking делает даже хороший parser бесполезным для RAG.

Шаг 7. Сделайте RAG-индекс

После парсинга и chunking можно создать embeddings и сохранить фрагменты в vector database.

documents = parse_documents("docs/")
chunks = split_documents(documents)
vectors = embedding_model.embed([chunk.text for chunk in chunks])
vector_store.upsert(chunks, vectors, metadata=True)

Для маленького прототипа подойдет локальный индекс или Chroma. Для production чаще выбирают Qdrant, Pinecone, Weaviate или другой vector store с metadata filters.

Шаг 8. Отвечайте с источниками

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

Формат ответа:

Короткий ответ: ...

Основание:
- Договор поставки №1, стр. 7, раздел "Ответственность сторон"
- Приложение 2, стр. 3, таблица тарифов

Если источника нет, агент должен сказать, что не нашел подтверждения, а не “догадаться”.

Шаг 9. Настройте structured extraction

Если агент должен извлекать поля из документа, задайте схему. Не просите “найди все важное”.

{
  "document_type": "contract",
  "contract_number": "string|null",
  "signed_at": "date|null",
  "party_a": "string|null",
  "party_b": "string|null",
  "amount": "number|null",
  "currency": "string|null",
  "needs_review": "boolean",
  "review_reason": "string|null"
}

Если поле не найдено, пусть модель возвращает null, а не придумывает. Для важных документов добавьте confidence и страницу, где найдено поле.

Шаг 10. Добавьте OCR-проверки

Сканированные документы требуют отдельного контроля. OCR может ошибаться в цифрах, датах, фамилиях и реквизитах.

  • Для критичных чисел показывайте страницу-источник.
  • Сравнивайте распознанные суммы с шаблоном.
  • Низкое качество OCR отправляйте человеку.
  • Не принимайте автоматически реквизиты, суммы и даты без проверки.
  • Сохраняйте ссылку на оригинальную страницу или изображение.

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

Шаг 11. Добавьте human review

Документный агент не должен автоматически принимать важные решения по сомнительным данным.

Отправляйте человеку, если:

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

Хороший агент ускоряет проверку, но не притворяется юристом или бухгалтером.

Шаг 12. Тестируйте на сложных документах

Тесты должны включать не только чистые PDF.

  • Скан с плохим качеством.
  • Договор с приложениями.
  • Таблица на несколько страниц.
  • PDF с двумя колонками.
  • Документ с печатями и подписями.
  • DOCX с комментариями.
  • XLSX с несколькими листами.
  • Две версии одного договора.

Отдельно проверяйте: retrieval, page citation, extraction schema, OCR errors, table parsing и handoff.

Мини-чеклист

  • Сценарий выбран: Q&A, summary, extraction, comparison или compliance.
  • Типы документов описаны.
  • Parser выбран под реальные файлы.
  • OCR и таблицы проверены вручную.
  • Metadata сохраняет doc_id, page, section, access_level.
  • Chunking учитывает разделы, таблицы и номера пунктов.
  • RAG возвращает источники.
  • Structured extraction работает по схеме.
  • Критичные поля требуют confidence и source page.
  • Сомнительные случаи уходят на human review.

Частые вопросы

Можно ли просто загрузить PDF в модель?

Для небольшого разового документа можно. Но для production нужен pipeline: parser, metadata, chunking, RAG, источники и обновление индекса. Иначе ответы сложно проверять и поддерживать.

Что важнее: модель или parser?

Для документов parser часто важнее. Если текст, таблицы и порядок страниц извлечены плохо, сильная модель все равно будет отвечать по плохому контексту.

Как работать с таблицами в PDF?

Не превращайте таблицы в обычный абзац без колонок. Сохраняйте заголовки колонок, строки, страницу и название таблицы. Для сложных таблиц лучше использовать parser с поддержкой layout/table extraction.

Нужен ли OCR для каждого PDF?

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

Можно ли доверять извлеченным данным автоматически?

Для низкорисковых задач - иногда. Для договоров, счетов, реквизитов, сумм, дат и юридически значимых данных лучше добавлять confidence, источники и human review.

Дальше по теме

Похожие материалы