Ray Data та Docling вирішують найбільшу проблему корпоративного ШІ

Zach Anderson
16:58, 27 лютого 2026

Нова інтеграція поєднує розподілену обробку Ray Data з парсингом документів Docling для обробки понад 10 000 складних файлів для RAG-додатків за години замість днів.

Корпоративні команди, які створюють ШІ-додатки, щойно отримали рішення для свого найбільш неприємного вузького місця. Anyscale детально описав, як поєднання Ray Data з Docling може перетворити тижні обробки документів на години — розробка, яка може прискорити терміни розгортання для компаній, які мають величезні архіви документів.

Технічна інтеграція вирішує те, що інсайдери називають "вузьким місцем даних" у системах Retrieval-Augmented Generation. Хоча демонстрації роблять генеративний ШІ простим, реальність передбачає боротьбу з тисячами застарілих PDF-файлів, складними таблицями та вбудованими зображеннями, з якими традиційні інструменти обробки справляються погано.

Що насправді змінюється

Механізм потокового виконання Ray Data одночасно передає дані через завдання CPU та GPU. Архітектура, рідна для Python, усуває накладні витрати на серіалізацію, які переслідують інші фреймворки під час перекладу даних між мовними середовищами. Для команд, які виконують пакетний висновок або попередню обробку масивних наборів даних, це означає швидші цикли ітерацій.

Docling обробляє складність парсингу, яка ламає більшість традиційних інструментів — точно витягуючи таблиці та макети, зберігаючи семантичну структуру. При інтеграції з Ray Data кожен робочий вузол запускає екземпляр Docling з вбудованими моделями ШІ в пам'яті, забезпечуючи паралельну обробку документів у масштабі.

Архітектура працює так: Ray Data Driver керує виконанням і серіалізує код завдань для розповсюдження. Робочі вузли зчитують блоки даних безпосередньо зі сховища та записують оброблені JSON-файли в місце призначення. Драйвер ніколи не стає вузьким місцем, оскільки він не обробляє фактичну пропускну здатність даних.

Kubernetes Foundation

KubeRay організовує кластери Ray на Kubernetes, прозоро обробляючи динамічне автомасштабування від 10 до 100 вузлів. Система включає автоматичне відновлення при збої робочих вузлів — критично важливе для великих завдань з поглинання, які не можуть дозволити собі перезапуск з нуля.

Наскрізний потік переміщує документи зі сховища об'єктів через парсинг і розбиття на фрагменти, генерує вбудовування на вузлах GPU і записує у векторні бази даних, такі як Milvus. RAG-додатки потім запитують базу даних для передачі контексту LLM.

Компанії, включаючи Pinterest, DoorDash та Instacart, вже використовують Ray Data для обробки останньої милі та навчання моделей, що свідчить про те, що технологія довела життєздатність у виробництві.

Далі за простий пошук

Ширша гра тут спрямована на робочі процеси агентного ШІ, де автономні агенти виконують багатокрокові завдання. Якість оброблених даних стає більш критичною, оскільки агенти покладаються на точну документацію для дій від імені користувачів. Організації, які створюють масштабовані архітектури, тепер позиціонують себе для просунутих ланцюгів висновків з декількома послідовними викликами LLM.

Платформи Red Hat OpenShift AI та Anyscale надають варіанти розгортання з корпоративними вимогами до управління. Відкрита основа означає, що команди можуть почати тестування без серйозних перешкод із закупівлею.

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

Джерело зображення: Shutterstock