Пайплайни для молодих проєктів: створення пайплайнів даних 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, CLI налаштовується на цей файл, і починається виконання.
Існує три способи використання. CLI підходить для одноразових виконань та локальної розробки. Бібліотека Python, заснована на DocpipeFlowManager, дозволяє запускати пайплайни з коду додатків чи ноутбуків. REST API призначений для пайплайнів, які працюють як спільний сервіс, яким користуються кілька команд. Усі три способи розглянуті нижче.
Проєкт є відкритим кодом, а його перша версія, 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 оцінює кожен документ з п’яти аспектів щодо читабельності: легкість читання за шкалою Флеша, рівень складності за шкалою Флеша-Кінкейда, показник 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"
]
}
Відгалуження високої якості може пройти процедуру покращення за допомогою ML перед вставкою, тоді як відгалуження низької якості проходить через інший SQLFilterOperator, який видаляє документи без жодних слів перед вставкою. Обидва варіанти потрапляють у окремі індекси OpenSearch, а MergeOperator може знову об’єднати ці потоки пізніше, коли потрібен єдиний перегляд даних.
Маршрутизація з контролем якості. Ідея полягає у тому, спочатку використовувати дешеві оператори контролю якості, а потім дозволяти SQLFilterOperator видаляти рядки ще до виконання дорогих кроків з використанням LLM. Повний механізм контролю може виглядати так:
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, і кожен рядок, який її не виконує, ніколи не потрапляє до виклику embedding.
Багатоступеневе збагачення даних. Послідовність класифікація, направлення, вилучення, збагачення та зберігання постійно використовується в продакшені. Спочатку документи можуть бути класифіковані: технічна документація направляється до екстрактора ентитетів, налаштованого під технічний контент, а документи з правилами — до іншого. Кожна гілка додає стовпці збагачення, специфічні для свого типу, і потоки об’єднуються ще до формування частин та embedding, щоб решта конвеєра залишалася спільною.
Кожен етап додає стовпці, і наступні оператори бачать все більш збагачену таблицю. Усе це не залежить від спеціальних режимів чи прапорців. Це звичайні оператори, поєднані разом, що є перевагою моделі операторів.
Три способи її запуску
Ця платформа — це більше, ніж інструмент CLI, і підходить для різних інженерних сценаріїв.
CLI. Це найшвидший спосіб запустити потік обробки даних:
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, що забезпечує горизонтальне масштабування та централізоване керування виконанням завдань. Налаштування мікрогрупування контролюють використання пам’яті у кожному режимі, що має значення під час обробки великих документів за допомогою технологій LLM.
Куди рухатися далі
Проєкт розміщений на GitHub у рамках організації IBM, і його посібник з швидкого старту — це найшвидший спосіб запустити робочий потік. Серед аспектів, які вимагають більш детального вивчення, — це шар вилучення даних (інтеграція з Docling, потоки VLM для документів із великою кількістю зображень, ASR для аудіо та відео), створення власного оператора зі складною логікою від початкової декларації класу до тестування, реєстрації та розгортання, запуск Prefect за допомогою Docker для великих обсягів роботи, а також опції мапування полів та шаблонів схеми VectorDBOperator для OpenSearch.
Пов’язана література
- Практичні нотатки: створення локальної системи RAG виробничого рівня — 100% безкоштовно — Детальний посібник з практичних нотаток щодо створення локальної системи RAG виробничого рівня — 100% безкоштовно: контракти, перевірки та шаблони коду для команд, які впроваджують цю модель.
- Гібридний пошук у Postgres для асистента з охорони здоров’я: схема, чанкінг, RRF та оцінка — Створення шару пошуку для асистента з охорони здоров’я у Postgres: чанкінг з урахуванням структури, гібридний пошук за допомогою pgvector та алгоритму RRF, бінарна квантація, порогові значення та оцінка результатів.