ประสบการณ์สร้าง Production RAG จากการประมวลผลเอกสารมากกว่า 5 ล้านรายการ

• ตลอด 8 เดือนของโครงการ RAG (Retrieval-Augmented Generation) ได้แยกแยะได้ว่าแนวทางใดได้ผลจริง และแนวทางใดเป็นการเสียเวลา
• ในช่วงแรกใช้ Langchain และ Llamaindex เพื่อทำต้นแบบให้เสร็จอย่างรวดเร็ว แต่เมื่อได้รับฟีดแบ็กจากผู้ใช้จริงก็พบข้อจำกัดด้านประสิทธิภาพ
• ปัจจัยที่ส่งผลต่อการปรับปรุงประสิทธิภาพการค้นหาเอกสารมากที่สุดคือ การสร้างคิวรี, reranking, กลยุทธ์การทำ chunking, การใช้ metadata และ query routing
• ในงานจริงมีการเลือกใช้ vector database, embedding, reranking, LLM ฯลฯ อย่างยืดหยุ่น และสร้าง custom pipeline ขึ้นมา
• ได้รวบรวมประสบการณ์และองค์ความรู้ทั้งหมดไว้ใน โอเพนซอร์สโปรเจกต์(agentset-ai/agentset) และเผยแพร่สู่สาธารณะ

---

ภาพรวมประสบการณ์สร้าง Production RAG ตลอด 8 เดือน

• แชร์ประสบการณ์ การสร้างและดูแลระบบ RAG บนชุดข้อมูลขนาดใหญ่ เช่น รวม 9 ล้านหน้า (Usul AI) และ 4 ล้านหน้า (บริษัท AI ด้านกฎหมายที่ไม่เปิดเผยชื่อแห่งหนึ่ง)
• ในช่วงแรกทำตาม YouTube tutorial แล้วเริ่มจาก Langchain ก่อนย้ายไป Llamaindex จนสร้างต้นแบบเสร็จในไม่กี่วัน แต่เมื่อ deploy จริงกลับพบปัญหา ประสิทธิภาพต่ำที่มีเพียงผู้ใช้เท่านั้นที่สังเกตได้
• หลังจากใช้เวลาหลายเดือนค่อย ๆ ปรับองค์ประกอบของระบบเป็นส่วน ๆ ก็สามารถไปถึงประสิทธิภาพที่เหมาะสมที่สุดได้

องค์ประกอบที่ช่วยเพิ่มประสิทธิภาพได้จริง (เรียงตาม ROI)

1. การสร้างคิวรี (Query Generation)

   • เนื่องจากคิวรีสุดท้ายของผู้ใช้ไม่สามารถบรรจุบริบททั้งหมดได้ จึงใช้ LLM ตรวจสอบบทสนทนาแล้วสร้างทั้ง semantic query และ keyword query หลายชุด
   • นำคิวรีเหล่านี้ไปประมวลผลแบบขนาน แล้วส่งต่อให้ reranker เพื่อให้ได้ผลทั้ง การขยายขอบเขตการค้นหาและการชดเชยอคติของ hybrid search

2. Reranking

   • reranking ที่ทำได้ด้วยโค้ดราว 5 บรรทัดสามารถส่งผลต่อประสิทธิภาพได้มากกว่าที่คาดมาก
   • ในกรณีที่ป้อน chunk จำนวนมาก (เช่น 50 ชิ้น) ขั้นตอนการจัดลำดับใหม่และคัดเลือกเฉพาะ chunk ส่วนบน (เช่น 15 ชิ้น) ให้ ROI สูงที่สุด
   • เพียงแค่ reranking อย่างเดียวก็สามารถชดเชยข้อบกพร่องของ pipeline ที่ออกแบบไม่ดีได้มากพอสมควร

3. กลยุทธ์การทำ Chunking (Chunking Strategy)

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

4. การใช้ Metadata ในอินพุตของ LLM

   • แทนที่จะส่งเฉพาะข้อความของ chunk เข้าไปใน LLM ก็เพิ่ม metadata (title, author เป็นต้น) เข้าไปด้วย ซึ่งช่วยปรับปรุงบริบทและคุณภาพคำตอบได้อย่างมาก

5. Query Routing

   • สำหรับประเภทคำถามที่ RAG ไม่สามารถตอบได้ (เช่น การสรุปบทความ หรือการขอข้อมูลผู้เขียน) มีการใช้ router แบบเบา เพื่อแยกคิวรีเหล่านั้นไปยังเส้นทางประมวลผลแบบ API+LLM

สแตกที่ใช้จริง (Our stack)

• Vector database: Azure → Pinecone → Turbopuffer (ราคาถูกและรองรับ keyword search โดยพื้นฐาน)
• การดึงข้อมูลเอกสาร: ใช้วิธีแบบ custom
• เครื่องมือสำหรับ chunking: โดยพื้นฐานใช้ Unstructured.io ส่วน pipeline ระดับองค์กรเป็น custom (มีเสียงชื่นชมว่า Chonkie ก็ดี)
• Embedding model: ใช้ text-embedding-large-3 (ยังไม่ได้ทดสอบรุ่นอื่น)
• Reranker: None → Cohere 3.5 → Zerank (ไม่ค่อยเป็นที่นิยม แต่ใช้งานจริงแล้วดีมาก)
• LLM: GPT 4.1 → GPT 5 → GPT 4.1 (ส่วนใหญ่ใช้ Azure credits)

การเปิดเป็นโอเพนซอร์สและบทสรุป

• สรุปผลการเรียนรู้และประสบการณ์ใช้งานจริงทั้งหมดไว้ใน โอเพนซอร์สโปรเจกต์agentset-ai/agentset
• เผยแพร่ภายใต้ MIT license จึงสามารถใช้งานได้อย่างอิสระและติดต่อสอบถามได้ (มีข้อมูลติดต่อให้)

[GN⁺]

ความเห็นจาก Hacker News

• รู้สึกว่าส่วนที่พูดถึงการสร้าง synthetic query นั้นสำคัญมาก เพราะในทางปฏิบัติผู้ใช้มักป้อนคำค้นได้ไม่แม่นยำมาก ช่วงแรกให้ LLM สร้าง synthetic query ขึ้นมา แต่ผลลัพธ์แปรผันมากตาม query ที่ถูกสร้างในแต่ละครั้ง จึงเปลี่ยนมาให้สร้าง query 3 เวอร์ชันที่หลากหลายภายในการเรียก LLM ครั้งเดียว แล้วค้นหาแบบขนาน ก่อนนำมาผสานเป็นรายการผลลัพธ์ที่แข็งแรงด้วย reciprocal rank fusion โดยการค้นหาใช้ hybrid dense + sparse bm25 เพราะใช้ dense อย่างเดียวจะอ่อนกับคำศัพท์เฉพาะทาง พอเพิ่ม reranker เข้าไปด้วย ปัญหาด้านการค้นหาส่วนใหญ่ก็แก้ได้
  • รู้สึกว่าน่าสนใจที่ใช้วิธี hybrid (bm25 + dense search) เพื่อชดเชยจุดอ่อนของโมเดล dense ที่ไม่เก่งคำศัพท์เทคนิค โมเดล v3 อย่าง SPLADE ที่บาลานซ์การค้นหาเชิงความหมายและเชิงคำศัพท์ได้ดีเองก็ดูมีประสิทธิภาพดี แต่ก็สงสัยอยู่เสมอว่าจะถูกแทนที่ด้วยโซลูชันที่เรียบง่ายกว่านี้ได้ไหม
  • เน้นว่ารายละเอียดอย่างการสร้าง/ปรับแต่ง query แบบนี้ สุดท้ายแล้วเป็นเรื่องที่ผู้ให้บริการโซลูชัน RAG อย่าง Amazon, Microsoft, OpenAI ควรเป็นฝ่ายดูแล
  • แม้ว่าวิธีเหล่านี้จะเป็น best practice ในปัจจุบันจริง แต่ก็ยังรู้สึกเหมือนขาดอะไรบางอย่างไปในเชิงกลยุทธ์เสริมที่จะดันประสิทธิภาพขึ้นไปอีกขั้น เช่น การเลือกแตกแขนง embedding model แบบเลือกตามกรณี หรือการผสม re-ranker หลายแบบ
  • ทิ้งท้ายด้วยข้อเสนอแนะว่า หากส่งต่อให้ผู้ใช้เห็นด้วยว่า LLM ตีความเจตนาการค้นหาของผู้ใช้อย่างไรพร้อมกับผลลัพธ์ ผู้ใช้ก็จะตรวจสอบได้เองว่าความเข้าใจของ LLM ถูกต้องหรือไม่
• รู้สึกสับสนกับตัวเลือกแบบ self-hosted เพราะดูจากเอกสารที่เกี่ยวข้องเหมือนต้องมีบัญชีบริการของ third-party อย่างน้อย 6 ตัว ซึ่งต่างจากความหมายของ self-hosted ที่แท้จริงมาก
  • อธิบายว่าโค้ดนั้นสามารถ self-host ได้จริงด้วยตัวเอง และคิดว่าคำว่า “self-hosted” เองก็ไม่มีเกณฑ์ทางการที่ชัดเจน เช่น ต่อให้บริการแบบ self-hosted มีฟังก์ชันสำรองข้อมูลนอกสถานที่ ก็ยังถือว่าเป็น self-hosted และเป็นเพียงบริการที่ออกแบบมาดี
  • การทำการตลาดคำว่า self-hosted แบบนี้อาจถือว่าเป็นเรื่องปกติได้ และด้วยความที่โมเดลธุรกิจเดิมของบริษัทคือขายเวอร์ชัน hosted ก็ไม่ได้จำเป็นต้องมีหน้าที่ต้องออกผลิตภัณฑ์ self-hosted แบบอิสระเต็มรูปแบบเสมอไป
  • แชร์ประสบการณ์การทำงานในสภาพแวดล้อมเครือข่ายที่จำกัด โดยตลอด 20 ปีที่ผ่านมาได้ทำงานอยู่ในระบบเครือข่ายภายในที่ถูกปิดกั้นอย่างสมบูรณ์ จึงคิดว่าอาจพลาดคลื่นเทคโนโลยีใหม่ ๆ ไปมาก อีกทั้งแทบไม่ดู YouTube นอกจากเรื่องซ่อมรถ จึงค่อนข้างไม่อินกับเทรนด์เทคโนโลยีที่ต้องพึ่งการเชื่อมต่อออนไลน์ตลอดเวลา
  • ส่วนตัวใช้งานเวอร์ชันโอเพนซอร์สอย่างพึงพอใจมาก และหากไม่ต้องการพึ่งพา hosted dependency ก็มีความเห็นเชิงปฏิบัติว่าเขียนทุกอย่างเองด้วย Rust ก็ได้
• reranker ขนาดใหญ่ที่อิง LLM (เช่น Qwen3-reranker) ให้ประสิทธิภาพแบบที่เคยอยากได้จาก cross-encoder มานาน จึงแนะนำว่าอยากให้ลองใช้ดู แต่ต้นทุนคำนวณสูงมาก อีกทั้งข้อมูล metadata/ตารางนั้นเป็นข้อมูลพื้นฐานที่มนุษย์มองว่า obvious มาก แต่ใน text chunk มักไม่ถูกทำซ้ำ หาก inject เข้าไปในอินพุตของ LLM จะทำให้ดู “ฉลาดขึ้น” มาก และควรระวังกับ query ซับซ้อนที่ simple RAG จัดการได้ไม่ดีนัก (เช่น สรุปเอกสารล่าสุด 20 ฉบับ) ดังนั้นเราจึงทำ UI ให้โฟกัสที่การค้นหาและลด chat UX ลง พร้อมทั้งให้ผู้ใช้เห็นเฉพาะข้อมูลที่โมเดลเห็นจริง
  • เห็นด้วยอย่างยิ่งว่าการทำให้ผู้ใช้เข้าใจโครงสร้างการประมวลผล context ของ LLM อย่างถูกต้องนั้นยากมาก ตัวอย่างสาธารณะที่หลุดจาก chat UX ยังมีน้อยมาก จึงอดสงสัยไม่ได้ว่าเหตุที่บริษัทใหญ่ ๆ ลองแล้วเลิกทำนั้น เป็นเพราะ “ไม่เห็นผล” จริงหรือไม่ ในทางปฏิบัติแอปผู้บริโภคขนาดใหญ่มีต้นทุนด้าน context/inference เป็นค่าใช้จ่ายหลักที่ต้องควบคุม ทำให้ UI แบบ context explicit เหมือนจะไม่ค่อยได้รับการยอมรับ ขณะที่ระบบ RAG ภายในองค์กรมีภาระด้านต้นทุนน้อยกว่า จึงจากประสบการณ์รู้สึกว่าสามารถโฟกัสกับคุณภาพผลลัพธ์และการประหยัดเวลาพนักงานได้มากกว่า
  • แม้การปรับแต่งทางเทคนิคจะสำคัญ แต่ก็อยากรู้กรณีใช้งานจริงมากกว่านี้ว่าช่วยเพิ่มประสิทธิภาพการทำงานของลูกค้าได้มากแค่ไหน ไม่เช่นนั้นก็อาจเป็นเพียงกระแสเทคโนโลยีอีกรอบเท่านั้น
• แชร์บทความสรุปที่เขียนไว้เมื่อปีกว่าเกี่ยวกับการจัดการ RAG สำหรับหลายล้านหน้า โดยเฉพาะเอกสารทางเทคนิค https://jakobs.dev/learnings-ingesting-millions-pages-rag-azure/
  • เคยสร้างระบบ RAG สำหรับการค้นหาทางเทคนิคไว้เมื่อปีก่อนเช่นกัน และรู้สึกว่าหลายส่วนยังแทบเหมือนเดิมแม้มองจากตอนนี้
• ในมุมของคนที่กำลังจะสร้างหรือนำระบบ RAG แบบนี้ไปใช้ อยากรู้ว่าถ้าอัปโหลดเอกสารผ่าน API ไปยังโฟลเดอร์ Google Workspace แล้วใช้ Google AI search API ค้นหาเอกสาร จะเป็นสถาปัตยกรรมที่ใช้งานได้จริงหรือไม่ โดยแยกเก็บตามโฟลเดอร์ของผู้ใช้แต่ละคน หรืออาจทำสิ่งคล้ายกันบน Azure ได้หรือไม่
• สงสัยวิธีทำ version management สำหรับ embedding ว่าหากต้องอัปเดตข้อมูล เปิดเผยบางเวอร์ชัน หรือกรองตามวันที่ ควรทำอย่างไร และกำลังคิดถึงวิธีเพิ่ม context version ไว้ด้านหน้าของ chunk ด้วย
  • แค่เก็บข้อความต้นฉบับและ metadata (รวมข้อมูลเวอร์ชัน) ไว้ด้วยกันใน vector store ก็พอ เช่น ใน turbopuffer สามารถทำ attribute filtering ได้สะดวก พร้อมแนะนำ เอกสาร
  • รู้สึกว่าคำถามนี้เองเป็นคำถามที่มีประโยชน์และสำคัญมาก
• รู้สึกว่าเหตุผลที่ลำดับการใช้เวอร์ชัน LLM เป็น GPT 4.1 → GPT 5 → กลับไป GPT 4.1 อีกครั้ง รวมถึงความไม่สอดคล้องกับเวอร์ชันของคอมโพเนนต์อื่นในสแตก (เช่น text-embedding-large-3) ดูแปลกอยู่บ้าง
  • คำตอบจาก OP: ทันทีที่ GPT-5 ออกก็ลองใช้งาน แต่เมื่อป้อน context จำนวนมาก (สูงสุด 100,000 โทเค็น) กลับทำงานได้แย่กว่า GPT-4.1 จึงย้อนกลับไปใช้ 4.1 อีกครั้ง โดยเฉพาะ a) ทำตาม instruction ได้ไม่ดีและมักไม่ค่อยทำตาม system prompt b) คำตอบยืดยาวเกินไปจนกระทบ UX มาก c) ข้อจำกัด context window ที่ 125,000 โทเค็นทำให้อินพุตที่ใหญ่มากเกิด error ได้ ปัญหาเหล่านี้เด่นชัดในงาน “RAG” ที่ต้องส่งหลาย chunk เข้าไปพร้อมกัน ส่วนงานทั่วไป GPT-5 อาจดีกว่าก็ได้
• แม้จะไม่ใช่สายเชียร์ AWS แต่ก็ย้ำว่า S3 Vectors คือ state-of-the-art ของสายนี้ในตอนนี้ และหากเชื่อมกับ Bedrock Knowledge Base ด้วย Discovery/Rebalance ก็จะยิ่งง่ายขึ้น กลายเป็นโซลูชันที่เรียบง่ายที่สุดในตลาด และคิดว่าเมื่อเปิดตัวอย่างเป็นทางการแล้วน่าจะทิ้งคู่แข่งส่วนใหญ่ได้
  • แซวแก้คำอย่างขำ ๆ ว่าคำที่ถูกควรเป็น “shill” ไม่ใช่ “schlep”
  • สงสัยว่าเหตุใด S3 Vectors ถึงเป็น SOTA (ล้ำสมัยที่สุด) เพราะท้ายที่สุดมันก็เป็นเพียง vector store ไม่ใช่หรือ
• RAG แบบอิง embedding ในทางปฏิบัติอาจยังไม่ใช่วิธีที่ดีที่สุดเสมอไป เหมาะกับงานเดี่ยวหรือเดโม แต่ในสถานการณ์จริงมักเจอข้อจำกัดอยู่บ่อย
  • แต่ก็ไม่จำเป็นต้องเป็นแบบนั้นเสมอไป จากประสบการณ์ของอีกฝ่าย ผลิตภัณฑ์ Honeycomb ที่เคยทำอย่าง Query Assistant blog ก็อิงกับ data query มาตั้งแต่ปี 2023 และเพราะฟีเจอร์นี้ถูกออกแบบให้มีเป้าหมายที่เรียบง่าย จึงกลับรู้สึกว่าเป็นทิศทางในอุดมคติของผลิตภัณฑ์ที่ใช้ LLM และควรผสานกับกระบวนการที่ไม่ใช่ LLM ด้วย
  • rag ถูกตีความใหม่ได้เรื่อย ๆ และมี use case หลากหลาย เราได้นำ rag ไปผนวกรวมเป็นเครื่องมือหนึ่งใน agentic search พร้อมผสมทั้งการค้นหาจากแหล่งข้อมูลแบบเรียลไทม์และวิธี chunk แบบเดิม อีกทั้งหน้าต่าง context ขนาดใหญ่ที่จะมาในไม่ช้าน่าจะทำให้การใส่ทั้งเอกสารเข้าไปในคำขอเดียวเป็นไปได้
  • อยากรู้ว่าแนะนำทางเลือกอะไร หมายถึงแนวทางสร้าง query ใช่หรือไม่
  • แม้แต่ ChatGPT เองก็มีประสิทธิภาพในการดึงข้อมูลล่าสุดผ่าน RAG และประโยชน์เชิงปฏิบัติจริงนี้เองคือเหตุผลที่ผู้ให้บริการรายใหญ่ทุกเจ้าต่างมีสิ่งนี้
  • ถามย้ำว่ากำลังเปรียบเทียบกับอะไรอยู่ให้ชัดเจน
• มีการบอกว่าใช้เวลาและแรงไปมากกับกลยุทธ์การเลือก chunk จึงอยากฟังรายละเอียดเพิ่มเติมเกี่ยวกับกลยุทธ์ที่ใช้จริง