ทำความเข้าใจ RAGFlow: สร้างแอป RAG สำหรับงานโปรดักชัน

เคยไหมที่สร้างเดโม RAG ซึ่งทำงานได้ดีเยี่ยมกับ PDF สะอาด ๆ ไม่กี่ไฟล์ แต่พอเจอเอกสารจริงขององค์กรกลับตอบอะไรไม่ได้?

สิ่งที่มักเกิดขึ้นคือ ตารางถูกแปลงจนแบน หน้าเอกสารสแกนหายไป สไลด์เด็คสูญเสียหัวข้อ และลอจิกการแบ่งชังก์แยกหัวข้อออกจากเนื้อหา ระบบ RAG สำหรับงานโปรดักชันไม่ได้เป็นแค่ LLM กับเวกเตอร์ดาต้าเบส แต่ต้องมีการแยกวิเคราะห์เอกสาร กลยุทธ์การแบ่งชังก์ การดึงค้นแบบไฮบริด รีแรงก์กิ้ง การติดตามการอ้างอิง การประสานงานเอเจนต์ และองค์ประกอบอีกหลายอย่างที่ต้องตั้งค่าด้วยตนเอง

RAGFlow เป็นแพลตฟอร์มโอเพนซอร์สที่รวมองค์ประกอบเหล่านั้นไว้ในสแตกเดียว จัดการการแยกวิเคราะห์เอกสารเชิงลึก การแบ่งชังก์ตามเทมเพลต การดึงค้นแบบไฮบริด เวิร์กโฟลว์ของเอเจนต์ และการผสาน MCP ภายใต้ UI และ API เดียว ซึ่งหมายความว่าสามารถโฟกัสกับคลังความรู้ของตนเองโดยไม่ต้องกังวลอย่างอื่น

ในบทความนี้ เราจะพาไปดูการทำงานภายในของ RAGFlow สถาปัตยกรรม การเปรียบเทียบกับ LangChain และ LlamaIndex และวิธีการดีพลอย

หากต้องการทบทวนการทำงานของ RAG ลงทะเบียนคอร์ส Retrieval Augmented Generation (RAG) with LangChain จะเข้าใจพื้นฐานได้ภายในบ่ายเดียว

RAGFlow คืออะไร?

RAGFlow เป็นเอนจิน RAG แบบโอเพนซอร์สที่สร้างโดย InfiniFlow และปล่อยภายใต้สัญญาอนุญาต Apache 2.0 ในเดือนเมษายน 2024

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

สิ่งที่ทำให้ RAGFlow ต่างจากเครื่องมือ RAG ส่วนใหญ่คือเป็นสแตกครบชุด ได้ทั้งการแยกวิเคราะห์เอกสาร การแบ่งชังก์ตามเทมเพลต การดึงค้นแบบไฮบริด รีแรงก์กิ้ง การติดตามการอ้างอิง ตัวสร้างเวิร์กโฟลว์ของเอเจนต์ และรองรับ MCP ในระบบเดียว ไม่ต้องเลือกเวกเตอร์ดาต้าเบส ตั้งค่าตัวพาร์เซอร์ เพิ่มรีแรงก์เกอร์ และสร้าง UI ทับอีกชั้น ทุกอย่างอยู่หลังเว็บอินเทอร์เฟซและ API เดียว

ดังนั้น RAGFlow จึงใกล้เคียงแพลตฟอร์มมากกว่ากรอบงาน

RAGFlow ทำงานอย่างไร

RAGFlow ทำตามไปป์ไลน์ RAG มาตรฐาน แต่ทุกขั้นเป็นคอมโพเนนต์ที่ตั้งค่าได้ แทนที่จะต้องเขียนโค้ดเอง

ตั้งแต่คุณอัปโหลดเอกสารจนถึง LLM ส่งคำตอบกลับ เกิดอะไรขึ้นบ้าง:

1. นำเข้าเอกสาร: อัปโหลดไฟล์หรือเชื่อมต่อแหล่งข้อมูล RAGFlow รองรับ PDF ไฟล์ Word ชีต Excel เด็ค PowerPoint Markdown HTML รูปภาพ และไฟล์สแกน ตั้งแต่ v0.25 เป็นต้นไป ยังซิงก์ข้อมูลจาก Confluence, S3, Notion, Discord และ Google Drive ได้ด้วย
2. แยกวิเคราะห์และจัดโครงสร้างเนื้อหา: เอนจิน DeepDoc อ่านแต่ละไฟล์ด้วย OCR การรู้จำโครงสร้างตาราง และการรู้จำเลย์เอาต์ ผลลัพธ์คือเนื้อหาที่มีโครงสร้างพร้อมเมตาดาต้าเกี่ยวกับหัวข้อ ตาราง รูป และลำดับการอ่าน
3. สร้างเอ็มเบดดิง: RAGFlow ส่งแต่ละชังก์ผ่านโมเดลเอ็มเบดดิงที่เลือกในคอนฟิก ใช้ OpenAI Cohere Voyage โมเดลโลคัล หรืออย่างอื่นที่รองรับก็ได้
4. จัดทำดัชนีความรู้: ชังก์และเวกเตอร์ถูกเก็บในเอนจินเอกสาร โดยค่าเริ่มต้นคือ Elasticsearch แต่สามารถสลับไปใช้ Infinity ซึ่งเป็นดาต้าเบสของ InfiniFlow ที่สร้างมาเพื่อการค้นหาแบบไฮบริด
5. ดึงค้นบริบทที่เกี่ยวข้อง: เมื่อมีคิวรีเข้ามา RAGFlow จะรันการค้นหาแบบเวกเตอร์ การค้นหาคีย์เวิร์ด BM25 และรีแรงก์กิ้งร่วมกัน ได้ชังก์อันดับต้น ๆ พร้อมการอ้างอิงกลับไปยังเอกสารต้นทาง
6. สร้างคำตอบด้วย LLM: นำชังก์ที่ดึงมาใส่ในพรอมป์ต ให้ LLM เขียนคำตอบ และ RAGFlow จะผนวกการอ้างอิงเพื่อให้ผู้ใช้ตรวจย้อนกลับได้ทุกข้ออ้างอิงถึงแหล่งที่มา

ลำดับขั้นไม่มีอะไรใหม่ สิ่งสำคัญคือทุกขั้นเป็นชิ้นส่วนที่ตั้งค่าได้ของแพลตฟอร์ม และตรวจสอบผลลัพธ์ได้ทุกช่วง

สถาปัตยกรรมของ RAGFlow

สถาปัตยกรรมของ RAGFlow มี 4 เลเยอร์ โดยแต่ละเลเยอร์แก้ปัญหาเฉพาะในไปป์ไลน์ RAG ต่อไปนี้คือภาพรวมแบบเร็ว ๆ :

แสดงภาพสถาปัตยกรรม RAGFlow

ต่อไปจะอธิบายทีละเลเยอร์

การนำเข้าเอกสาร

นี่คือจุดเริ่มต้น RAGFlow รองรับ PDF เอกสาร Office อย่าง Word, Excel, PowerPoint ไฟล์ Markdown และหน้าเว็บ ไฟล์สแกนและรูปภาพก็ใช้ได้ เพราะมี OCR ในตัว

สามารถอัปโหลดไฟล์ผ่าน UI เชื่อมต่อคลาวด์ซอร์ส หรือส่งเอกสารผ่าน API เลเยอร์ ingestion จะทำให้ทุกอย่างอยู่ในฟอร์แมตกลางก่อนเข้าสู่ขั้นถัดไป

การประมวลผลความรู้

จุดนี้คือที่ที่ DeepDoc เข้ามามีบทบาท

การแยกวิเคราะห์จะแปลงไฟล์ดิบให้เป็นเนื้อหาที่มีโครงสร้างพร้อมหัวข้อ ย่อหน้า ตาราง และรูปภาพ การแบ่งชังก์จะแยกเนื้อหาเป็นหน่วยสำหรับการดึงค้นตามเทมเพลตที่เลือก (General, Paper, Book, Q&A, Manual, Table หรือ Naive) การดึงเมตาดาต้าจะผูกบริบทกับแต่ละชังก์ เช่น หมายเลขหน้า ชื่อหัวข้อ และตำแหน่งบนหน้า

ชังก์ที่ได้จากเลเยอร์นี้ยังคงโครงสร้างเดิมไว้ หมายความว่าตารางยังคงเป็นตาราง หัวข้ออยู่กับส่วนของมัน และคำบรรยายรูปอยู่กับรูป ไม่ดูสุ่มเหมือนกลยุทธ์แบ่งชังก์แบบดั้งเดิมของ RAG

เอนจินการดึงค้น

เอนจินดึงค้นทำงานอยู่บน Elasticsearch หรือ Infinity ขึ้นกับเอนจินเอกสารที่ตั้งค่าไว้

จะรันการค้นหา 3 แบบพร้อมกัน:

• การค้นหาแบบเวกเตอร์ เพื่อความใกล้เคียงเชิงความหมาย
• การค้นหาคีย์เวิร์ดแบบ BM25 เพื่อจับคู่วลีตรงตัว
• รีแรงก์กิ้ง ทับบนผลลัพธ์ที่ผสานแล้วเพื่อดันชังก์ที่เกี่ยวข้องมากที่สุดขึ้นมา

เลเยอร์นี้จะคัดชังก์คุณภาพสูงจำนวนน้อยสำหรับใส่ในพรอมป์ตของ LLM

เลเยอร์ LLM

เลเยอร์ LLM ส่งชังก์ที่ดึงได้ไปยังโมเดลที่เชื่อมต่อไว้ ไม่ว่าจะเป็น OpenAI, DeepSeek, Gemini, Claude โมเดลโลคัลผ่าน Ollama หรืออย่างอื่นที่ RAGFlow รองรับ

คำตอบจะมาพร้อมการอ้างอิง ทุกข้อความอ้างในคำตอบจะชี้ไปยังชังก์เฉพาะ และแต่ละชังก์ชี้ไปยังตำแหน่งเฉพาะในเอกสารต้นทาง นี่คือสิ่งที่ RAGFlow เรียกว่า คำตอบที่ยึดโยงหลักฐาน (grounded answers) ผู้ใช้คลิกการอ้างอิงเพื่อเห็นข้อความที่มาได้ทันที ทำให้ตรวจจับการเพ้อฝันได้ง่าย

ทั้งสี่เลเยอร์ทำงานเป็นไปป์ไลน์ ตั้งแต่ ingestion ป้อนให้ knowledge processing แล้วไปที่เอนจินดึงค้น และสุดท้ายป้อนไปยังเลเยอร์ LLM

คุณสมบัติเด่นของ RAGFlow

ต่อไปนี้คือฟีเจอร์ที่สำคัญที่สุดเมื่อสร้างระบบ RAG บนเอกสารจริงที่ยุ่งเหยิง

การแยกวิเคราะห์เอกสารขั้นสูง

พาร์เซอร์ของ RAGFlow เรียกว่า DeepDoc และนี่คือเหตุผลที่แพลตฟอร์มนี้เกิดขึ้น

DeepDoc รันโมเดลวิชัน 3 แบบบนเอกสารแต่ละไฟล์: OCR สำหรับดึงข้อความ TSR สำหรับรู้จำโครงสร้างตาราง และ DLR สำหรับรู้จำเลย์เอาต์เอกสาร แทนที่จะมอง PDF เป็นสตรีมตัวอักษร มันอ่านไฟล์แบบที่มนุษย์อ่าน เห็นว่าตารางอยู่ตรงไหน คอลัมน์คั่นตรงไหน ข้อความใดเป็นหัวข้อ และข้อความใดเป็นเชิงอรรถ

โครงสร้างนั้นจะไหลเข้าสู่ชังก์ ตารางยังอยู่กับเฮดเดอร์ เลย์เอาต์หลายคอลัมน์ถูกอ่านตามลำดับที่ถูกต้อง และรูปภาพยังคงคำบรรยายไว้

หากเคยลองทำเอง จะรู้ว่าทำส่วนนี้ให้ดีในเอกสารหลายประเภทและในสเกลใหญ่เป็นเรื่องยากมาก

การดึงค้นแบบไฮบริด

การค้นหาเชิงความหมายมักพลาดคิวรีที่คำตรงตัวมีความสำคัญ ส่วนการค้นหาคีย์เวิร์ดล้วน ๆ ก็พลาดเมื่อความหมายสำคัญแต่ถ้อยคำต่างกัน

RAGFlow รันทั้งสองพร้อมกัน:

• การค้นหาแบบเวกเตอร์ จับคู่เชิงความหมาย — "revenue" จะหา "sales" และ "income" เจอ
• การค้นหาคีย์เวิร์ด จับคู่ตรงตัว — โค้ดสินค้า หรือคำกฎหมายจะถูกพบแม้โมเดลเอ็มเบดดิงจะไม่เข้าใจก็ตาม
• รีแรงก์กิ้ง นำผลรวมมาจัดลำดับใหม่ด้วยโมเดลเฉพาะ เพื่อให้ชังก์บนสุดเกี่ยวข้องจริง

ตัวสร้างเวิร์กโฟลว์

ตัวสร้างเวิร์กโฟลว์เป็นผืนผ้าใบแบบภาพที่ตั้งค่าไปป์ไลน์ได้โดยไม่ต้องเขียนโค้ด

เพียงลากคอมโพเนนต์ลงผืนผ้าใบ— retrieval, rerank, LLM, รันโค้ด, HTTP calls, การวนซ้ำ, เงื่อนไข—แล้วเชื่อมเป็นโฟลว์ RAGFlow มีเทมเพลตสำเร็จรูปสำหรับแพตเทิร์นยอดนิยม เช่น Retrieve - Rerank - Answer, Deep Research และ Data Analytics

สำหรับทีมที่ไม่ค่อยมีวิศวกร วิธีนี้ช่วยสร้างต้นแบบที่ใช้งานได้ภายในสัปดาห์เดียว

รองรับเอเจนต์

ตั้งแต่ v0.20 RAGFlow รองรับเวิร์กโฟลว์แบบเอเจนต์เต็มรูปแบบบนผืนผ้าใบเดียวกับเวิร์กโฟลว์ทั่วไป

คอมโพเนนต์เอเจนต์สามารถวางแผน สะท้อนความคิด เรียกใช้เครื่องมือ และมอบหมายให้ซับเอเจนต์ได้ ตั้งค่าพรอมป์ตและรายชื่อเครื่องมือ แล้วเอเจนต์จะตัดสินใจขณะรันว่าควรเรียกใช้เครื่องมือใดและเรียงลำดับอย่างไร เครื่องมืออาจเป็นคอมโพเนนต์ในตัว เซิร์ฟเวอร์ MCP ที่เชื่อมไว้ หรือเอเจนต์อื่น

คุณค่าคือการใช้เหตุผลบนความรู้ที่ดึงมา

เอเจนต์ซัพพอร์ตสามารถดึงจากคลังความรู้ เรียก API ภายนอกเพื่อตรวจสถานะทิกเก็ต และตัดสินใจว่าจะยกระดับหรือไม่ ทั้งหมดในโฟลว์เดียว โดยแนบการอ้างอิงกับส่วนที่มาจากเอกสาร

การแยกวิเคราะห์เอกสารและการสกัดความรู้

คุณภาพการดึงค้นเริ่มจากคุณภาพการแยกวิเคราะห์ หากพลาดส่วนนี้ ต่อให้มีรีแรงก์เกอร์หรือ LLM ใหญ่แค่ไหนก็ช่วยไม่ได้

ความล้มเหลวของ RAG ส่วนใหญ่อยู่ระดับเอกสาร เช่น PDF ที่เต็มไปด้วยตารางถูกดึงออกมาเป็นค่าคั่นด้วยจุลภาค หรือสไลด์เด็คสูญเสียลำดับชั้นภาพ เมื่อชังก์เหล่านั้นไปถึงเวกเตอร์ดาต้าเบส ก็ไม่มีมูลค่าเหลือ

แนวทางของ RAGFlow คือยกระดับการแยกวิเคราะห์ให้เป็นปัญหาหลัก

ตาราง

ตารางคือส่วนที่ยากที่สุดของการแยกวิเคราะห์เอกสาร พาร์เซอร์ PDF มาตรฐานจะอ่านทีละแถวและกลายเป็นสตรีมตัวเลขที่ไม่มีเฮดเดอร์ติดมาด้วย โครงสร้างจึงหายไป

DeepDoc รันการรู้จำโครงสร้างตาราง (TSR) ก่อนการแบ่งชังก์ ระบุตำแหน่งขอบเขตตาราง แถวหัวตาราง คอลัมน์ และความสัมพันธ์ของเซลล์ เมื่อเครื่องมือแบ่งชังก์เอกสารถูกแยก ตารางจะยังคงอยู่ครบกับเฮดเดอร์ และแต่ละแถวเก็บบริบทของตนเองไว้

รูปภาพและไฟล์สแกน

DeepDoc ใช้ OCR เพื่อดึงข้อความจากหน้าที่สแกน และตั้งแต่ v0.19 เป็นต้นไป สามารถใช้โมเดลวิชัน-ภาษาช่วยตีความรูปภาพภายในไฟล์ PDF และ DOCX ได้

นั่นหมายความว่า ไดอะแกรม กราฟ หรือรูปถ่ายใบเสร็จสามารถกลายเป็นเนื้อหาที่ค้นหาได้

เลย์เอาต์หลายคอลัมน์

งานวิชาการและรายงานการเงินมักใช้เลย์เอาต์หลายคอลัมน์ พาร์เซอร์แบบง่ายจะอ่านจากซ้ายไปขวา ทีละบรรทัด ทำให้ผสมคอลัมน์เข้าด้วยกันและได้เนื้อหาที่ไม่สมเหตุสมผล

DeepDoc ใช้การรู้จำเลย์เอาต์เอกสาร (DLR) เพื่อหาลำดับการอ่านก่อน รู้ว่าคอลัมน์ 1 มาก่อนคอลัมน์ 2 และหัวข้อครอบทั้งสองคอลัมน์

เมตาดาต้า

ทุกชังก์จะมาพร้อมเมตาดาต้า เช่น หมายเลขหน้า ชื่อหัวข้อ ตำแหน่งบนหน้า และไฟล์ต้นทางที่มาของชังก์นั้น

นี่คือสิ่งที่ทำให้มีการอ้างอิงได้ เมื่อ LLM อ้างข้อความ RAGFlow จะชี้กลับไปยังหน้าที่แน่นอนและตำแหน่งในเอกสารต้นทาง อีกทั้งยังทำให้กรองระดับชังก์ได้ เช่น ค้นหาเฉพาะในส่วนหนึ่งหรือเอกสารหนึ่ง

คุณภาพของชังก์

ชิ้นส่วนสุดท้ายคือการแบ่งชังก์เอง RAGFlow ใช้การแบ่งชังก์ตามเทมเพลต ซึ่งให้เลือกเทมเพลตที่ตรงกับประเภทเอกสาร (General, Paper, Book, Q&A, Manual, Table หรือ Naive)

แต่ละเทมเพลตมีกฎการแบ่งต่างกัน เทมเพลต Paper แยกบทคัดย่อ วิธีการ และผลลัพธ์เป็นหน่วยต่างหาก เทมเพลต Q&A เก็บคำถามกับคำตอบไว้ด้วยกัน เทมเพลต Manual เคารพหัวข้อและขั้นตอน คุณคงพอเห็นภาพ

ผลลัพธ์คือชังก์ที่มีความหมายในตัวเอง เมื่อนำไปใส่ในหน้าต่างบริบทของ LLM ก็มีข้อมูลพอที่จะตอบคำถามได้

การดึงค้นใน RAGFlow

เมื่อเอกสารถูกแยกวิเคราะห์และแบ่งชังก์แล้ว ขั้นดึงค้นจะเป็นตัวตัดสินว่า LLM จะเห็นบริบทที่ถูกต้องหรือไม่ เอนจินดึงค้นของ RAGFlow มีสามส่วนทำงานร่วมกัน

การดึงค้นแบบเวกเตอร์

การค้นหาแบบเวกเตอร์จะจับความใกล้เคียงเชิงความหมาย นำคิวรีและแต่ละชังก์ไปเอ็มเบดด้วยโมเดลเดียวกัน เอนจินจะคืนชังก์ที่เวกเตอร์อยู่ใกล้กับเวกเตอร์คิวรีมากที่สุด

นี่ทำให้การค้นหา "revenue growth" เจอชังก์เกี่ยวกับ "sales increase" ได้ แม้ไม่มีคำตรงกัน RAGFlow ให้เลือกโมเดลเอ็มเบดดิงได้ เช่น OpenAI Cohere Voyage BGE หรือโมเดลโลคัล และเปลี่ยนภายหลังได้โดยไม่ต้องสร้างระบบใหม่ทั้งหมด

การค้นหาแบบไฮบริด

การค้นหาแบบเวกเตอร์ไม่เหมาะกับคำที่ต้องตรงตัว สิ่งอย่างโค้ดสินค้า หรือการอ้างอิงทางกฎหมายอาจไม่มีสัญญาณเชิงความหมายแรง แต่การจับคู่สตริงตรงตัวสำคัญมาก

RAGFlow รันการค้นหาคีย์เวิร์ด BM25 คู่กับการค้นหาแบบเวกเตอร์และรวมผลลัพธ์เข้าด้วยกัน ได้ทั้งการเรียกคืนเชิงความหมายของเอ็มเบดดิงและความแม่นยำของการจับคีย์เวิร์ดในคิวรีเดียว

รีแรงก์กิ้ง

รอบแรกของการดึงค้นจะได้ชุดผู้สมัครกลับมา โดยมากคือ 30 หรือ 50 ชังก์ ซึ่งมากเกินสำหรับหน้าต่างบริบทของ LLM และอันดับต้นมักมีนอยส์

รีแรงก์กิ้งจะนำชุดนั้นมาจัดลำดับใหม่ด้วยโมเดลเฉพาะที่อ่านคิวรีและแต่ละชังครับกัน รีแรงก์เกอร์รู้ว่าอะไรเกี่ยวข้องกับคิวรี ไม่ใช่แค่คล้ายกัน อันดับ 5 หรือ 10 อันดับแรกหลังรีแรงก์จะถูกส่งเข้าไปในพรอมป์ต

การคัดเลือกบริบท

ขั้นสุดท้ายคือตัดสินใจว่าจะใส่อะไรในบริบทของ LLM RAGFlow ให้ตั้งค่าจำนวนชังก์ เกณฑ์ความคล้าย และคะแนนรีแรงก์เกอร์ขั้นต่ำได้

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

เป้าหมายของเอนจินดึงค้นคือให้ LLM ได้บริบทที่ต้องการพอดี ไม่มากหรือน้อยเกินไป

RAGFlow เทียบกับไปป์ไลน์ RAG แบบดั้งเดิม

ไปป์ไลน์ RAG แบบดั้งเดิมประกอบจากเครื่องมืออิสระ เลือกพาร์เซอร์ (Unstructured, LlamaParse, PyMuPDF) ตัวแบ่งชังก์ (LangChain text splitters โค้ดเอง) โมเดลเอ็มเบดดิง เวกเตอร์ดาต้าเบส (Pinecone, Weaviate, Chroma, Qdrant) รีแรงก์เกอร์ (Cohere, BGE) ไคลเอนต์ LLM และ UI จากนั้นเขียนโค้ดที่ประกอบทั้งหมดเข้าด้วยกัน

แนวทางนี้ให้การควบคุมสูงสุด แต่ต้องใช้แรงวิศวกรรมมาก

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

RAGFlow เลือกแนวทางตรงข้าม

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

สิ่งที่แลกมาคือความยืดหยุ่น หากต้องการเปลี่ยนเป็นอัลกอริทึมแบ่งชังก์แบบใหม่หรือรีแรงก์เกอร์เชิงวิจัย จะต้องทำงานภายใต้โมเดลปลั๊กอินของ RAGFlow แทนการเขียน Python สำหรับงานโปรดักชันส่วนใหญ่ก็เพียงพอ แต่สำหรับงานเชิงทดลองอาจรู้สึกจำกัด

สรุปความแตกต่าง:

ไม่มีแนวทางใดดีกว่าโดยสิ้นเชิง หากมีเวลาทางวิศวกรรมและต้องการควบคุมเต็มที่ ไปป์ไลน์แบบดั้งเดิมคือคำตอบ หากต้องการโฟกัสกับคลังความรู้ RAGFlow จะเร็วกว่ามาก

RAGFlow เทียบกับ LangChain และ LlamaIndex

หากพิจารณา RAGFlow อยู่ น่าจะเคยได้ยิน LangChain และ LlamaIndex แล้ว ต่อไปนี้คือการเปรียบเทียบ

LangChain

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

หากโปรเจ็กต์เน้นเอเจนต์มาก—การเรียกเครื่องมือ การให้เหตุผลหลายขั้น ลอจิกแตกแขนง มนุษย์มีส่วนร่วม—LangChain (และเลเยอร์ state machine อย่าง LangGraph) เป็นตัวเลือกที่ทีมส่วนใหญ่ใช้

LlamaIndex

LlamaIndex เป็นกรอบงานด้านข้อมูลสำหรับ LLM มุ่งเน้นการนำเข้าข้อมูล สร้างดัชนี และคิวรีให้ดี LlamaIndex มีคอนเน็กเตอร์ข้อมูลกว่า 160 รายการ ประเภทดัชนีหลายแบบ (เวกเตอร์ คีย์เวิร์ด ต้นไม้ กราฟความรู้) และดีฟอลต์ที่เหมาะสมสำหรับการแบ่งชังก์และดึงค้น

หากโปรเจ็กต์เน้นการดึงค้น มีเอกสารจำนวนมาก ต้องการค้นหาลึก และมีแหล่งข้อมูลหลายระบบ LlamaIndex เป็นตัวเลือกแบบโค้ดเฟิร์สต์ที่แข็งแกร่งที่สุด

RAGFlow

RAGFlow เป็นแพลตฟอร์ม RAG แบบบูรณาการ ไม่ใช่ไลบรารีให้ import มาใช้ใน Python แต่เป็นระบบที่ต้องดีพลอย มีการแยกวิเคราะห์ แบ่งชังก์ ดึงค้น รีแรงก์กิ้ง การอ้างอิง เวิร์กโฟลว์ เอเจนต์ และเว็บ UI มาพร้อม

หากต้องการให้ระบบ RAG ระดับโปรดักชันทำงานกับเอกสารยุ่งเหยิงโดยไม่ต้องเขียนโค้ดไปป์ไลน์ตั้งแต่ศูนย์ RAGFlow คือทางที่เร็วที่สุด

ทั้งสามเครื่องมือผสมกันได้ด้วย แพตเทิร์นทั่วไปคือ LlamaIndex สำหรับ ingestion, LangChain หรือ LangGraph สำหรับประสานเอเจนต์ และ RAGFlow เมื่ออยากได้สแตกแบบครบถ้วนที่โฮสต์เองแทนการเขียนโค้ดด้วยมือ

สรุปอีกครั้ง:

การสร้างแอป RAG ด้วย RAGFlow

เมื่อ RAGFlow ทำงานแล้ว การสร้างแอป RAG มี 5 ขั้น โดยไม่ต้องเขียนโค้ดไปป์ไลน์ เพียงตั้งค่าทุกขั้นผ่าน UI หรือ API

นำเข้าเอกสาร

เริ่มจากอัปโหลดเอกสาร เพิ่มไฟล์ผ่านเว็บ UI เชื่อมต่อแหล่งข้อมูลอย่าง Google Drive, S3, Notion, Confluence หรือ Discord หรือเพิ่มไฟล์ผ่าน API

ตัวอย่างการนำเข้าเอกสาร

RAGFlow รองรับฟอร์แมตส่วนใหญ่ จึงไม่ต้องแปลงไฟล์ล่วงหน้า

กำหนดค่าคลังความรู้

คลังความรู้ใน RAGFlow คือคอนเทนเนอร์สำหรับเอกสาร ชังก์ และการตั้งค่า เลือกเทมเพลตชังก์ที่ตรงกับเอกสาร (General สำหรับเนื้อหาผสม Paper สำหรับงานวิจัย Manual สำหรับเอกสารเทคนิค Q&A สำหรับทิกเก็ตซัพพอร์ต เป็นต้น) เลือกโมเดลเอ็มเบดดิง และเลือกพาร์เซอร์

การกำหนดค่าคลังความรู้

ขั้นนี้สำคัญมาก เลือกเทมเพลตดี จะลดปัญหาในภายหลังได้มาก

เลือกกลยุทธ์การดึงค้น

จากนั้นตัดสินใจว่าการดึงค้นจะทำงานอย่างไร ตั้งค่าจำนวนชังก์บนสุด เกณฑ์ความคล้าย และว่าจะใช้การค้นหาแบบไฮบริดหรือเฉพาะเวกเตอร์ เปิดรีแรงก์กิ้งและเลือกโมเดลรีแรงก์เกอร์ได้

สำหรับกรณีก้าวหน้า RAGFlow รองรับ RAPTOR สำหรับการสรุปแบบลำดับชั้น และกราฟความรู้สำหรับการดึงค้นเชิงเอนทิตี เปิดใช้ได้ในคอนฟิกคลังความรู้

เชื่อมต่อ LLM

RAGFlow ไม่ได้รวม LLM มาให้ ต้องนำมาเอง—OpenAI, DeepSeek, Gemini, Claude โมเดลโลคัลผ่าน Ollama หรืออย่างอื่นที่รองรับ

ตัวเลือกโมเดล

เพิ่มคีย์ API ในการตั้งค่า เลือกโมเดล และกำหนด system prompt

ทดสอบคำตอบ

ขั้นสุดท้ายคือการทดสอบ RAGFlow มีอินเทอร์เฟซแชตสำหรับคิวรีคลังความรู้และดูคำตอบพร้อมการอ้างอิง

คลิกการอ้างอิงใด ๆ จะพาไปยังชังก์นั้นทันทีพร้อมไฮไลต์ตำแหน่งในเอกสารต้นทาง

ส่วนใหญ่ทีมจะวนลูปนี้สองสามรอบกว่าคำตอบจะใช้ได้ เป็นเรื่องปกติของทุกระบบ RAG แต่กับ RAGFlow จะเปลี่ยนการตั้งค่าใน UI แทนการเขียน Python ใหม่

ตัวอย่างการตั้งค่าแชต

RAGFlow ในงานโปรดักชัน

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

คลังความรู้ระดับองค์กร

องค์กรขนาดใหญ่มีเอกสารนับพันกระจายอยู่ตามไดรฟ์แชร์ Confluence SharePoint และ PDF ในอีเมล พนักงานมักหาไม่เจอ และถาม LLM โดยไม่มี RAG ก็นำไปสู่การเพ้อฝัน

RAGFlow ทำงานได้ดีในบริบทนี้

PDF เก่า ๆ นโยบายที่สแกนไว้ ชีต Excel พร้อมพิวอตเทเบิล สไลด์ PowerPoint เมื่อหลายปีก่อน—ทั้งหมดถูกพาร์เซ และด้วยการอ้างอิง ทีมกฎหมายและคอมพลายแอนซ์จึงเชื่อถือคำตอบได้ อีกทั้งเว็บ UI ทำให้ผู้ที่ไม่ใช่วิศวกรดูแลคลังความรู้ได้

ผู้ช่วยฝ่ายสนับสนุนลูกค้า

ทีมซัพพอร์ตมีทิกเก็ตสะสมหลายปี คำถามที่พบบ่อย คู่มือผลิตภัณฑ์ และรันบุ๊กภายใน ผู้ช่วยต้องค้นหาทั้งหมดนั้น หาเนื้อหาที่ถูกต้อง และรู้ว่าเมื่อใดควรยกระดับเคส

เทมเพลตชังก์แบบ Q&A ของ RAGFlow ถูกสร้างมาสำหรับสิ่งนี้โดยตรง เพียงป้อนประวัติทิกเก็ต และมันจะมองแต่ละคู่คำถาม-คำตอบเป็นหน่วยดึงค้น หากเพิ่มเลเยอร์เอเจนต์ เชื่อม API สำหรับดูคำสั่งซื้อ ก็จะได้ผู้ช่วยที่จัดการคำถามทั่วไปและส่งต่อเคสยากพร้อมบริบทเต็ม

การค้นหาเอกสารภายใน

ทีมวิศวกรรมมีรันบุ๊ก เอกสารสถาปัตย์ โพสต์มอร์ตัมเหตุขัดข้อง และเอกสารอ้างอิง API กระจายอยู่ใน Notion, Confluence, และ GitHub การ grep ใช้ได้กับคีย์เวิร์ด แต่ไม่ช่วยกับคำถามแบบ "ครั้งล่าสุดที่แจ้งเตือนนี้เกิดขึ้น เราจัดการอย่างไร?"

RAGFlow ให้การค้นหาเชิงความหมายครอบคลุมทั้งคลัง พร้อมการอ้างอิงกลับไปยังต้นทาง ทำให้วิศวกรได้ทั้งข้อความที่เกี่ยวข้องและลิงก์ไปหน้าเดิมในคลิกเดียว

ผู้ช่วยงานวิจัย

ทีมวิจัยทำงานกับเปเปอร์ สิทธิบัตร รายงาน และการทดลองภายใน เทมเพลต Deep Research ใน RAGFlow ถูกออกแบบมาสำหรับสิ่งนี้ โดยมีการดึงค้นหลายรอบพร้อมการให้เหตุผลเป็นลำดับขั้น ที่เอเจนต์จะแตกคำถาม ค้นหาชิ้นส่วนคำตอบ และสังเคราะห์เข้าด้วยกัน

สำหรับงานวิจัยด้านการเงิน กฎหมาย และเภสัช การตามรอยทุกข้ออ้างอิงสู่แหล่งที่มา คือสิ่งที่ทำให้ผู้ช่วยใช้งานได้จริง

จุดร่วมของเคสเหล่านี้คือ เอกสารคือส่วนที่ยาก หากเนื้อหาต้นทางสะอาดและเรียบง่าย เครื่องมือ RAG ส่วนใหญ่ก็ใช้ได้ แต่ถ้ายุ่งเหยิงและมีโครงสร้าง เลเยอร์การพาร์เซของ RAGFlow จะพาคุณไปได้ไกลกว่าการเขียนไปป์ไลน์เอง

การดีพลอย RAGFlow

RAGFlow ให้เส้นทางดีพลอย 3 แบบ ต่อไปนี้คือรายละเอียด

ดีพลอยด้วย Docker

Docker Compose คือเส้นทางหลัก โคลน รีโป cd เข้าโฟลเดอร์ docker แล้วรัน docker compose up -d จะสตาร์ทเซิร์ฟเวอร์ RAGFlow พร้อม Elasticsearch, MinIO, MySQL และ Redis

สเปกต่ำสุดคือ CPU 4 คอร์ RAM 16 GB และดิสก์ 50 GB ในการใช้งานจริงควรมี RAM มากกว่านี้หากรันคอลเลกชันเอกสารใหญ่ เพราะ Elasticsearch และ Infinity ใช้หน่วยความจำมาก

อิมเมจ Docker เล็งเป้าไปที่ x86 ควรทราบไว้ หากใช้ Apple Silicon หรือ ARM64 อื่น ๆ เลเยอร์แปลจะช่วยให้รันได้ แต่เพื่อประสิทธิภาพที่ดีกว่า ควรบิลด์อิมเมจเองตามคู่มือ ARM64 ในเอกสาร RAGFlow

การพัฒนาบนเครื่อง

หากต้องการแก้ซอร์สโค้ดของ RAGFlow สามารถรันแบ็กเอนด์และฟรอนต์เอนด์จากซอร์ส ใช้ uv สำหรับดีเพนเดนซี Python รัน docker compose -f docker/docker-compose-base.yml up -d เพื่อสตาร์ทเฉพาะบริการประกอบ (MinIO, Elasticsearch, MySQL, Redis) จากนั้นสตาร์ทแบ็กเอนด์ด้วยสคริปต์เชลล์ และฟรอนต์เอนด์ด้วย npm run dev

เส้นทางนี้เหมาะเมื่อมีส่วนร่วมพัฒนาโปรเจ็กต์หรือแก้บั๊ก สำหรับผู้ใช้ส่วนใหญ่ Docker Compose เร็วกว่า

ดีพลอยบนคลาวด์

InfiniFlow มีเวอร์ชันโฮสต์ที่ cloud.ragflow.io มีระดับฟรีที่ให้ 5 แอปและ 500 เครดิตต่อเดือน และแพ็กเกจเสียเงินที่ $29, $129 และระดับองค์กร

เวอร์ชันคลาวด์เหมาะสำหรับต้นแบบและทีมเล็ก ๆ สำหรับงานโปรดักชันจริงที่มีข้อมูลอ่อนไหว ส่วนใหญ่เลือกโฮสต์เองบนโครงสร้างพื้นฐานของตน ไม่ว่าจะเป็น VM เดี่ยวสำหรับดีพลอยเล็ก หรือ Kubernetes ผ่าน Helm chart สำหรับงานใหญ่

ข้อพิจารณาด้านสเกล

ดีพลอยดีฟอลต์ของ RAGFlow รันทุกอย่างบนเครื่องเดียว ใช้ได้ถึงจุดหนึ่ง จากนั้นจะชนเพดานด้านจำนวนเอกสาร ปริมาณคิวรี หรือขนาดทีม

องค์ประกอบที่สเกลแยกกันได้คือเอนจินเอกสาร (Elasticsearch หรือ Infinity) ออบเจ็กต์สตอเรจ (MinIO) และตัวแอป RAGFlow สำหรับดีพลอยใหญ่ แยกบริการเหล่านี้ออกไปใช้หลายเครื่อง ใช้ Elasticsearch แบบจัดการหรือสตอเรจที่เข้ากันได้กับ S3 และรันอินสแตนซ์แอป RAGFlow หลายตัวหลังโหลดบาลานเซอร์

การเร่งด้วย GPU สำหรับ DeepDoc ก็น่าลอง อย่างที่ทราบ การพาร์เซใช้ CPU หนักโดยดีฟอลต์ แต่เปิดโหมด GPU ในคอนฟิกได้ ซึ่งสร้างความต่างอย่างมากเมื่อ ingest เอกสารจำนวนมาก

ส่วนที่เหลือเป็นงานโครงสร้างพื้นฐานมาตรฐาน และ RAGFlow ไม่ได้ขัดขวางสิ่งเหล่านั้น

ข้อดีและข้อจำกัดของ RAGFlow

ทุกเครื่องมือมีข้อแลกเปลี่ยน RAGFlow ก็เช่นกัน ต่อไปนี้คือสิ่งที่ควรรู้ก่อนใช้งาน

ข้อดี

• เป็นแพลตฟอร์มแบบบูรณาการ: ไม่ต้องเลือกพาร์เซอร์ เวกเตอร์ดาต้าเบส รีแรงก์เกอร์ ตัวแบ่งชังก์ และเฟรมเวิร์ก UI แล้วเขียนโค้ดประกอบ RAGFlow มีให้ครบ
• การประมวลผลเอกสารคือจุดแข็งที่สุด: DeepDoc จัดการ PDF ไฟล์สแกน ตาราง และเลย์เอาต์ซับซ้อนได้ดีกว่าทางเลือกส่วนใหญ่ หากเอกสารยุ่งเหยิง แค่นี้ก็มักเพียงพอให้เลือก RAGFlow
• เน้นโปรดักชันตั้งแต่วันแรก: การอ้างอิงที่ยึดโยงหลักฐาน การแสดงชังก์ เวิร์กโฟลว์เอเจนต์ รองรับ MCP และ UI จัดการจริง มีมาให้ในตัว
• โอเพนซอร์สภายใต้ Apache 2.0: โฮสต์เองได้ ปรับแต่งโค้ดได้ และรันบนโครงสร้างพื้นฐานของตนเอง รีโป GitHub มีสตาร์กว่า 80k และพัฒนาอย่างต่อเนื่อง โปรเจ็กต์ไม่น่าจะหายไปไหนเร็ว ๆ นี้

ข้อจำกัด

• การดีพลอยไม่ได้ง่ายอย่างที่คิดแรก ๆ : Docker Compose ช่วยได้ แต่คุณยังต้องรัน Elasticsearch หรือ Infinity, MinIO, MySQL และ Redis ควบคู่กับแอป สักจุดหนึ่งย่อมมีปัญหา และต้องมีความรู้ Docker พอสมควรเพื่อแก้ไข
• ข้อกำหนดโครงสร้างพื้นฐาน: ขั้นต่ำคือ RAM 16 GB และ CPU 4 คอร์ แต่นั่นเหมาะกับงานเล็ก การใช้งานจริงต้องการ 32 GB ขึ้นไป โดยเฉพาะหากใช้ Infinity หรือรันงาน ingestion ใหญ่ ๆ การรัน RAGFlow บน VPS $5 ใช้ไม่ได้ผล
• มีเส้นโค้งการเรียนรู้: ตัวสร้างเวิร์กโฟลว์ทรงพลัง แต่มีคอมโพเนนต์มาก การหาเทมเพลตชังก์และการตั้งค่าดึงค้นที่เหมาะสมต้องใช้เวลา จะใช้เวลาสองสามวันกว่าจะคล่องและทำงานได้เต็มที่

ไม่มีข้อใดเป็นตัวตัดสิทธิ์หาก RAGFlow เหมาะกับเคสของคุณ มองว่าเป็นต้นทุนของการได้แพลตฟอร์มแทนไลบรารี

ใครควรใช้ RAGFlow?

RAGFlow ไม่เหมาะกับทุกโปรเจ็กต์ ต่อไปนี้คือกลุ่มที่เหมาะและกลุ่มที่ควรใช้สิ่งที่เบากว่า

เหมาะที่สุด

วิศวกร AI ที่สร้างระบบ RAG ระดับโปรดักชัน หากหน้าที่คือสร้างแอป RAG ให้ทำงาน ไม่ใช่เขียนไลบรารีแบ่งชังก์ใหม่ RAGFlow จะตัดงานเดินท่อส่วนใหญ่ให้

ทีม AI ในองค์กร ทีมกฎหมาย คอมพลายแอนซ์ การเงิน และซัพพอร์ตต้องการการอ้างอิงและการตามรอย อีกทั้ง UI ที่ผู้ไม่ใช่วิศวกรใช้งานได้ก็เป็นข้อดี

นักพัฒนาที่ทำงานกับเอกสารยุ่งเหยิง PDF ที่เต็มไปด้วยตาราง ไฟล์สแกน เลย์เอาต์หลายคอลัมน์ และฟอร์แมตผสม คือจุดที่ DeepDoc เหนือกว่าคู่แข่ง หากเนื้อหาต้นทางไม่ใช่ข้อความสะอาด คุณภาพการพาร์เซของ RAGFlow ยากจะเทียบ

องค์กรที่มีคอลเลกชันเอกสารขนาดใหญ่ เมื่อเกินไม่กี่พันเอกสาร จะต้องมีระบบที่ ingest ทำดัชนี และค้นหาได้ในสเกล RAGFlow คือเครื่องมือที่เหมาะสำหรับงานนี้

ไม่ค่อยเหมาะ

ต้นแบบแชตบอทง่าย ๆ หากแค่ต้องตอบคำถามจากไฟล์ Markdown สองสามไฟล์ RAGFlow จะเกินความจำเป็น สคริปต์ LlamaIndex หรือไปป์ไลน์ LangChain ง่าย ๆ จะเร็วกว่า

โปรเจ็กต์เล็กมาก สำหรับ Q&A ส่วนตัวเหนือ PDF ไม่กี่ไฟล์ ต้นทุนโครงสร้างพื้นฐานหนักเกินไป จะเสียเวลากับคำสั่ง Docker มากกว่างานจริง

ทีมที่ต้องการไม่ต้องตั้งค่าเลย หากอยากสมัครแล้วได้ RAG พร้อมใช้ใน 5 นาที บริการโฮสต์หรือไลบรารีน้ำหนักเบาจะเหมาะกว่า RAGFlow มีเวอร์ชันคลาวด์ แต่เส้นทางโฮสต์เอง (ซึ่งมีคุณค่ามากที่สุด) ต้องมีการตั้งค่าบ้าง

กฎจำง่าย ๆ คือ หากคุณภาพการดึงค้นบนเอกสารยุ่งเหยิงคือความท้าทายหลักของโปรเจ็กต์ RAGFlow คุ้มค่ากับต้นทุนการตั้งค่า หากไม่ใช่ ใช้เครื่องมือที่เบากว่า

บทสรุป

RAGFlow คือแพลตฟอร์มฟูลสแตกสำหรับสร้างแอป RAG ระดับโปรดักชันบนเอกสารโลกจริง

จุดแข็งที่สุดคือการประมวลผลเอกสาร การดึงค้น รีแรงก์กิ้ง และการสร้างคำตอบทำงานในเวิร์กโฟลว์เดียว แทนที่จะประกอบจากเครื่องมือแยกชิ้น ได้การพาร์เซด้วย DeepDoc การดึงค้นแบบไฮบริด การอ้างอิงที่ยึดโยงหลักฐาน และเวิร์กโฟลว์เอเจนต์ภายใต้ UI และ API เดียว

หากเอกสารยุ่งเหยิงและคุณภาพการดึงค้นสำคัญ RAGFlow คุ้มค่าต้นทุนการตั้งค่า

เริ่มจากคลาวด์ฟรีหรือดีพลอยด้วย Docker บนเครื่อง ลองอัปโหลดเอกสารที่ยากที่สุดสองสามไฟล์ แล้วดูคำตอบที่ได้ วิธีนี้เร็วที่สุดในการประเมินว่าเหมาะกับเคสของคุณหรือไม่

สถาปัตยกรรม RAG ออกแบบให้เรียบง่าย แต่ไม่ได้แปลว่าใช้กับเคสซับซ้อนไม่ได้ อ่านบล็อกโพสต์ Advanced RAG Techniques เพื่อเรียนรู้เกี่ยวกับการดึงค้นแบบหนาแน่น รีแรงก์กิ้ง และการให้เหตุผลหลายขั้น