Unstructured преобразует PDF, сканы, офисные документы и письма в структурированный JSON: распознаёт заголовки, таблицы, изображения и связный текст, разбивает результат на смысловые фрагменты, добавляет описания и векторные представления, а затем передаёт подготовленные данные в файловое хранилище, базу или RAG-систему.

Работа начинается с панели Start или конструктора Workflows. Для быстрой проверки достаточно перетащить файл в область тестирования, выбрать способ обработки и запустить разбор. На экране одновременно видны исходная страница и результат: слева можно проверить порядок чтения и расположение блоков, справа — раскрыть JSON, найти конкретный элемент и сохранить полный ответ. Когда пробный прогон устраивает, ту же конфигурацию переносят в рабочий процесс с источником, узлами преобразования и назначением.

Основной рабочий процесс строится как ориентированный граф. Источник передаёт документы в Partitioner, затем при необходимости подключаются Enrichment, Chunker и Embedder, после чего данные отправляются в выбранное назначение. Каждый узел открывает собственную панель параметров; граф можно масштабировать, центрировать, дополнять через Add Node и проверять до запуска задания. Такой порядок позволяет отдельно подобрать точность разбора, размер фрагментов и формат итоговых данных, не смешивая эти решения в одной непрозрачной настройке.

Как устроено рабочее пространство

Навигация разделяет разовые проверки и производственные процессы. В Start удобно взять один документ, увидеть результат и получить пример вызова API. В Connectors создаются подключения к источникам и назначениям. Workflows содержит схемы обработки, Jobs показывает выполненные и запущенные задания, а API Keys предназначен для ключей, которыми пользуются скрипты и интеграции. Такое деление важно на практике: тестирование качества не требует предварительно настраивать хранилище, а готовую схему можно запускать повторно без ручной загрузки каждого файла.

В конструкторе схема читается слева направо. Source определяет, откуда поступают документы. Partitioner извлекает элементы и формирует базовый JSON. Enrichment добавляет содержательное описание изображений, таблиц или сущностей. Chunker группирует элементы в фрагменты подходящего размера. Embedder создаёт числовые векторы. Destination записывает результат. Обязательными для минимальной схемы остаются источник, разбор и назначение; остальные узлы нужны только тогда, когда их данные действительно использует следующая система.

У выбранного узла справа открывается панель Details. В ней находятся переключатели, списки моделей, числовые ограничения и подсказки по совместимости. Вкладка FAQ объясняет назначение параметров, а элементы управления над графом помогают отменить действие, вернуть его, изменить масштаб и снова поместить схему в центр. Полезная привычка — давать коннекторам и рабочим процессам имена по назначению, например договоры-из-sharepoint-в-postgresql, а не оставлять несколько объектов с одинаковыми общими именами.

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

Проверка одного файла перед созданием потока

Разовый тест экономит время, когда неизвестно, какая стратегия справится с конкретным макетом. В области загрузки выбирают PDF, изображение, презентацию, таблицу, письмо или другой поддерживаемый тип. После запуска рядом с просмотром появляется результат. Для PDF можно переходить между страницами и сопоставлять видимый блок с соответствующим объектом JSON. Если в документе две колонки, таблица и примечания, проверяют не только наличие текста, но и порядок элементов: неверная последовательность ухудшит ответы RAG даже при безошибочном OCR.

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

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

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

Стратегии разбиения документа

Partitioner определяет, как исходный файл превращается в элементы. В панели можно выбрать Auto, Fast, High Res или VLM. Эти режимы различаются не декоративным уровнем качества, а способом анализа. Fast ориентирован на документы с доступным текстовым слоем и простым порядком чтения. High Res использует анализ макета и полезен для таблиц, изображений и сложного расположения блоков. VLM обращается к визуально-языковой модели и помогает там, где смысл зависит от общей композиции страницы. Auto выбирает подход автоматически, что удобно для смешанной коллекции.

Когда подходит Auto

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

Когда достаточно Fast

Fast полезен для born-digital PDF с корректным текстовым слоем, простых DOCX, HTML и материалов без сложной геометрии. Его преимущество проявляется в больших архивах, где подавляющее большинство страниц состоит из последовательных абзацев. На таком наборе тяжёлая визуальная обработка добавляет задержку, но почти не улучшает данные. Перед массовым запуском проверяют многостолбцовые страницы, колонтитулы и списки: если строки смешиваются, переходят на более точный режим для этой категории документов.

Когда нужен High Res

High Res выбирают для сканов, таблиц, анкет, многостолбцовых отчётов, презентационных слайдов и страниц, где важны координаты объектов. Режим распознаёт области макета и связывает текст с их положением. Это помогает отделить заголовок от основного текста, сохранить таблицу как отдельный элемент и не смешать подпись к рисунку с соседним абзацем. Практическая плата — большее время обработки и зависимость качества от разрешения исходной страницы.

Когда оправдан VLM

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

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

Из чего состоит результат JSON

После partition документ представлен последовательностью элементов. Среди типичных типов встречаются Title, NarrativeText, ListItem, Table, Image и UncategorizedText. Title обозначает заголовок или структурный рубеж, NarrativeText — связный абзац, ListItem — пункт списка, Table — таблицу, Image — изображение или выделенную визуальную область. UncategorizedText появляется, когда блок содержит текст, но его роль нельзя надёжно определить. Типы помогают строить фильтры и сохранять структуру при chunking.

Каждый элемент получает element_id. Идентификатор нужен не только для уникальности: по нему удобно связывать фрагмент с исходным объектом, проводить повторную индексацию и отслеживать, какие элементы вошли в chunk. В metadata могут находиться имя файла, тип файла, номер страницы, координаты, язык, сведения о родительском элементе и специальные поля конкретного формата. Состав метаданных зависит от источника и выбранной обработки, поэтому downstream-код не должен считать все поля обязательными.

Координаты особенно полезны при выдаче ответа с визуальной проверкой. По номеру страницы и bounding box приложение может подсветить область, откуда пришёл текст. Но координатная система требует согласованности: ширина, высота и начало отсчёта должны интерпретироваться так же, как в исходном документе. Если интерфейс отображает страницы после масштабирования, координаты переводят пропорционально, а не применяют как готовые пиксели экрана.

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

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

Таблицы, изображения и обогащение

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

Table Description создаёт смысловое описание таблицы. Оно полезно для первичного поиска: запрос динамика расходов по кварталам может найти таблицу по описанию, даже если точные слова запроса отсутствуют в ячейках. При этом описание не заменяет исходные данные. В индекс разумно положить и краткое описание, и структурированную таблицу, а в ответе показывать значения из ячеек. Это снижает риск, что сгенерированное резюме будет принято за первичный источник.

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

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

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

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

Разбиение на фрагменты для поиска и RAG

После извлечения элементов документ часто слишком велик для одного запроса к модели и слишком неоднороден для точного поиска. Chunker собирает элементы в фрагменты. В Unstructured доступны стратегии by Character, by Title, by Page и by Similarity. Они отвечают на разные вопросы: какой максимальный размер допустим, нужно ли сохранять разделы, важна ли граница страницы и можно ли объединять близкие по смыслу части.

Chunk by Title

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

Chunk by Character

Стратегия по числу символов предсказуема и удобна для ровного текста. Max Characters задаёт жёсткий предел, New After N Characters позволяет начать новый фрагмент раньше, если достигнута разумная длина. Значения подбирают с учётом токенизации выбранной модели: символы и токены не совпадают один к одному. Русский текст, таблицы, код и длинные идентификаторы дают разное отношение, поэтому окончательный размер проверяют токенизатором downstream-модели.

Chunk by Page

Разбиение по страницам сохраняет естественную ссылку на лист и удобно для документов, где каждая страница является отдельной формой, слайдом или записью. Для непрерывного договора граница страницы может разрезать предложение и отделить заголовок от абзаца. В таких случаях помогает Contextual Chunking: к фрагменту добавляется контекст, который объясняет его место в документе. Контекст улучшает поиск, но увеличивает объём индекса, поэтому его оценивают на реальных запросах.

Chunk by Similarity

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

Include Original Elements сохраняет исходные элементы внутри chunk. Это полезно для трассировки и повторного отображения, но увеличивает JSON. Overlap добавляет часть предыдущего текста в следующий фрагмент, а Overlap All распространяет перекрытие шире. Перекрытие помогает запросам, попавшим на границу, однако создаёт дубли в выдаче. Поисковая система должна уметь группировать соседние совпадения, иначе пользователь увидит несколько почти одинаковых результатов.

Multipage Sections определяет, может ли один раздел переходить через страницу. Для книг и договоров это обычно полезно; для анкет и счетов страницы лучше держать отдельно. Правильная настройка видна по ответам: если модель постоянно теряет продолжение абзаца, границы слишком жёсткие; если один фрагмент содержит несколько независимых тем, размер или порог объединения слишком велики. Оптимизацию проводят по набору вопросов, а не только по средней длине chunk.

Векторные представления и совместимость индекса

Embedder превращает текстовые фрагменты в векторы. В узле выбирают поставщика, модель и размерность, если модель позволяет её задавать. Эти параметры должны точно совпадать с настройкой векторного хранилища и последующим кодом запросов. Вектор, созданный одной моделью, нельзя сравнивать с запросом, обработанным другой моделью: числа будут иметь одинаковый вид, но находиться в несовместимых пространствах.

Размерность влияет на структуру индекса и объём хранения. Если база создана для 1536 измерений, запись вектора другой длины завершится ошибкой или потребует отдельного поля. При смене модели безопаснее создать новый индекс и переобработать данные, а не смешивать старые и новые записи. В metadata сохраняют имя модели и ревизию конфигурации рабочего процесса, чтобы происхождение вектора можно было установить после нескольких месяцев эксплуатации.

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

Часть назначений принимает готовые vectors, часть ожидает текст и создаёт их самостоятельно. Нельзя одновременно встроить фрагмент в Unstructured и затем незаметно повторить embedding другой моделью на стороне базы. Такой поток либо хранит лишние данные, либо приводит к расхождению между вектором и поисковым запросом. Перед подключением Destination определяют, где именно находится единственная ответственная точка создания вектора.

Для гибридного поиска сохраняют и текст chunk, и embedding, и фильтруемые метаданные. Вектор отвечает за смысловую близость, полнотекстовый индекс — за точные названия, коды и номера, metadata — за ограничения по дате, типу документа, проекту или уровню доступа. Unstructured подготавливает эти слои, но стратегию ранжирования задаёт поисковая система. Хороший JSON сам по себе не гарантирует качественную выдачу без настройки индекса.

Извлечение данных по заданной схеме

Структурированное извлечение применяется, когда нужен не набор абзацев, а определённые поля: стороны договора, дата, сумма, номер счёта, список позиций или реквизиты. Схему задают в JSON Schema. Имена полей должны быть понятными, типы — строгими, а описания — объяснять значение. Поле date без уточнения может означать дату документа, оплаты или поставки; описание устраняет эту неоднозначность.

Результат появляется в области extracted_data или соответствующей структуре ответа. Его валидируют тем же JSON Schema и отдельно проверяют бизнес-правила. Сумма должна быть неотрицательной, валюта — из допустимого списка, дата окончания — не раньше даты начала, а обязательный идентификатор — соответствовать формату. Модель может вернуть синтаксически корректное, но содержательно неверное значение, поэтому схема является первым фильтром, а не полной гарантией.

Для таблиц полезно описывать массив объектов. Например, invoice_items содержит name, quantity, unit_price и total. Важно решить, как обрабатывать объединённые строки, скидки и налоги. Если итоговая сумма находится отдельно от позиций, её не следует насильно добавлять как ещё один товар. На контрольных документах сравнивают сумму массива и итог счёта, но допускают различие на налог или округление только по явно заданному правилу.

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

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

Поддерживаемые документы и особенности форматов

Unstructured принимает PDF, изображения, офисные документы, электронные письма, электронные книги, HTML, разметку и табличные файлы. В перечне встречаются DOC и DOCX, PPT и PPTX, XLS и XLSX, ODT, RTF, EPUB, EML, MSG, HTML, XML, Markdown, CSV, TSV, PNG, JPEG, TIFF, HEIC и другие расширения. Поддержка расширения означает возможность запустить обработку, но не одинаковую глубину анализа: у таблицы, письма и скана различаются элементы и метаданные.

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

DOCX и HTML обычно сохраняют логическую структуру лучше, потому что заголовки, списки и таблицы заданы явно. Но в документах, созданных визуальным позиционированием, порядок может быть неожиданным. PPTX следует оценивать по слайдам: текстовые блоки, заметки и изображения несут разный смысл. XLSX требует решения, какие листы, диапазоны и пустые строки считать данными. Один универсальный chunking для всех форматов редко даёт лучший результат.

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

CSV и TSV чувствительны к разделителю, кодировке и окончаниям строк. Для DIF с определённым вариантом перевода строк документация отмечает возможность ошибки неподдерживаемого формата. Практическое решение — предварительно нормализовать файл, сохранить его в UTF-8 и проверить разделитель. Бинарные офисные форматы могут требовать преобразования, поэтому тест на реальном архиве важнее предположения по одному расширению.

HEIC и многостраничный TIFF требуют проверки ориентации и страниц. Снимок с телефона может содержать EXIF-поворот, который визуально учитывает просмотрщик, но не каждый обработчик. Перед OCR изображение приводят к правильной ориентации, достаточному разрешению и контрасту. Слишком сильное сжатие JPEG создаёт артефакты вокруг букв, а низкое разрешение делает мелкий текст неразличимым независимо от выбранной модели.

Источники данных и создание коннектора

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

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

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

Повторная синхронизация обычно обрабатывает новые и изменённые объекты. Переименование в объектном хранилище может восприниматься как новый файл, потому что ключ объекта изменился. Чтобы не получить две записи, downstream-система должна иметь стратегию идентификации: хранить исходный путь, checksum, стабильный документный ID или комбинацию признаков. Одна только строка filename ненадёжна.

Amazon S3 и совместимые хранилища

Для S3 задаются bucket, ключ и секрет, а при необходимости token и собственный endpoint. Custom endpoint позволяет работать с S3-совместимым хранилищем, но сертификат, регион и схема подписи должны соответствовать серверу. Anonymous применяют только для публичных объектов. При ошибке доступа сначала проверяют политику bucket и права на перечисление объектов, затем — путь и регион; неверный секрет является лишь одной из возможных причин.

Azure Blob Storage

Для Azure Blob указывают адрес контейнера и способ авторизации: имя учётной записи с ключом, connection string или SAS token. Не следует заполнять несколько конфликтующих способов одновременно без необходимости. SAS ограничивают контейнером, разрешениями и сроком действия. Если тест проходил, а позже задания начали получать отказ, проверяют истечение token и сетевые ограничения хранилища.

Google Drive и корпоративные каталоги

Google Drive требует Drive ID и сервисный ключ с доступом к выбранной области. Общий диск и личная папка имеют разные идентификаторы и модель прав. Фильтр расширений помогает не забирать служебные файлы. Аналогичный принцип действует для SharePoint, OneDrive, Box, Confluence и других систем: сначала предоставляют минимальный доступ, затем тестируют одну папку и только после проверки расширяют охват.

Назначения и запись результата

Destination определяет, где окажутся элементы или chunks. Это может быть объектное хранилище, поисковый движок, реляционная база, документная база или векторное хранилище. Выбор зависит от следующего действия. JSON для архивной обработки удобно положить в bucket. Для полнотекстового поиска подходит индекс. Для RAG нужны текст, metadata и, как правило, embedding. Для аналитики извлечённых полей лучше таблица с явной схемой.

Перед подключением проверяют модель данных назначения. Векторная база требует имя коллекции или индекса, размерность и поле идентификатора. PostgreSQL — таблицу, типы столбцов и стратегию upsert. Elasticsearch — mapping полей и анализаторы. Объектное хранилище — формат имени файла и правила перезаписи. Если оставить эти решения неявными, первый прогон может пройти, а повторный создать дубли.

Для Pinecone и других векторных систем задают индекс, окружение или адрес, размер пакета и API key. Batch Size влияет на скорость и вероятность ошибки: слишком маленькие пакеты увеличивают число запросов, слишком большие могут превысить лимит или тайм-аут. Начинают с умеренного значения и смотрят журнал. При повторных ошибках уменьшают пакет, проверяют размер записи и квоты назначения.

Идентификатор записи должен быть детерминированным. Хороший вариант строится из стабильного ID документа, element_id или номера chunk и ревизии обработки. Случайный UUID при каждом запуске не позволяет обновить старую запись и ведёт к дублированию. Если содержимое изменилось, workflow должен либо обновить запись, либо удалить прежние chunks документа перед вставкой нового набора.

Поля доступа к источнику и назначению не должны совпадать без причины. Компрометация одного ключа не должна открывать обе стороны потока. Для тестовой и рабочей среды создают разные коннекторы, индексы и секреты. Названия вроде prod-search-readwrite и test-s3-readonly помогают избежать запуска теста в рабочее хранилище, но секретные значения остаются только в защищённых полях.

Создание рабочего процесса

Новый Workflow удобнее строить от минимального пути: Source, Partitioner, Destination. После успешного теста добавляют Chunker, затем Embedder и только потом обогащения. Такой порядок облегчает диагностику. Если сразу включить шесть узлов, по одной общей ошибке трудно понять, не распознался ли файл, не прошла ли модель или отказала база.

На вкладке Details задают имя и описание. Schedule определяет запуск по времени, Settings — параметры выполнения, FAQ — подсказки. Расписание полезно для регулярно обновляемого источника, но частота должна соответствовать реальной скорости изменения. Ежечасный обход архива, который меняется раз в неделю, создаёт лишние проверки. Для срочных данных, напротив, суточный запуск будет слишком редким.

Перед сохранением проверяют направление связей. Chunker должен стоять после Partitioner или enrichment, Embedder — после текста, Destination — в конце соответствующего маршрута. Если доступно несколько назначений, определяют, нужен ли одинаковый результат каждому. Архивный JSON может хранить исходные элементы, а векторная база — только chunks; в таком случае полезны отдельные маршруты или процессы с ясными контрактами данных.

Названия рабочих процессов включают источник, назначение и цель, но не секреты. Например, policies-sharepoint-rag яснее, чем workflow-7. Описание фиксирует стратегию, схему и ответственного за процесс. Это помогает при смене команды: по одному графу не всегда понятно, почему выбран конкретный порог similarity или почему отключено описание изображений.

После изменения узла проводят тест на том же контрольном наборе. Незначительное изменение Max Characters может повлиять на все IDs chunks и вызвать полную переиндексацию. Смена модели embedding требует нового индекса. Добавление enrichment увеличивает объём результата. Конфигурацию рассматривают как код: изменения документируют, проверяют и вводят поэтапно.

Запуск задания и чтение журнала

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

Разовый запуск позволяет выбрать процесс и параметры без ожидания расписания. Это удобно после исправления коннектора или на тестовой папке. Reprocess All используют осознанно: он заставляет заново обработать уже известные документы и способен резко увеличить объём работы. Для изменения только одного документа лучше ограничить источник или применить точечный механизм, если он доступен в выбранной конфигурации.

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

Для массового набора полезно отделять ошибку одного файла от отказа всего процесса. Повреждённый PDF, неверная кодировка CSV или защищённый документ не должны скрывать успешную обработку остальных. В журнале фиксируют имя и ID проблемного объекта, затем помещают его в карантин для отдельного анализа. Бесконечные автоматические повторы одного и того же повреждённого файла расходуют ресурсы и засоряют журнал.

Длительность сравнивают с числом страниц, размером файлов и выбранными моделями. Рост времени может быть нормальным после включения VLM или enrichments. Если конфигурация не менялась, ищут новые типы документов, увеличение разрешения сканов, снижение лимита внешнего API или медленную запись в назначение. Метрика секунд на страницу информативнее общего времени задания, когда объём источника меняется.

Использование API и воспроизводимых настроек

После удачного теста интерфейс помогает получить пример вызова, включая команду curl или код SDK. Копировать пример следует вместе с параметрами, которые реально проверены. Затем секрет выносят в переменную окружения или менеджер секретов, путь к файлу делают параметром, а ответ сохраняют потоково, если документы крупные. Жёстко записанный API key в скрипте или ноутбуке легко попадает в репозиторий.

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

Параметры запроса фиксируют рядом с результатом: стратегию, модель, chunking, enrichments и дату выполнения. Это превращает JSON в воспроизводимый артефакт. Без конфигурации невозможно объяснить, почему два одинаковых файла дали разные chunks. В рабочем процессе достаточно хранить ID и ревизию схемы; в исследовательском тесте полезен полный снимок параметров.

Большие ответы не следует целиком писать в обычный application log. Они увеличивают стоимость журналирования и могут содержать конфиденциальный текст. В лог помещают request ID, размер, число элементов, длительность и статус. Содержимое сохраняют в предназначенном хранилище с контролем доступа. Для диагностики достаточно небольшой обезличенной выборки или hash.

API и интерфейс должны использовать один контракт данных. Если пользователь протестировал VLM и chunk by Title, а скрипт отправляет параметры по умолчанию, производственный результат не соответствует проверенному. Хорошая практика — экспортировать или централизованно хранить конфигурацию и автоматически сравнивать её с ожидаемой перед запуском.

Практический сценарий: база знаний для RAG

Для корпоративной базы знаний сначала выбирают источник с политиками, инструкциями и регламентами. Partitioner должен сохранить заголовки и списки; для чистых офисных документов достаточно экономичной обработки, а сканы отправляют в более точный маршрут. Chunk by Title удерживает разделы, Max Characters не даёт им стать слишком большими, Include Original Elements сохраняет трассировку. Затем добавляется embedding и запись в векторную базу.

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

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

Если поиск возвращает правильный документ, но не тот абзац, уменьшают chunk или меняют стратегию. Если нужный абзац отсутствует в JSON, исправляют partition. Если фрагмент есть, но не находится по синониму, проверяют embedding. Если находится, но ответ неверен, проблема лежит в prompt, reranker или генеративной модели. Разделение этапов не позволяет бесконечно менять один компонент в надежде исправить всю систему.

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

Практический сценарий: договоры и извлечение полей

Договор сначала разбирают с сохранением заголовков, нумерованных пунктов и страниц. Для сканов проверяют печати, подписи и мелкий текст приложений. Chunk by Title полезен для поиска положений, а JSON Schema — для реквизитов: стороны, дата, срок, сумма, валюта, применимое право и условия расторжения. Эти два результата решают разные задачи и не должны подменять друг друга.

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

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

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

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

Практический сценарий: научные статьи и отчёты

Научная статья сочетает две колонки, формулы, рисунки, подписи, таблицы и список литературы. Для такого PDF важен порядок чтения. В тестовом просмотре проверяют, что текст первой колонки не перемешан со второй, подпись следует за рисунком, а сноски не вставлены в середину предложения. High Res или VLM сравнивают на нескольких страницах с разным макетом.

Заголовки разделов позволяют chunk by Title, но Abstract, References и подписи к рисункам лучше отмечать отдельно. Список литературы часто создаёт много совпадений по фамилиям и терминам, поэтому его можно индексировать в отдельном поле или с меньшим весом. Формулы хранят вместе с окружающим объяснением; один изолированный символический блок редко отвечает на пользовательский вопрос.

Table Description и Image Description облегчают поиск графиков. В metadata добавляют номер рисунка или таблицы, если он извлечён, и страницу. Пользовательский интерфейс должен открыть исходную страницу, потому что автоматически созданное описание может не передать точное значение точки на графике. Для числового анализа предпочтительнее структурированная таблица или исходные данные.

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

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

Практический сценарий: архив сканов

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

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

High Res и Generative OCR сравнивают на трудных листах. Метрика символов дополняется проверкой ключевых полей, дат, имён и таблиц. Для архивного поиска допустима небольшая ошибка в обычном слове, но ошибка в номере дела делает документ невидимым по основному запросу. Поэтому критичные шаблоны проверяют регулярными выражениями и справочниками.

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

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

Контроль качества результата

Качество нельзя свести к одному проценту распознавания. Для Unstructured полезны четыре группы метрик: полнота элементов, правильность порядка чтения, качество структуры и пригодность downstream-задаче. Документ может иметь почти весь текст, но неверно смешанные колонки. Таблица может содержать все числа, но потерять связь с заголовками. RAG может найти нужный chunk, но без страницы и источника он непригоден для проверки.

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

Для таблиц измеряют совпадение числа строк и столбцов, сохранение merged cells и точность критичных значений. Для списков — число пунктов и вложенность. Для заголовков — precision и recall классификации Title. Для chunking — долю вопросов, где нужный ответ целиком находится в одном или нескольких соседних фрагментах. Для embeddings — recall@k на наборе запросов.

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

Случайную выборку из рабочего потока проверяют регулярно. Источники меняются: появляется новый шаблон счёта, другой сканер, обновлённая форма или презентация с необычным шрифтом. Даже неизменная конфигурация может начать давать другой профиль ошибок из-за входных данных. Мониторинг должен замечать рост пустых элементов, ошибок, времени и среднего размера JSON.

Безопасность, доступ и чувствительные данные

Документный конвейер имеет доступ одновременно к исходникам и системам назначения, поэтому принцип минимальных прав особенно важен. Source получает только чтение нужной области. Destination — только запись или upsert в конкретный индекс. Административные ключи не используются для обычного задания. Для разных сред и подразделений создают отдельные учётные данные.

Секреты хранят в предназначенных полях и менеджере секретов. Их не вставляют в JSON Schema, описание workflow, имя файла, запрос curl в истории терминала или снимок экрана. Если ключ попал в журнал или репозиторий, его отзывают и заменяют, а не только удаляют строку. История могла сохраниться в кэше и резервных копиях.

Результат обработки может быть не менее чувствительным, чем документ. Текст, таблицы, сущности и embeddings способны раскрывать содержание. Доступ к bucket с JSON или векторному индексу ограничивают так же строго, как доступ к PDF. Обезличивание выполняют до передачи в менее защищённую среду; удаление имени файла не скрывает персональные данные внутри текста.

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

Срок хранения определяют для исходников, промежуточного JSON, логов, embeddings и резервных копий. Удаление одного PDF из источника не обязательно автоматически удаляет его из всех назначений. Workflow должен поддерживаться процедурой удаления: найти записи по стабильному ID, удалить chunks, векторы и кэш, затем зафиксировать выполнение. Это особенно важно для персональных данных и документов с ограниченным сроком.

Производительность и управление расходами

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

Начинают с пилота. Измеряют страницы в минуту, долю ошибок, размер JSON и объём векторов. Затем оценивают параллелизм источника и лимиты внешних провайдеров. Увеличение числа одновременных заданий ускоряет работу только до первого узкого места; после него растут тайм-ауты и повторы. Журнал показывает, где находится задержка: чтение, model inference или запись.

Auto и Fast используют для простых документов, более дорогие режимы — для классов, где они дают измеримый выигрыш. В смешанном архиве полезна маршрутизация: электронные PDF идут по экономичному пути, сканы и сложные таблицы — по точному. Если маршрутизация не автоматизирована, создают отдельные папки или workflows и фиксируют правило распределения.

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

Повторная обработка должна быть контролируемой. Изменение одного поля metadata не всегда требует заново запускать VLM на всех страницах. Архитектура может сохранить базовый JSON и повторить только chunking или embedding. Если workflow выполняет этапы как единый процесс, перед массовым reprocess оценивают стоимость и создают новый индекс для безопасного переключения.

Batch Size назначения подбирают экспериментально. Большие пакеты уменьшают накладные расходы, но повышают размер запроса и цену повтора. Маленькие проще повторить, но они создают много сетевых операций. Оптимум зависит от среднего chunk, лимита API и времени ответа базы. Настройку меняют по метрикам, а не по максимально допустимому числу.

Типичные ошибки и способы устранения

Файл не распознаётся или объявлен неподдерживаемым

Сначала проверяют реальный формат, а не расширение. Файл с именем .pdf может быть HTML-страницей ошибки или повреждённой загрузкой. Открывают его независимым просмотрщиком, проверяют magic bytes и повторно сохраняют. Для текстовых таблиц нормализуют кодировку и окончания строк. Защищённый PDF может потребовать разрешённого снятия защиты правообладателем.

В результате нет текста

Если PDF является сканом, режим, использующий только текстовый слой, вернёт пустой или короткий результат. Выбирают High Res, VLM или OCR и проверяют разрешение. Для изображения исправляют поворот и контраст. Если пусты только отдельные страницы, смотрят, не состоят ли они из нестандартного вложенного изображения или прозрачного слоя.

Перемешаны колонки и заголовки

Сравнивают Auto, High Res и VLM на проблемной странице. В JSON смотрят координаты и порядок элементов. Декоративный текст, колонтитулы и подписи могут влиять на классификацию. Для downstream-поиска иногда достаточно фильтровать повторяющиеся элементы, но если смешан основной текст, нужна другая стратегия, а не косметическая очистка после chunking.

Таблица превратилась в строки

Включают более точную обработку и Table to HTML, затем проверяют исходное качество линий и ячеек. Таблица без границ или с многоуровневыми заголовками сложнее. Если HTML есть, но отображается неверно, проблема может находиться в последующем конвертере в Markdown. Сохраняют исходный HTML для проверки.

Search JSON недоступен

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

Destination отклоняет запись

Проверяют размерность embedding, mapping, обязательные поля, размер пакета и права. Ошибка одной слишком большой записи может остановить batch. Уменьшают Batch Size и находят конкретный chunk. Для базы данных проверяют длину строк и допустимые символы в ID. Для объекта — путь и правила перезаписи.

Задание создаёт дубли

Причина обычно в случайных IDs, смене имени исходного объекта или отсутствии upsert. Вводят стабильный document_id и chunk_id, хранят revision, удаляют прежние записи перед загрузкой обновлённого документа. Нельзя исправить дубли только визуальным фильтром: они продолжают влиять на ранжирование и расходы.

Срок выполнения неожиданно вырос

Сравнивают состав файлов, число страниц, разрешение, стратегию, enrichments и журнал назначения. Один многостраничный TIFF или презентация с крупными изображениями способен изменить среднее. Проверяют лимиты внешней модели и базы. Если повторы растут, сначала устраняют причину ошибок, а не увеличивают параллелизм.

Ответы RAG стали хуже после изменения chunking

Сравнивают старый и новый набор на одинаковых вопросах. Слишком маленькие chunks теряют контекст, слишком большие содержат несколько тем. Overlap может создать дубли, а изменение Title-классификации — новые границы. Возвращают прежнюю конфигурацию или создают новый индекс для честного A/B-теста.

Что Unstructured не заменяет

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

Он также не является готовым чат-ботом. Partition, chunking и embedding создают данные, но вопрос пользователя проходит через поисковый индекс, фильтры доступа, reranking, prompt и модель. Ошибка на любом этапе влияет на ответ. Наличие JSON и vectors означает, что подготовлен слой данных, а не завершена вся RAG-система.

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

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

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

Сравнение Unstructured с аналогами

Программа	Лучше подходит для	Главное ограничение
Unstructured	Полных потоков от источника через parsing, chunking и embeddings до хранилища	Не предназначен для ручной правки страниц
LlamaParse	Агентного разбора сложных PDF, таблиц, графиков и сканов с выводом в Markdown или JSON	Основной мощный разбор привязан к облачной платформе и кредитам
Docling	Программной конвертации разных форматов в единый документный объект с возможностью автономного запуска	Для производственной синхронизации источников и назначений требуется собственная обвязка
Azure Document Intelligence	OCR, layout, готовых и обучаемых моделей извлечения в инфраструктуре Microsoft Azure	Рабочий процесс тесно связан с ресурсами и моделью Azure
Google Cloud Document AI	Классификации, разделения и специализированных процессоров документов в Google Cloud	Для каждого сценария нужно выбрать и настроить подходящий processor
Amazon Textract	Извлечения текста, форм, таблиц, подписей и запросов из документов в AWS	Поддерживает более узкий набор задач и форматов, чем полный ETL-конвейер
PDF Commander	Ручного редактирования, OCR, объединения, подписи и защиты PDF	Не строит готовые JSON- и RAG-конвейеры

Unstructured выбирают, когда нужен единый управляемый путь от корпоративного источника до JSON, chunks, vectors и назначения. LlamaParse особенно уместен для сложного агентного parsing и готовых продуктов вокруг document AI. Docling подходит команде, которая хочет контролировать конвертацию кодом и самостоятельно собрать эксплуатационный поток. Azure Document Intelligence, Google Document AI и Amazon Textract удобны, когда инфраструктура уже сосредоточена в соответствующем облаке и задача совпадает с их моделями. PDF Commander нужен для другой стадии: исправить сам PDF, распознать скан для человека, собрать страницы или подписать документ перед передачей в конвейер.

Как выбрать конфигурацию для своей задачи

Начинают не с максимального набора функций, а с результата, который должен получить следующий компонент. Для полнотекстового поиска нужны чистый текст, страницы и metadata. Для RAG — хорошие chunks, embeddings и доступ к источнику. Для извлечения счетов — JSON Schema, таблицы и валидация. Для мультимодального поиска — описания изображений и связь с координатами. Один workflow может обслуживать несколько целей, только если его контракт данных остаётся ясным.

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

После partition настраивают chunking. Сначала by Title для структурированных материалов или by Character для ровного текста. Проверяют границы и размер в токенах. Добавляют overlap только при доказанной проблеме на стыках. Similarity применяют, если заголовки ненадёжны. Contextual Chunking включают, когда изолированным фрагментам не хватает информации о разделе.

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

Перед запуском расписания проверяют IDs, upsert, удаление и права. Выполняют небольшой job, читают журнал, открывают несколько записей в назначении и запускают поиск. Затем увеличивают объём ступенями. Резкий переход от одного тестового PDF к миллиону страниц скрывает ошибки, которые на малой партии исправляются за минуты.

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

Рабочий чек-лист перед массовой обработкой

• Проверить реальные форматы файлов, кодировки, защиту и качество сканов.
• Собрать контрольную выборку с таблицами, изображениями, несколькими колонками и ошибочными файлами.
• Сравнить Auto с Fast, High Res или VLM по измеримым критериям.
• Проверить типы элементов, порядок чтения, page_number, coordinates и element_id.
• Выбрать chunking по структуре документов и проверить размер в токенах.
• Оставить только те enrichments, которые улучшают конкретный поиск или извлечение.
• Согласовать модель и размерность embedding с индексом и кодом запросов.
• Создать стабильные document_id и chunk_id, определить обновление и удаление.
• Ограничить права коннекторов и убрать секреты из логов и описаний.
• Проверить небольшой Job, подробный журнал и несколько записей в назначении.
• Запустить набор реальных вопросов и сохранить результаты как регрессионный тест.
• Настроить мониторинг ошибок, времени на страницу, пустых элементов и дублей.

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

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

Итоговый поток должен оставаться объяснимым: по найденному chunk можно установить документ, страницу, элемент, конфигурацию и задание, которое его создало. Эта трассировка отличает надёжную документную систему от набора разрозненных OCR-вызовов. Когда она выстроена, ошибки быстрее локализуются, повторная обработка не создаёт хаос, а пользователь получает ответ вместе с проверяемым основанием.