Ray Data и Docling решают главную проблему корпоративного ИИ

Зак Андерсон
16:58, 27 февраля 2026

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

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

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

Что на самом деле меняется

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

Docling справляется со сложностью парсинга, которая ломает большинство традиционных инструментов — точно извлекая таблицы и макеты, сохраняя при этом семантическую структуру. При интеграции с Ray Data каждый рабочий узел запускает экземпляр Docling со встроенными моделями ИИ в памяти, обеспечивая параллельную обработку документов в масштабе.

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

Основа Kubernetes

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

Сквозной поток перемещает документы из объектного хранилища через парсинг и разбиение на фрагменты, генерирует встраивания на узлах GPU и записывает в векторные базы данных, такие как Milvus. Затем RAG-приложения запрашивают базу данных для передачи контекста LLM.

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

За пределами простого поиска

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

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

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

Источник изображения: Shutterstock