Ray Data và Docling Giải Quyết Điểm Yếu Lớn Nhất của AI Doanh Nghiệp

Zach Anderson
16:58 27/02/2026 (Giờ VN)

Tích hợp mới kết hợp xử lý phân tán của Ray Data với phân tích tài liệu của Docling để xử lý hơn 10,000 tệp phức tạp cho ứng dụng RAG trong vài giờ thay vì vài ngày.

Các nhóm doanh nghiệp xây dựng ứng dụng AI vừa có giải pháp cho điểm nghẽn khó chịu nhất của họ. Anyscale đã trình bày chi tiết cách kết hợp Ray Data với Docling có thể biến tuần lễ xử lý tài liệu thành vài giờ—một bước phát triển có thể đẩy nhanh tiến độ triển khai cho các công ty đang ngồi trên kho lưu trữ tài liệu khổng lồ.

Tích hợp kỹ thuật này giải quyết những gì người trong ngành gọi là "điểm nghẽn dữ liệu" trong hệ thống Retrieval-Augmented Generation. Trong khi các bản demo khiến AI tạo sinh trông đơn giản, thực tế lại phải vật lộn với hàng nghìn tệp PDF cũ, bảng phức tạp và hình ảnh nhúng mà các công cụ xử lý truyền thống xử lý kém.

Những Thay Đổi Thực Tế

Công cụ thực thi streaming của Ray Data truyền dữ liệu qua các tác vụ CPU và GPU đồng thời. Kiến trúc Python gốc loại bỏ chi phí tuần tự hóa làm phiền các framework khác khi dịch dữ liệu giữa các môi trường ngôn ngữ. Đối với các nhóm chạy suy luận hàng loạt hoặc tiền xử lý tập dữ liệu khổng lồ, điều này có nghĩa là chu kỳ lặp nhanh hơn.

Docling xử lý độ phức tạp phân tích cú pháp phá vỡ hầu hết các công cụ truyền thống—trích xuất chính xác các bảng và bố cục trong khi vẫn giữ nguyên cấu trúc ngữ nghĩa. Khi được tích hợp với Ray Data, mỗi nút worker chạy một phiên bản Docling với các mô hình AI nhúng trong bộ nhớ, cho phép xử lý tài liệu song song ở quy mô lớn.

Kiến trúc hoạt động như sau: Ray Data Driver quản lý thực thi và tuần tự hóa mã tác vụ để phân phối. Các worker đọc các khối dữ liệu trực tiếp từ bộ nhớ và ghi các tệp JSON đã xử lý vào đích. Driver không bao giờ trở thành điểm nghẽn vì nó không xử lý thông lượng dữ liệu thực tế.

Nền Tảng Kubernetes

KubeRay điều phối các cụm Ray trên Kubernetes, xử lý tự động mở rộng quy mô động từ 10 đến 100 nút một cách minh bạch. Hệ thống bao gồm khôi phục tự động khi các nút worker bị lỗi—quan trọng đối với các công việc thu thập dữ liệu lớn không thể khởi động lại từ đầu.

Quy trình đầu cuối di chuyển tài liệu từ bộ nhớ đối tượng qua phân tích cú pháp và phân đoạn, tạo embedding trên các nút GPU và ghi vào cơ sở dữ liệu vector như Milvus. Các ứng dụng RAG sau đó truy vấn cơ sở dữ liệu để cung cấp ngữ cảnh cho LLM.

Các công ty bao gồm Pinterest, DoorDash và Instacart đã sử dụng Ray Data cho xử lý last-mile và đào tạo mô hình, cho thấy công nghệ đã chứng minh khả năng sản xuất thực tế.

Vượt Ra Ngoài Tìm Kiếm Đơn Giản

Chiến lược rộng hơn ở đây nhắm đến quy trình làm việc AI đại lý, nơi các đại lý tự động thực hiện các tác vụ nhiều bước. Chất lượng dữ liệu được xử lý trở nên quan trọng hơn khi các đại lý dựa vào tài liệu chính xác để hành động thay mặt người dùng. Các tổ chức xây dựng kiến trúc có thể mở rộng hiện định vị mình cho các chuỗi suy luận nâng cao với nhiều lệnh gọi LLM tuần tự.

Các nền tảng Red Hat OpenShift AI và Anyscale cung cấp tùy chọn triển khai với yêu cầu quản trị doanh nghiệp. Nền tảng nguồn mở có nghĩa là các nhóm có thể bắt đầu thử nghiệm mà không gặp rào cản mua sắm lớn.

Đối với các nhóm AI hiện đang dành nhiều thời gian cho việc chuẩn bị dữ liệu hơn là điều chỉnh mô hình, tích hợp này cung cấp một con đường thực tế phía trước. Câu hỏi không phải là liệu xử lý tài liệu phân tán có quan trọng không—mà là liệu cơ sở hạ tầng của bạn có thể xử lý những gì tiếp theo hay không.

Nguồn hình ảnh: Shutterstock