Трубопроводы Docling: создание данных RAG класса корпоративного уровня
Как docling-pipelines заменяет хрупкие скрипты на основе «клея» на комбинируемые операторы и потоки в формате JSON: входные данные, извлечение информации, контроль качества, генерация эмбеддингов и хранение векторов.
Источники: Introducing Docling Pipelines: Building Enterprise-Grade RAG Data Pipelines
Где идут не так с использованием готового кода
Представьте общий диск с 10 000 PDF-файлами, сайт SharePoint, заполненный файлами Word, и накопившиеся записи звонков клиентов. Команда, отвечающая за продукт, хочет, чтобы всё это оказалось в векторном хранилище, где можно было бы выполнять поиск и разбивать данные на части, при этом личные данные должны быть удалены, а дубликаты — устранены.
Типичным инженерным решением является использование скрипта, а затем ещё одного скрипта. Приглашаются несколько библиотек, ноутбук Pandas объединяет их воедино, задача cron запускает всё это каждую ночь, и решение готово к использованию. Оно работает, но лишь некоторое время.
Через три месяца кто-то спрашивает, почему отсутствуют новые документы. Проблема сводится к изменению структуры одной из столбцов в последующих этапах обработки, в результате чего скрипт незаметно удалил соответствующие строки. Никто этого не заметил, поскольку ничего не было видно. После устранения ошибки происходит повторная обработка, и тогда становится ясно, что нет записей о том, какие документы уже обработаны, поэтому все 10 000 документов снова проходят обработку.
Такова типичная судьба инструментов, связывающих этапы обработки документов. Они начинаются просто и постепенно разрушаются, а затем резко ломаются. Добавляются повторные попытки выполнения скриптов, фильтрация качества появляется уже в последнюю очередь, а отслеживание зависимостей между этапами отсутствует, поэтому успех зависит от того, будут ли скрипты выполняться в правильном порядке. Поэтапные обновления становятся сложными без стабильного идентификатора документа. В итоге остается запутанная структура, которую может отладить только её создатель, но даже он уже не уверен.
Что такое docling-pipelines
Docling-pipelines — это модульная платформа на основе операторов для обработки документов, предназначенная для создания полноценных данныхых пайплайнов типа RAG. Она охватывает весь жизненный цикл: начиная с загрузки данных из локальных или облачных источников, затем выделения текста и сущностей, фильтрации качества, разбиения на части и генерации векторных представлений, и заканчивая записью в векторную базу данных. Это стандартный путь, и большинство производственных пайплайнов являются его вариациями.
Его устанавливают как обычный пакет Python:
bash
pip install docling-pipelines
Он работает везде, где работает Python. Для базового использования он не требует внешней инфраструктуры: ни Kafka, ни кластера Spark, ничего не нужно настраивать. Пайплайн описывается в файле JSON, к этому файлу направляется интерфейс командной строки, и запуск начинается.
Существует три способа использования. Интерфейс командной строки подходит для однократных запусков и локальной разработки. Библиотека на Python, основанная на DocpipeFlowManager, позволяет запускать пайплайны из кода приложений или ноутбуков. REST API предназначен для пайплайнов, работающих как общий сервис, который используют несколько команд. Все три способа рассматриваются ниже.
Проект является open source, а его первая версия, v0.1.0, вышла в июле 2025 года.
Основная идея: операторы и потоки
Тем, кто только знакомится с этой фреймворком, следует уделить здесь больше времени, поскольку остальное становится понятным после этого.
Оператор — это базовая единица. Оператор — это класс в Python, который принимает таблицу документов и возвращает таблицу, возможно, преобразованную. Каждая функция в фреймворке, будь то загрузка данных, извлечение информации, обнаружение языка, разбиение на части или генерация векторных представлений, является оператором.
Требования к оператору немногочисленны:
short_name: строка, которую JSON использует для обозначения оператораtransform(table): принимает объектpa.Tableи возвращает список таблиц вместе с словарем метаданныхget_metadata(): метод@staticmethod, возвращающий метаданные оператора для его обнаруженияget_required_features(): указывает, какие столбцы необходимы оператору в качестве входных данныхvalidate(): необязательный метод для проверки конфигурации при запуске
Минимальная структура оператора выглядит следующим образом:
from docpipe.core.operators.abstract_operator import AbstractOperator, OperatorCategory
import pyarrow as pa
class MyOperator(AbstractOperator):
short_name = "my_operator"
category = OperatorCategory.Quality
def __init__(self, config: dict) -> None:
super().__init__(config)
def transform(self, table: pa.Table) -> tuple[list[pa.Table], dict]:
metadata = self.create_base_metadata(total_docs_count=len(table))
# … process table …
return [table], metadata
@staticmethod
def get_metadata() -> dict:
return {"short_name": "my_operator", "description": "…"}
Применение этих методов позволяет создать компонент первого класса, который может сочетаться с любым другим оператором в экосистеме.
Таблицы PyArrow хранят данные. Каждому оператору передаётся объект pa.Table, и он возвращает такой же объект. Это осознанный выбор, поскольку столбчатый формат PyArrow эффективен и имеет типизацию, а данные передаются между этапами без копирования. Чистые строки и словари Python никогда не передаются между этапами обработки.
Полезным следствием этого является то, что столбцы накапливаются по мере обработки данных. Этап загрузки добавляет поля id, name, path и source. Этап извлечения добавляет поле content. Этап разбиения на части добавляет поле chunked_content, а этап генерации вкладок — поле embeddings. К моменту, когда строка попадает в хранилище векторов, она содержит полную запись со всеми столбцами и метаданными, готовую к индексации.
Оператор воздействует только на те столбцы, которые его касаются, а всё остальное проходит мимо без изменений. Поэтому новый оператор можно вставить в любое место, не меняя его соседей.
Поток представляет собой DAG. Пайплайн хранится в файле JSON. Каждый узел содержит поле type (краткое название оператора), уникальное в графе имя name, блок настроек config и список зависимостей depends_on. При запуске движок разрешает граф зависимостей и выполняет узлы в топологическом порядке, причем параллельные ветви обрабатываются одновременно.
Таким образом, структура пайплайна представляет собой данные, а не код. Её можно версионировать, сравнивать изменения, статически проверять и заменять без вмешательства в код на Python. Параметр --validate выявляет нарушения зависимостей, отсутствующие столбцы и ошибки конфигурации ещё до обработки первого документа.
Почему модель работает. На практике выделяются два преимущества.
Первым является композиционность. Оператор может следовать за любым другим при условии, что предыдущие операторы сгенерировали столбцы, указанные в методе get_required_features(). Механизм проверяет это при запуске и сообщает о конкретном отсутствующем столбце и узле, который должен был его предоставить, ещё до начала выполнения.
Вторым преимуществом является возможность тестирования. Каждый оператор ведёт себя как чистая функция от одной таблицы к другой, поэтому его можно тестировать отдельно: создаётся объект pa.Table с необходимыми столбцами, вызывается метод transform(), а затем проверяется результат. Не требуются моки, побочные эффекты или работа с реальными потоками обработки.
Ознакомление с операторами
Существует 22 встроенных оператора, разделённых на пять категорий. Это краткий обзор.
Получение данных. IngestSource — единственный оператор получения данных, поддерживающий как локальные, так и облачные источники. Для локальных путей используется поставщик filesystem, а тот же узел может переключаться на любого из восьми облачных поставщиков (S3, IBM COS, SharePoint, OneDrive, Google Drive, Box, CSV-файлы и веб-страницы) без изменения остальных этапов процесса. Он выводит по одной строке на файл, содержащей только метаданные, без содержимого. На этапе извлечения содержимое загружается позже, что обеспечивает быстрое получение данных и небольшую нагрузку на память даже при больших объемах.
Извлечение данных. Extract преобразует необработанные файлы в структурированный текст. PDF, DOCX, HTML, изображения, аудио и видео преобразуются в формат markdown с помощью Docling: либо в режиме библиотеки (локально, без сетевых запросов), либо с помощью Docling Serve в режиме API, что позволяет переносить тяжелую работу по извлечению на специализированную службу.
Экстракция сущностей является необязательной и предлагается тремя поставщиками: LiteLLM (который обеспечивает доступ к более чем 100 поставщикам моделей), IBM watsonx.ai и система экстракции на основе шаблонов от Docling. Выбор зависит от возможностей доступа к моделям и стоимости.
ACLOperator входит в этап экстракции. Он извлекает метаданные управления доступом из документов в отдельную колонку, что позволяет последующим системам применять меры безопасности на уровне документа без необходимости повторного обращения к исходному файлу.
Функциональные компоненты. В эту категорию входит логика обработки данных: операторы, которые преобразуют, направляют и переформатируют данные, а не обогащают их информацией.
ChunkerOperator разделяет извлечённый текст на фрагменты с использованием одной из трёх стратегий: простой (фиксированный размер символов, настраиваемое перекрытие), семантической (учитывающей содержимое) или гибридной (разбиение в стиле Docling, сохраняющее структуру документа). Он также может подготавливать краткое описание каждого фрагмента с помощью LLM, что обеспечивает более полное представление при поиске.
EmbeddingsOperator генерирует векторные эмбеддинги для каждого фрагмента. Он работает с моделями HuggingFace, запущенными локально, с сервисом LiteLLM (более 100 облачных провайдеров) и с IBM watsonx.ai; замена модели эмбеддингов осуществляется путём изменения одной строки в файле JSON с настройками работы.
BranchingOperator — это та часть, где процессы становятся интереснее. Он разделяет документы на отдельные подпайплайны на основе значений столбцов, условий в стиле SQL или меток классификации. Каждая ветвь работает самостоятельно и указывается по имени в поле depends_on с использованием точечной нотации, например "depends_on": ["branch_node.branch_name"].
MergeOperator объединяет разделенные потоки обратно вместе, либо складывая строки, либо соединяя столбцы, в зависимости от требований операторов, находящихся ниже по потоку.
DocIdHashOperator генерирует детерминированный, стабильный хеш-идентификатор из содержимого каждого документа. Этот идентификатор лежит в основе удаления дубликатов и пошаговой обработки: один и тот же документ всегда получает один и тот же идентификатор, независимо от того, где и когда он был загружен.
EntityCurationOperator и NOOPOperator дополняют этот набор. Первый отвечает за очистку сущностей после их извлечения, а второй — за передачу данных между узлами, что помогает организовать структуру DAG.
Качество. Операторы из этой группы определяют разницу между просто наличием конвейера обработки данных и наличием надежного конвейера.
LanguageDetect с помощью fastText определяет язык документа и добавляет столбец lang_name, который может использоваться для фильтрации, направления данных или их маркировки.
ReadabilityOperator оценивает читаемость каждого документа по пяти критериям: индекс Flesch для легкости чтения, уровень Flesch-Kincaid, показатель Gunning Fog, индекс Dale-Chall и количество сложных слов. Эти показатели служат полезными сигналами для направления данных, например, для различения технической документации и обычного контента перед выбором стратегии разбиения на части.
PIIAndHAPAnnotator использует методы обнаружения на основе больших языковых моделей для поиска и маскировки персональной информации (адресов электронной почты, номеров телефонов, номеров социального страхования, номеров карт, банковских счетов, IP-адресов), а также контента, содержащего ненависть, оскорбления и нецензурную лексику; пороги обнаружения устанавливаются для каждой категории отдельно.
RedactionOperator обеспечивает маскировку на основе шаблонов, когда форматы информации известны, например внутренние идентификаторы, коды продуктов или любые данные, которые можно совпоставить с помощью регулярных выражений.
EdedupOperator удаляет полные дубликаты внутри набора документов, используя для этого столбец doc_id_hash для детерминированного выполнения операций.
SQLFilterOperator относится к наиболее недооцененным компонентам. Он фильтрует строки с использованием условия SQL WHERE на значениях столбцов, поэтому выражение "docq_total_words > 100 AND lang_name = 'en'" обеспечивает полноценную проверку качества без использования Python. В сочетании с оценками читаемости и определением языка он позволяет реализовывать довольно сложные механизмы маршрутизации без написания кода.
DocumentClassifierOperator сортирует документы в настраиваемые категории. DocQuality вычисляет показатели качества для всего корпуса, а MLEnrichmentOperator добавляет прогнозы машинного обучения в виде дополнительных столбцов. Более общий вывод, который делают и другие описания подобных пайплайнов, заключается в том, что качество данных часто оказывает большее влияние на результаты RAG, чем выбор модели.
VectorDB и хранение данных. VectorDBOperator записывает документы в виде чанков в векторный хранилище; поддерживаемыми бэкендами являются OpenSearch и Milvus. Сопоставление полей, настройки индексов и нормализация метаданных задаются в JSON-файле потока.
DocumentSetOperator сохраняет обработанные таблицы в набор документов, хранящийся с использованием DuckDB. Это полезно, когда обработанные документы должны быть доступны для поиска без использования векторного хранилища или когда требуется надежная точка контроля на этапе обработки.
StorageOutputOperator записывает документы обратно во внешние хранилища (S3, SharePoint, Google Drive или локальную файловую систему) в обработанном или исходном виде, что подходит для схем «обработка и архивирование».
Все эти компоненты могут использоваться в любом порядке при условии соблюдения предшествующих зависимостей, поэтому поток не ограничен фиксированной структурой.
Реальный пример потока
Вот стандартный алгоритм быстрого запуска — полная цепочка обработки данных до хранения в векторном хранилище, в которой для генерации вкладок используется Ollama, а для хранения — OpenSearch:
{
"flow_name": "complete-document-pipeline",
"global_config": {
"doc_column": "content",
"storage": "in-memory"
},
"flow": [
{
"type": "ingest_source",
"name": "ingest_local_folder",
"config": {
"provider": "filesystem",
"connection_params": {
"paths": [
"./sample_documents"
]
},
"include_filter": "pdf,txt,docx"
}
},
{
"type": "extract_operator",
"name": "extract_with_docling",
"config": {
"text_extraction": {
"provider": "docling_library"
},
"entity_extraction": {
"provider": "none"
}
},
"depends_on": [
"ingest_local_folder"
]
},
{
"type": "chunker",
"name": "simple_chunker",
"config": {
"chunk_type": "simple",
"chunk_size": 512,
"chunk_overlap": 50
},
"depends_on": [
"extract_with_docling"
]
},
{
"type": "embeddings",
"name": "ollama_embeddings",
"config": {
"provider": "litellm",
"provider_config": {
"model_id": "openai/nomic-embed-text",
"api_base": "http://localhost:11434/v1"
},
"embeddings_column": "embeddings"
},
"depends_on": [
"simple_chunker"
]
},
{
"type": "vectordb",
"name": "opensearch_vector_store",
"config": {
"provider": "opensearch",
"doc_id_column": "doc_id_hash",
"embeddings_column": "embeddings",
"provider_config": {
"index_name": "sample-documents-index",
"host": "localhost",
"port": 9200
}
},
"depends_on": [
"ollama_embeddings"
]
}
]
}
Пошагово, узел за узлом:
- ingest_local_folder сканирует папку
./sample_documentsв поисках файлов PDF, текстовых и DOCX с помощьюingest_sourceи его поставщика файловой системы. Каждый файл преобразуется в строку с идентификатором, именем, путем и источником. В этот момент содержимое файлов не читается, поэтому операция происходит быстро: находятся файлы, но они не загружаются. - extract_with_docling берет эти строки с метаданными, читает каждый файл с помощью Docling и добавляет столбец
contentс извлеченным текстом в формате Markdown. Именно на этом этапе PDF преобразуются в структурированный текст, доступный для поиска. Поставщикdocling_libraryработает полностью внутри процесса, поэтому внешние сервисы не требуются.
chunked_content — структурированный список объектов фрагментов, каждый из которых содержит текст и информацию о его положении в исходном документе.embeddings. Это по сути версия LiteLLM, адаптированная для Ollama; изменение значений model_id и api_base позволяет направить запрос к любому из более чем 100 провайдеров, поддерживаемых LiteLLM, без каких-либо других изменений.doc_id_hash в качестве первичного ключа. Поэтому повторная эксплуатация этого инструмента никогда не приводит к созданию дубликатов.Несколько структурных аспектов заслуживают внимания. Единственная необходимая связь — это depends_on: нет явной передачи данных, нет регистрации обратных вызовов и нет общего состояния, поскольку движок обрабатывает граф и перемещает данные. Блок global_config устанавливает значения по умолчанию, которые наследуются всеми операторами. Параметр doc_column указывает, в какой колонке находится основной текст, а storage: „in-memory“ сохраняет промежуточные таблицы в ОЗУ между этапами, что подходит для большинства случаев использования; при работе с большими наборами данных его можно заменить.
Весь поток обработки запускается одной командой:
docling-pipelines - flow-file pipeline.json
Расширенные шаблоны
Потоки не обязательно должны быть линейными цепями. В реальных реализациях часто встречаются три шаблона.
Разветвление и слияние. Разветвление направляет документы в разные под-пайплайны в соответствии с настраиваемыми критериями. Каждая ветвь представляет собой именованный результат, на который обращаются следующие узлы с использованием точечной нотации в параметре depends_on. Ветвь маршрутизации, определяемая оценкой читаемости, выглядит следующим образом:
{
"name": "quality_branching",
"type": "branching",
"config": {
"branches": {
"high_quality_branch": {
"link_name": "High Quality Documents",
"criteria_json": {
"criteria_list": [
{
"variable": "flesch_reading_ease",
"operator": ">",
"value": 60
}
],
"logical_operator": "AND"
}
},
"low_quality_branch": {
"link_name": "Low Quality Documents",
"criteria_json": {
"criteria_list": [
{
"variable": "flesch_reading_ease",
"operator": "<=",
"value": 60
}
],
"logical_operator": "AND"
}
}
}
},
"depends_on": [
"readability"
]
}
Ветка высокого качества может пройти процедуру обогащения с использованием методов машинного обучения перед вставкой в базу данных, в то время как ветка низкого качества проходит через ещё один SQLFilterOperator, который удаляет документы, не содержащие ни одного слова, перед вставкой. Обе группы документов оказываются в отдельных индексах OpenSearch, а затем MergeOperator может снова объединить эти потоки, если позже потребуется единый вид данных.
Маршрутизация с контролем качества. Идея заключается в том, сначала использовать недорогие операторы контроля качества, а затем позволить SQLFilterOperator удалять некачественные строки до того, как будут применены дорогостоящие алгоритмы на основе больших языковых моделей. Полная структура такого контроля может выглядеть следующим образом:
lang_detect → ededup → doc_quality → readability → sql_filter → embeddings
Условие sql_filter — это просто оператор WHERE в SQL, выраженный в виде данных:
{
"criteria_list": [
{
"variable": "docq_total_words",
"operator": ">",
"value": 100
},
{
"variable": "lang_name",
"operator": "=",
"value": "en"
}
],
"logical_operator": "AND"
}
Нет ни Python, ни пользовательских операторов — только условие в JSON, и каждая строка, не соответствующая ему, никогда не попадает в функцию встраивания.
Многоэтапное обогащение данных. Последовательность «классификация, маршрутизация, извлечение, обогащение, хранение» постоянно используется в производственных средах. Сначала документы могут быть классифицированы: техническая документация направляется в инструмент извлечения сущностей, настроенный на технический контент, а документы с правилами — в другой инструмент. Каждая ветвь добавляет столбцы, специфичные для своего типа, и потоки данных сливаются до этапа разбиения на чанки и встраивания, чтобы остальная часть пайплайна оставалась общей.
На каждом этапе добавляются столбцы, и операторы, находящиеся ниже по потоку, получают всё более детализированную таблицу. Всё это не требует специальных режимов или флагов. Это обычные операторы, объединённые вместе, что и является преимуществом модели операторов.
Три способа его запуска
Эта платформа — это не просто инструмент командной строки, а подходит для различных инженерных задач.
Командная строка. Это самый быстрый способ запустить работающую цепочку обработки:
docling-pipelines - flow-file pipeline.json
docling-pipelines - flow-file pipeline.json - validate # validate without running
docling-pipelines - list-operators - verbose # discover all registered operators
--validate полезен на этапе разработки потока: нарушения зависимостей, отсутствие необходимых столбцов и ошибки типа конфигурации обнаруживаются ещё до того, как происходит чтение или запись данных. Регулярное использование этого инструмента в CI перед развертыванием изменений в потоке — хорошая привычка.
Библиотека Python. Когда необходимо запускать пайплайны из кода приложения:
from docpipe.lib.docpipe_flow_manager import DocpipeFlowManager
manager = DocpipeFlowManager(flow_file="pipeline.json")
manager.execute()
Это подходит для кода, встроенного в более крупное приложение, ноутбук или скрипт оркестрации, который должен управлять жизненным циклом выполнения.
REST API. Для работы в качестве долгоживущего сервиса:
uvicorn docpipe.api.main:app - host 0.0.0.0 - port 8000
Сервер FastAPI предоставляет три группы маршрутов: /api/v1/flows для управления потоками, /api/v1/job_runs для контроля запусков задач и /api/v1/operators для поиска операторов. Пользователи аутентифицируются через LDAP или OAuth2/OIDC с использованием токенов JWT, а документация в формате OpenAPI/Swagger генерируется автоматически по адресу /docs. Это интерфейс общего сервиса, который используют несколько команд, который может запускаться внешними событиями, а также к которому другие могут обращаться для получения информации о статусе и результатах.
Расширение с помощью пользовательских операторов
Для долгосрочного внедрения в реальных организациях это, пожалуй, самая важная часть проектирования.
Контракт достаточно компактен, чтобы его описание занимало примерно 30 строк. Класс на Python соответствует требованиям, если он наследуется от AbstractOperator и реализует методы transform(), get_metadata() и get_required_features(). Он может сочетаться с любым встроенным оператором, отображаться в выводе команды --list-operators, а в формате JSON потока к нему обращаются по short_name, как и к встроенному оператору.
Регистрация осуществляется тремя способами в зависимости от этапа разработки.
Путь в файловой системе предназначен для разработки. Укажите переменную окружения на локальную директорию:
DOCPIPE_CUSTOM_OPERATORS=./my_operators docling-pipelines - flow-file pipeline.json
Все элементы в этой директории импортируются при запуске. Установка не требуется, поэтому процесс итерации происходит быстро.
Пакет Python предназначен для распространения. Операторы публикуются в виде пакета pip с соответствующей точкой входа, устанавливаются в той же среде, после чего автоматически регистрируются. Таким образом операторы могут попасть к другим командам без необходимости изменять основной кодовый базис.
S3 URI — это вариант для крупных предприятий. Укажите DOCPIPE_CUSTOM_OPERATORS на удаленный пакет операторов, и фреймворк загрузит его и зарегистрирует во время выполнения. Это позволяет централизованно управлять операторами во многих развертываниях: изменения вносятся в одном месте, а каждое развертывание применяет их при следующем запуске.
Логика, специфичная для конкретных предприятий, таким образом не входит в ядро фреймворка. Процессоры обеспечения соответствия, инструменты извлечения данных для конкретных доменов и собственные модели оценки могут быть упакованы в виде операторов, объединены с встроенными компонентами в формате JSON-потока и развернуты без необходимости модификации самого фреймворка.
Практические аспекты
Уместным вопросом к любому подобному инструменту является то, является ли он хорошим прототипом или действительно готов к использованию в производственных условиях. Далее приведены детали.
Возможность отслеживания. Встроена поддержка OpenTelemetry, и каждая экспекуция оператора генерирует элемент типа span. Логи представлены в виде структурированного JSON с информацией о корреляции трасс, где в каждой строке указаны trace_id и span_id. Это работает с Jaeger, Grafana Tempo, Datadog и AWS X-Ray без необходимости настройки с стороны приложения, причем нагрузка равна нулю при отключении функции телеметрии.
Пошаговая обработка. В конвейере используется детерминистичный идентификатор из DocIdHashOperator для отслеживания обработанных документов. При повторной обработке принимаются во внимание только новые или изменённые документы; один и тот же документ, отправленный дважды, получает тот же хеш и игнорируется. Установка параметра force_ingest: true в global_config отменяет это поведение и приводит к повторной обработке всего. Метаданные для пошаговых запусков могут храниться в DuckDB (по умолчанию), PostgreSQL или на файловой системе.
Безопасность. ACLOperator отображает метаданные разрешений в виде столбца для последующего применения правил, а PIIAndHAPAnnotator находит и маскирует конфиденциальный контент до того, как он попадёт в хранилище векторов. Секреты, указанные в конфигурации потока, могут браться из HashiCorp Vault: путь вида vault://path/to/secret, заданный в JSON, разрешается движком во время выполнения процесса. Доступ к REST API защищается с помощью LDAP и OAuth2/OIDC.
Масштабируемость. Выполнение возможно в трех режимах — от ноутбука до распределенного флота устройств. По умолчанию используется пул потоков внутри процесса, который является быстрым, простым и не требует дополнительных зависимостей. Пул процессов запускает операторы в отдельных процессах для задач, требующих большой производительности CPU на одном узле. Для распределенных рабочих нагрузок существует пул работ Prefect, запускающий контейнеры Docker, что обеспечивает горизонтальное масштабирование и централизованное управление процессами выполнения. Настройки микрогруппировки контролируют использование памяти во всех режимах, что имеет важное значение при обработке крупных документов с помощью алгоритмов извлечения информации из больших языковых моделей.
Что делать дальше
Проект размещён на GitHub в рамках организации IBM, и его руководство по быстрому старту — это самый быстрый способ запустить рабочую цепочку. Области, требующие более тщательного изучения, включают слой извлечения данных (интеграция с Docling, пайплайны VLM для документов с большим количеством изображений, ASR для аудио и видео), написание пользовательского оператора с сложной логикой начиная с первой декларации класса и заканчивая тестированием, регистрацией и развертыванием, запуск Prefect с использованием Docker для работы с большими объёмами данных, а также опции маппинга полей и шаблонов схемы для VectorDBOperator в OpenSearch.
Связанные материалы
- Практические заметки: создание локальной пайплайны RAG производственного уровня — 100% бесплатно — Подробное руководство по практическим заметкам: создание локальной пайплайны RAG производственного уровня — 100% бесплатно: контракты, проверки и готовые блоки кода для команд, внедряющих эту схему.
- Гибридный поиск в Postgres для помощника в сфере здравоохранения: схема, разбиение на части, RRF и оценка — Создание слоя поиска для помощника в сфере здравоохранения в Postgres: разбиение данных с учётом структуры, гибридный поиск с использованием pgvector и алгоритма RRF, двоичная квантизация, пороговые значения и процедуры оценки.