Ray Data และ Docling แก้ไขปัญหาที่ใหญ่ที่สุดของ Enterprise AI

Zach Anderson
27 ก.พ. 2026 16:58

การรวมระบบใหม่นี้ผสมผสานการประมวลผลแบบกระจายของ Ray Data เข้ากับการแยกวิเคราะห์เอกสารของ Docling เพื่อประมวลผลไฟล์ที่ซับซ้อนมากกว่า 10,000 ไฟล์สำหรับแอปพลิเคชัน RAG ภายในเวลาไม่กี่ชั่วโมงแทนที่จะเป็นหลายวัน

ทีมองค์กรที่กำลังสร้างแอปพลิเคชัน AI เพิ่งได้รับโซลูชันสำหรับอุปสรรคที่น่าหงุดหงิดที่สุด Anyscale ได้อธิบายรายละเอียดว่าการผสมผสาน Ray Data กับ Docling สามารถเปลี่ยนการประมวลผลเอกสารที่ใช้เวลาหลายสัปดาห์ให้เหลือเพียงไม่กี่ชั่วโมง ซึ่งเป็นการพัฒนาที่สามารถเร่งกำหนดเวลาการนำไปใช้งานสำหรับบริษัทที่มีคลังเอกสารจำนวนมหาศาล

การรวมระบบทางเทคนิคนี้แก้ไขสิ่งที่ผู้เชี่ยวชาญเรียกว่า "ปัญหาคอขวดด้านข้อมูล" ในระบบ Retrieval-Augmented Generation แม้ว่าการสาธิตจะทำให้ AI แบบสร้างสรรค์ดูตรงไปตรงมา แต่ความเป็นจริงเกี่ยวข้องกับการต่อสู้กับ PDF เก่าหลายพันไฟล์ ตารางที่ซับซ้อน และรูปภาพที่ฝังอยู่ซึ่งเครื่องมือประมวลผลแบบดั้งเดิมจัดการได้ไม่ดี

สิ่งที่เปลี่ยนแปลงจริงๆ

เครื่องมือประมวลผลแบบสตรีมมิ่งของ Ray Data ส่งข้อมูลผ่านงาน CPU และ GPU พร้อมกัน สถาปัตยกรรมที่ใช้ Python ดั้งเดิมช่วยขจัดภาระการจัดลำดับที่รบกวนเฟรมเวิร์กอื่นๆ เมื่อแปลข้อมูลระหว่างสภาพแวดล้อมภาษาต่างๆ สำหรับทีมที่ทำงาน batch inference หรือประมวลผลล่วงหน้าชุดข้อมูลขนาดใหญ่ นี่หมายถึงวงจรการทำซ้ำที่เร็วขึ้น

Docling จัดการความซับซ้อนในการแยกวิเคราะห์ที่ทำให้เครื่องมือแบบดั้งเดิมส่วนใหญ่พังทลาย โดยสามารถแยกตารางและเค้าโครงได้อย่างแม่นยำในขณะที่รักษาโครงสร้างความหมายไว้ เมื่อรวมเข้ากับ Ray Data แต่ละ worker node จะเรียกใช้ Docling instance พร้อมโมเดล AI ที่ฝังอยู่ในหน่วยความจำ ทำให้สามารถประมวลผลเอกสารแบบขนานในระดับใหญ่ได้

สถาปัตยกรรมทำงานแบบนี้: Ray Data Driver จัดการการดำเนินการและจัดลำดับโค้ดงานเพื่อแจกจ่าย Workers อ่านบลอกข้อมูลโดยตรงจากที่เก็บข้อมูลและเขียนไฟล์ JSON ที่ประมวลผลแล้วไปยังปลายทาง driver ไม่เคยกลายเป็นคอขวดเพราะไม่ได้จัดการกับปริมาณข้อมูลจริง

พื้นฐาน Kubernetes

KubeRay จัดการคลัสเตอร์ Ray บน Kubernetes โดยจัดการการปรับขนาดอัตโนมัติแบบไดนามิกจาก 10 ถึง 100 โหนดอย่างโปร่งใส ระบบรวมการกвостановอัตโนมัติเมื่อ worker nodes ล้มเหลว ซึ่งเป็นสิ่งสำคัญสำหรับงานนำเข้าขนาดใหญ่ที่ไม่สามารถเริ่มต้นใหม่ตั้งแต่ต้นได้

ขั้นตอนแบบ end-to-end ย้ายเอกสารจากที่เก็บข้อมูลออบเจ็กต์ผ่านการแยกวิเคราะห์และการแบ่งส่วน สร้าง embeddings บนโหนด GPU และเขียนไปยังฐานข้อมูลเวกเตอร์เช่น Milvus จากนั้นแอปพลิเคชัน RAG จะสอบถามฐานข้อมูลเพื่อป้อนบริบทให้กับ LLMs

บริษัทต่างๆ รวมถึง Pinterest, DoorDash และ Instacart ใช้ Ray Data สำหรับการประมวลผล last-mile และการฝึกโมเดลอยู่แล้ว ซึ่งบ่งชี้ว่าเทคโนโลยีนี้ได้พิสูจน์ความเป็นไปได้ในการผลิตแล้ว

เกินกว่าการค้นหาธรรมดา

การเล่นที่กว้างขึ้นที่นี่มุ่งเป้าไปที่เวิร์กโฟลว์ AI แบบ agentic ที่ตัวแทนอัตโนมัติดำเนินการงานหลายขั้นตอน คุณภาพของข้อมูลที่ประมวลผลมีความสำคัญมากขึ้นเมื่อตัวแทนพึ่งพาเอกสารที่แม่นยำเพื่อทำการแทนผู้ใช้ องค์กรที่สร้างสถาปัตยกรรมที่ปรับขนาดได้ตอนนี้วางตำแหน่งตัวเองสำหรับห่วงโซ่การอนุมานขั้นสูงด้วยการเรียก LLM แบบต่อเนื่องหลายครั้ง

แพลตฟอร์ม Red Hat OpenShift AI และ Anyscale ให้ตัวเลือกการนำไปใช้งานที่มีข้อกำหนดการกำกับดูแลขององค์กร พื้นฐานแบบโอเพนซอร์สหมายความว่าทีมสามารถเริ่มทดสอบได้โดยไม่มีอุปสรรคด้านการจัดซื้อที่สำคัญ

สำหรับทีม AI ที่กำลังใช้เวลากับการเตรียมข้อมูลมากกว่าการปรับแต่งโมเดล การรวมระบบนี้มอบเส้นทางที่ใช้งานได้จริงไปข้างหน้า คำถามไม่ใช่ว่าการประมวลผลเอกสารแบบกระจายมีความสำคัญหรือไม่ แต่เป็นว่าโครงสร้างพื้นฐานของคุณสามารถรองรับสิ่งที่จะเกิดขึ้นต่อไปได้หรือไม่

แหล่งที่มาของภาพ: Shutterstock