สร้าง RAG แบบ Local ได้จริง: ประสบการณ์จาก Skald

ทีมพัฒนา Skald ได้ทดลองสร้างระบบ RAG (Retrieval-Augmented Generation) แบบ self-hosted ที่ไม่ต้องส่งข้อมูลไปยังบริการของบุคคลที่สาม โดยใช้เทคโนโลยี open-source ทั้งหมด เพื่อตอบโจทย์องค์กรที่ต้องการความเป็นส่วนตัวของข้อมูลแต่ยังต้องการใช้ประโยชน์จาก AI สมัยใหม่

การทดสอบใช้เนื้อหาจากเว็บไซต์ PostHog ประมาณ 2,000 เอกสาร โดยเปรียบเทียบประสิทธิภาพระหว่าง 3 รูปแบบ: Cloud APIs (Voyage + Claude), Hybrid (Voyage + GPT-OSS 20B), และ Fully Local (Sentence Transformers + GPT-OSS 20B) ผลลัพธ์แสดงให้เห็นว่าระบบ local สามารถทำงานได้จริงและให้ผลลัพธ์ที่ดีในหลายกรณี

สิ่งที่น่าสนใจคือการ deploy ระบบทั้งหมดใช้เวลาเพียง 8 นาที รวมถึง vector database, reranking, embedding service และ document parser โดยใช้ Postgres + pgvector, Sentence Transformers, และ Docling ตามลำดับ ทำให้เห็นว่าการสร้าง RAG แบบ local ไม่ได้ยากอย่างที่คิด

ผลการทดสอบพบว่า Cloud setup ได้คะแนน 9.45/10, Hybrid setup ได้ 9.18/10, ส่วน Local setup แบบพื้นฐานได้ 7.10/10 และเมื่อใช้โมเดล multi-lingual ที่ดีกว่าสามารถยกระดับเป็น 8.63/10 ได้ โดยจุดอ่อนหลักคือการตอบคำถามที่ต้องรวบรวมข้อมูลจากหลายเอกสาร แต่สำหรับคำถามแบบ point query ระบบ local ทำงานได้ดีมาก

สรุปสาระสำคัญ
องค์ประกอบของ RAG และทางเลือก Open-Source
Vector Database: Postgres + pgvector (แทน Pinecone, Weaviate)
Embeddings: Sentence Transformers all-MiniLM-L6-v2 (แทน OpenAI, Voyage)
LLM: GPT-OSS 20B ผ่าน llama.cpp (แทน GPT-4, Claude)
Reranker: Sentence Transformers cross-encoder (แทน Cohere, Voyage)
Document Parser: Docling ผ่าน docling-serve

ผลการทดสอบประสิทธิภาพ
Voyage + Claude (Cloud): คะแนนเฉลี่ย 9.45/10 - ผ่านทุกคำถาม
Voyage + GPT-OSS 20B (Hybrid): คะแนนเฉลี่ย 9.18/10 - ผลลัพธ์ดีมาก
Local + โมเดลพื้นฐาน: คะแนนเฉลี่ย 7.10/10 - ดีสำหรับ point queries
Local + โมเดล multi-lingual: คะแนนเฉลี่ย 8.63/10 - ปรับปรุงได้มาก

ข้อดีของ Local Setup
Deploy ได้ภายใน 8 นาที รวมทุก component
ไม่ต้องส่งข้อมูลออกนอกองค์กร - เหมาะกับข้อมูลที่ sensitive
ใช้เทคโนโลยี open-source ทั้งหมด (MIT-licensed)
รองรับการทำงานใน air-gapped infrastructure

จุดแข็งของโมเดล Local
ตอบคำถามแบบ point query (หาคำตอบจากที่เดียว) ได้ดีมาก
โมเดลพื้นฐานทำงานเร็วและเหมาะกับภาษาอังกฤษ
โมเดล multi-lingual (bge-m3) รองรับหลายภาษารวมถึงไทย
แนวโน้มจะดีขึ้นเรื่อยๆ เมื่อโมเดล open-source พัฒนา

ข้อจำกัดที่ควรระวัง
โมเดลพื้นฐานมีปัญหากับคำถามที่คลุมเครือ (ambiguous questions)
ยังไม่เก่งในการรวบรวมข้อมูลจากหลายเอกสาร (multi-document context)
โมเดลพื้นฐานรองรับเฉพาะภาษาอังกฤษ - ต้องใช้โมเดล multi-lingual สำหรับภาษาอื่น
pgvector อาจไม่เหมาะกับ dataset ขนาดใหญ่มากๆ - ต้องพิจารณา vector DB อื่น

สิ่งที่ต้องเตรียมพร้อม
ต้องรัน service หลายตัวเพิ่มขึ้นเมื่อเทียบกับการเรียก API
ต้องมีความรู้ในการ deploy และ manage infrastructure
อาจต้องปรับแต่ง topK values และเทคนิคอื่นๆ ตาม use case
ต้องมี hardware เพียงพอ (ทดสอบใช้ g5.2xlarge EC2 สำหรับ LLM)

https://blog.yakkomajuri.com/blog/local-rag
🚀 สร้าง RAG แบบ Local ได้จริง: ประสบการณ์จาก Skald ทีมพัฒนา Skald ได้ทดลองสร้างระบบ RAG (Retrieval-Augmented Generation) แบบ self-hosted ที่ไม่ต้องส่งข้อมูลไปยังบริการของบุคคลที่สาม โดยใช้เทคโนโลยี open-source ทั้งหมด เพื่อตอบโจทย์องค์กรที่ต้องการความเป็นส่วนตัวของข้อมูลแต่ยังต้องการใช้ประโยชน์จาก AI สมัยใหม่ การทดสอบใช้เนื้อหาจากเว็บไซต์ PostHog ประมาณ 2,000 เอกสาร โดยเปรียบเทียบประสิทธิภาพระหว่าง 3 รูปแบบ: Cloud APIs (Voyage + Claude), Hybrid (Voyage + GPT-OSS 20B), และ Fully Local (Sentence Transformers + GPT-OSS 20B) ผลลัพธ์แสดงให้เห็นว่าระบบ local สามารถทำงานได้จริงและให้ผลลัพธ์ที่ดีในหลายกรณี สิ่งที่น่าสนใจคือการ deploy ระบบทั้งหมดใช้เวลาเพียง 8 นาที รวมถึง vector database, reranking, embedding service และ document parser โดยใช้ Postgres + pgvector, Sentence Transformers, และ Docling ตามลำดับ ทำให้เห็นว่าการสร้าง RAG แบบ local ไม่ได้ยากอย่างที่คิด ผลการทดสอบพบว่า Cloud setup ได้คะแนน 9.45/10, Hybrid setup ได้ 9.18/10, ส่วน Local setup แบบพื้นฐานได้ 7.10/10 และเมื่อใช้โมเดล multi-lingual ที่ดีกว่าสามารถยกระดับเป็น 8.63/10 ได้ โดยจุดอ่อนหลักคือการตอบคำถามที่ต้องรวบรวมข้อมูลจากหลายเอกสาร แต่สำหรับคำถามแบบ point query ระบบ local ทำงานได้ดีมาก 📌 สรุปสาระสำคัญ ✅ องค์ประกอบของ RAG และทางเลือก Open-Source ➡️ Vector Database: Postgres + pgvector (แทน Pinecone, Weaviate) ➡️ Embeddings: Sentence Transformers all-MiniLM-L6-v2 (แทน OpenAI, Voyage) ➡️ LLM: GPT-OSS 20B ผ่าน llama.cpp (แทน GPT-4, Claude) ➡️ Reranker: Sentence Transformers cross-encoder (แทน Cohere, Voyage) ➡️ Document Parser: Docling ผ่าน docling-serve ✅ ผลการทดสอบประสิทธิภาพ ➡️ Voyage + Claude (Cloud): คะแนนเฉลี่ย 9.45/10 - ผ่านทุกคำถาม ➡️ Voyage + GPT-OSS 20B (Hybrid): คะแนนเฉลี่ย 9.18/10 - ผลลัพธ์ดีมาก ➡️ Local + โมเดลพื้นฐาน: คะแนนเฉลี่ย 7.10/10 - ดีสำหรับ point queries ➡️ Local + โมเดล multi-lingual: คะแนนเฉลี่ย 8.63/10 - ปรับปรุงได้มาก ✅ ข้อดีของ Local Setup ➡️ Deploy ได้ภายใน 8 นาที รวมทุก component ➡️ ไม่ต้องส่งข้อมูลออกนอกองค์กร - เหมาะกับข้อมูลที่ sensitive ➡️ ใช้เทคโนโลยี open-source ทั้งหมด (MIT-licensed) ➡️ รองรับการทำงานใน air-gapped infrastructure ✅ จุดแข็งของโมเดล Local ➡️ ตอบคำถามแบบ point query (หาคำตอบจากที่เดียว) ได้ดีมาก ➡️ โมเดลพื้นฐานทำงานเร็วและเหมาะกับภาษาอังกฤษ ➡️ โมเดล multi-lingual (bge-m3) รองรับหลายภาษารวมถึงไทย ➡️ แนวโน้มจะดีขึ้นเรื่อยๆ เมื่อโมเดล open-source พัฒนา ‼️ ข้อจำกัดที่ควรระวัง ⛔ โมเดลพื้นฐานมีปัญหากับคำถามที่คลุมเครือ (ambiguous questions) ⛔ ยังไม่เก่งในการรวบรวมข้อมูลจากหลายเอกสาร (multi-document context) ⛔ โมเดลพื้นฐานรองรับเฉพาะภาษาอังกฤษ - ต้องใช้โมเดล multi-lingual สำหรับภาษาอื่น ⛔ pgvector อาจไม่เหมาะกับ dataset ขนาดใหญ่มากๆ - ต้องพิจารณา vector DB อื่น ‼️ สิ่งที่ต้องเตรียมพร้อม ⛔ ต้องรัน service หลายตัวเพิ่มขึ้นเมื่อเทียบกับการเรียก API ⛔ ต้องมีความรู้ในการ deploy และ manage infrastructure ⛔ อาจต้องปรับแต่ง topK values และเทคนิคอื่นๆ ตาม use case ⛔ ต้องมี hardware เพียงพอ (ทดสอบใช้ g5.2xlarge EC2 สำหรับ LLM) https://blog.yakkomajuri.com/blog/local-rag
0 Comments 0 Shares 26 Views 0 Reviews