- Skald ถูกพัฒนาขึ้นโดยมีเป้าหมายเป็น ระบบ RAG ที่โฮสต์เองได้ทั้งหมด โดยไม่ส่งข้อมูลไปยังบุคคลที่สาม
- องค์ประกอบของ RAG แบ่งเป็น ฐานข้อมูลเวกเตอร์, โมเดล embedding, LLM, reranker, ตัวแยกวิเคราะห์เอกสาร และมีการนำเสนอ ทางเลือกโอเพนซอร์ส สำหรับแต่ละส่วน
- สแตกโลคัลพื้นฐานของ Skald ประกอบด้วย Postgres+pgvector, Sentence Transformers, Docling, และ LLM ที่ผู้ใช้กำหนดเอง
- จากผลเบนช์มาร์ก โมเดลบนคลาวด์ (Voyage+Claude) ได้คะแนนเฉลี่ย 9.45 ขณะที่ GPT-OSS 20B แบบโลคัลเต็มรูปแบบ ได้ 7.10~8.63 คะแนน
- แนวทางนี้แสดงให้เห็นว่า สามารถสร้าง RAG ประสิทธิภาพสูงได้พร้อมรักษาความเป็นส่วนตัวของข้อมูล
องค์ประกอบของ RAG และทางเลือกโอเพนซอร์ส
- RAG พื้นฐานประกอบด้วย ฐานข้อมูลเวกเตอร์, โมเดล embedding, LLM และอาจมี reranker กับตัวแยกวิเคราะห์เอกสาร เพิ่มเติม
- แต่ละองค์ประกอบสามารถแทนที่ SaaS ด้วย ทางเลือกแบบโลคัล ได้
- ตัวอย่างทางเลือกที่นำเสนอในตาราง
- Vector DB: Pinecone, Weaviate Cloud → Qdrant, Weaviate, Postgres+pgvector
- Embeddings: OpenAI, Cohere → Sentence Transformers, BGE, E5
- LLM: GPT, Claude → Llama, Mistral, GPT-OSS
- Reranker: Cohere → BGE Reranker, Sentence Transformers Cross-Encoder
- Document Parsing: Reducto → Docling
- Skald มุ่งสู่ สแตกโอเพนซอร์สเต็มรูปแบบ และรันแต่ละองค์ประกอบบนเครื่องโลคัล
การจัดสแต็กโลคัลของ Skald
- Vector DB: ใช้ Postgres + pgvector
- ผสานเข้ากับโครงสร้างพื้นฐานเดิมได้ง่าย และรองรับเอกสารได้ถึงระดับหลายแสนรายการ
- Vector Embeddings: ค่าเริ่มต้นคือ Sentence Transformers (all-MiniLM-L6-v2)
- รองรับภาษาอังกฤษเท่านั้น และสมดุลระหว่างความเร็วกับประสิทธิภาพการค้นหา
- มีการทดสอบโมเดล bge-m3 (รองรับหลายภาษา) ด้วย
- LLM: ไม่มีให้มาเป็นค่าเริ่มต้น ผู้ใช้ต้องรันเอง
- ในการทดสอบใช้ GPT-OSS 20B รันบน EC2
- Reranker: ค่าเริ่มต้นคือ Sentence Transformers Cross-Encoder และยังใช้โมเดลหลายภาษาอย่าง bge-reranker-v2-m3 ได้เช่นกัน
- Document Parsing: ใช้ Docling โดยรันผ่าน docling-serve
ผลด้านประสิทธิภาพและการดีพลอย
- ใช้เวลา 8 นาที ในการดีพลอยอินสแตนซ์โปรดักชันของ Skald พร้อมสแตกทั้งหมด
- รวม Postgres, บริการ embedding และ reranking, รวมถึง Docling
- ส่วน LLM รันแยกต่างหาก (ใช้ llama.cpp)
- ชุดข้อมูลทดสอบประกอบด้วย คอนเทนต์เว็บไซต์ของ PostHog (ประมาณ 2000 เอกสาร) และชุดคำถาม-คำตอบที่สร้างขึ้นเอง
- การตั้งค่าการทดลอง
- Vector search topK=100, Reranking topK=50, Query rewriting=Off
- เกณฑ์การประเมินเน้นที่ ความแม่นยำ
เปรียบเทียบผลเบนช์มาร์ก
- Voyage + Claude (ชุดบนคลาวด์)
- คะแนนเฉลี่ย 9.45 และตอบถูกต้องทุกข้อ
- Voyage + GPT-OSS 20B (โลคัลบางส่วน)
- คะแนนเฉลี่ย 9.18 โดยส่วนใหญ่ถูกต้อง แต่มีข้อมูลตกหล่นบางส่วน
- โลคัลเต็มรูปแบบ + GPT-OSS 20B
- โมเดลภาษาอังกฤษพื้นฐาน (all-MiniLM-L6-v2 + ms-marco-MiniLM-L6-v2) : คะแนนเฉลี่ย 7.10
- ตอบคำถามภาษาอังกฤษได้แม่นยำ แต่ยังอ่อนในคำถามหลายภาษา คำถามกำกวม และการสรุปรวมจากหลายเอกสาร
- โมเดลหลายภาษา (bge-m3 + mmarco-mMiniLMv2-L12-H384-v1) : คะแนนเฉลี่ย 8.63
- จัดการคำถามภาษาโปรตุเกสได้สำเร็จ แต่ยังมีบางส่วนตกหล่นเมื่อต้องรวมข้อมูลจากหลายเอกสาร
- ข้อจำกัดสำคัญคือ การผสานข้อมูลที่กระจายอยู่ในหลายเอกสารเข้าด้วยกัน
- โมเดลคลาวด์ชดเชยจุดนี้ได้ด้วยประสิทธิภาพที่สูงกว่า แต่ในสภาพแวดล้อมโลคัลยังต้องใช้เทคนิคเพิ่มเติม
แผนในอนาคต
- Skald มีแผน ปรับปรุงประสิทธิภาพของ Local RAG และเผยแพร่เบนช์มาร์กของโมเดลโอเพนซอร์ส
- ตั้งเป้าจัดหาโซลูชันสำหรับ องค์กรที่ต้องรันเครื่องมือ AI ในสภาพแวดล้อมแบบ air-gapped
- ผู้ที่สนใจเข้าร่วมสามารถร่วมมือได้ผ่าน GitHub(skaldlabs/skald) หรือ ชุมชน Slack
7 ความคิดเห็น
ไม่รู้เลยว่าไอเดียที่ว่า RAG ต้องมี vector DB นี่มันเริ่มมาจากไหนกันแน่...
ไม่ว่าจะเป็น vector DB หรืออะไรก็ตาม จริง ๆ แล้วแค่ทำระบบค้นหาให้ได้ก็น่าจะพอแล้วนะ...
Gemini:
ใช่แล้ว การใช้ ฐานข้อมูลเวกเตอร์ (Vector Database) ใน RAG (Retrieval-Augmented Generation) มีรากฐานเชิงแนวคิดมาตั้งแต่มีการเผยแพร่งานวิจัยที่เกี่ยวข้องเป็นครั้งแรกในปี 2020
โดยพื้นฐานแล้ว RAG เป็นแนวทางที่ผสาน การค้นคืนข้อมูล (Retrieval) กับ การสร้างข้อความ (Generation) เข้าด้วยกัน และในขั้นตอนการค้นคืนนี้ เวกเตอร์เอ็มเบดดิงและฐานข้อมูลเวกเตอร์ที่ใช้เก็บและค้นหาเวกเตอร์เหล่านั้นอย่างมีประสิทธิภาพจึงมีบทบาทสำคัญอย่างยิ่ง
💡 จุดเริ่มต้นของ RAG และ Vector DB
แนวคิดที่ว่า RAG จำเป็นต้องมี Vector DB เริ่มต้นจากงานวิจัยและแนวคิดสำคัญดังต่อไปนี้
เหตุผลพื้นฐานที่ทำให้ฐานข้อมูลเวกเตอร์กลายเป็นองค์ประกอบสำคัญของ RAG มีดังนี้
สรุป: เหตุผลที่ต้องใช้ Vector DB
หากต้องการให้ LLM เข้าถึงความรู้ล่าสุดหรือความรู้เฉพาะโดเมนที่ไม่ได้อยู่ในการฝึก ก็จำเป็นต้องค้นหาข้อมูลโดยอาศัยความคล้ายคลึงเชิงความหมาย ไม่ใช่เพียงการจับคู่คีย์เวิร์ดแบบง่าย ๆ (การค้นหาแบบดั้งเดิม) Vector DB คือเทคโนโลยีหลักที่ถูกผสานเข้ากับกรอบการทำงานของ RAG อย่างเป็นธรรมชาติเพื่อทำให้การค้นหาบนพื้นฐานของความคล้ายคลึงเชิงความหมายนี้ทำงานได้อย่างมีประสิทธิภาพ
จริง ๆ แล้วสิ่งที่ RAG ต้องการก็คือความสามารถในการค้นหา และการทำ embedding ด้วย dense vector แล้ว push เข้า vectorDB เพื่อค้นหาด้วย cosine similarity ก็เป็นเพียงหนึ่งในหลายวิธีในการสร้าง search engine เท่านั้น... ไม่ได้มีเหตุผลว่าจะห้ามใช้ vectorDB หรอก แต่ถ้าถามว่าจำเป็นจริงไหม ก็มีอัลกอริทึมของ search engine ที่ใช้กันมาได้ดีมายาวนานอยู่เยอะ เลยทำให้อดเอียงคอสงสัยนิด ๆ ไม่ได้ครับ
เพราะมันถูกและ LLM สำหรับโปรดักชันส่วนใหญ่ก็ใช้กัน
จริง ๆ แล้วถ้าคิดแบบนั้น เว็บเซิร์ฟเวอร์เองก็ทำทุกอย่างได้จากดิสก์ถ้าเพิ่มฟังก์ชันอินฟราขึ้นมา งั้นก็ไม่ต้องมี DBMS เหมือนกันสิ 555
ถูกต้องครับ/ค่ะ ว่าจำเป็นต้องมีฐานข้อมูลสำหรับการค้นหาความคล้ายคลึง/ความหมาย โดยใช้ค่า embedding (เวกเตอร์) ของ query ของผู้ใช้เป็น key และเมื่อ key อยู่ในรูปแบบเวกเตอร์ ก็ใช้ vector DB ได้เช่นกัน
ความคิดเห็นจาก Hacker News
อยากแนะนำว่าเวลาสร้างระบบแบบนี้ อย่าไปยึดติดกับ vector database หรือ embeddings มากเกินไป
การค้นหาแบบ full-text หรือใช้เครื่องมืออย่าง
grep/rgมักจะเร็วและถูกกว่ามาก และไม่ต้องคอยดูแลดัชนีด้วยถ้าให้เครื่องมือค้นหากับ LLM ที่ดี มันสามารถสร้างคิวรีอย่าง “dog OR canine” ได้เองและปรับปรุงซ้ำไปเรื่อย ๆ
แถมยังไม่ต้องแก้ ปัญหา chunking อีกด้วย
ดูได้ที่ Search Sensei
ตอนโหลดครั้งแรกจะดาวน์โหลด model weights กับ onnx runtime ราว 50MB แต่หลังจากนั้นก็ทำงานได้ลื่น
ตัวอย่างเช่น BM25 จะไม่เข้าใจว่า “j lo” กับ “jlo” หมายถึง Jennifer Lopez แต่การค้นหาแบบ embedding-based จัดการ คำพิมพ์ผิดหรือชื่อเรียกอื่น แบบนี้ได้ดี
ระบบค้นหากับข่าว 1,000 ชิ้นในช่วงปี 2016~2024
แต่ก็น่าเสียดายที่ไม่ได้เปิดเผยผลของ BM25 แบบเดี่ยว
ในการทดสอบเล็ก ๆ ของผม มีกรณีที่ embedding พลาดหน้าที่มีคำจากคิวรีอยู่ตรง ๆ — สุดท้าย Ctrl+F ชนะ
Lexical search มี precision สูงแต่ recall ต่ำ ส่วน semantic search อยู่คนละด้านของสมดุลนี้
รู้สึกว่าควรมีตัวดำเนินการ “NOT” มากกว่านี้ และอยากเรียนรู้เรื่อง RAG เพิ่มด้วย
เคยเห็นเครื่องมือแบบ agent บางตัวสร้างคิวรีพวกนี้ให้อัตโนมัติ แต่ไม่แน่ใจว่าเกิดจาก prompt ชี้นำหรือเป็นพฤติกรรมพื้นฐาน
สาเหตุหนึ่งที่ประสิทธิภาพไม่ดีอาจเป็นเพราะ semantic chunking ยังไม่พอ
ถ้า embed ทั้งเอกสาร หลายแนวคิดจะปนกันจนความแม่นยำลดลง
ควรใช้เครื่องมืออย่าง Spacy แบ่งตามหน่วยความหมาย แล้วเพิ่มบริบทว่าแต่ละ chunk อยู่ในบริบทใดของเอกสารก่อนค่อย embed
แนวทาง contextual retrieval ของ Anthropic มีประสิทธิภาพมากในระบบ RAG
ใช้โมเดล GPT OSS 20B สร้างบริบทก็ได้
น่าจะเกิดความเข้าใจผิดเพราะเราทดสอบด้วยคำถามที่ต้องรวบรวมบริบทจากหลายเอกสาร
สงสัยว่าทำไมถึง ตั้งสมมติฐานว่า semantic search ดีกว่า lexical search
ตอนเทียบกับ Tantivy (BM25) ในปี 2023 ความต่างของผลลัพธ์มีน้อยมาก
ต่อให้ recall ดีขึ้นนิดหน่อย ก็ไม่แน่ใจว่าคุ้มจะสร้างโครงสร้างที่ซับซ้อนขนาดนั้นไหม
ในการทดสอบของนักพัฒนา recall อยู่ที่ 90% แต่พอทดสอบกับผู้ใช้จริงกลับตกไปเหลือราว 30%
ผู้ใช้ไม่รู้คำศัพท์ที่ตรงกับในเอกสาร จึง พึ่ง lexical search อย่างเดียวไม่พอ
จะวาง agent ทับเพิ่มก็ได้ แต่ latency สูงขึ้นจนความพึงพอใจผู้ใช้ลดลง
ใน Wanderfugl ส่วนที่ BM25 ให้คะแนนต่ำ semantic search ก็ยังหาเจอได้ดี
สุดท้าย hybrid ranking อาจเป็นคำตอบ
สรุปคือ ขึ้นอยู่กับ use case
กำลังหา เครื่องมือโอเพนซอร์ส ที่ใช้ถามข้อมูลทั้งหมดแบบ local offline ได้ ไม่ว่าจะเป็นอีเมล, Slack, GDrive, โค้ด, วิกิ ฯลฯ
อยากเลี่ยงการสร้างเองหรือ custom มากเกินไป และถ้ามีค่าเริ่มต้นกับคำแนะนำโมเดลที่ดีจะยิ่งดี
ลิงก์ GitHub
รองรับ CRUD เป็นพื้นฐาน และถ้าเปิดใช้ vector search ก็จะ embed เอกสารหรืองานโน้ต
รองรับ Ollama และ OpenAI เป็น embedding provider
MCP server ให้ทั้งการค้นหาแบบ semantic + BM25 (qdrant fusion) และสร้างคำตอบผ่าน MCP sampling
ตัวเซิร์ฟเวอร์เองไม่ได้สร้างคำตอบ แต่เชื่อมกับ LLM/MCP client ตัวไหนก็ได้
แพตเทิร์น MCP sampling/RAG นี้ทรงพลังมาก และมีโอกาสสูงที่จะมีเวอร์ชันโอเพนซอร์สแบบทั่วไปสำหรับแหล่งข้อมูลอื่นตามมา
เครื่องมือที่เราใช้คือ haiku.rag
มันมีโค้ด Python ที่เป็นมิตรกับนักพัฒนา โครงสร้างบน pydantic-ai พร้อม benchmark และฟีเจอร์ citation ขั้นสูง
รองรับ deep research agent และเป็นโปรเจกต์โอเพนซอร์สจริงจังที่ดูแลระยะยาว
ตอนนี้ใช้ Sentence Transformers (all-MiniLM-L6-v2) เป็น embedding model เริ่มต้น แต่เพิ่งรู้ว่ามันรองรับเฉพาะภาษาอังกฤษ จึงอาจมีปัญหาเมื่อสร้าง German RAG
เลยสงสัยว่าประสิทธิภาพของโมเดลที่ไม่ใช่ภาษาอังกฤษเป็นอย่างไร
ให้ดูหัวข้อ RTEB Multilingual หรือ RTEB German ในส่วน “Retrieval”
ถ้าจะ self-host บน CPU ก็ควรกรองโมเดลที่มีพารามิเตอร์ไม่เกิน 100M
แต่ภาษาเยอรมันมีข้อมูลฝึกค่อนข้างมาก และก็มี multilingual model อยู่พอสมควร
โดยเฉพาะโมเดลเชิงพาณิชย์แบบ API ส่วนใหญ่ รองรับหลายภาษา
ดูงานวิจัยที่เกี่ยวข้องได้ที่ ลิงก์ Springer
สมัย GPT-4 (8K context) ผมเคยทำสคริปต์ที่แบ่งหนังสือทั้งเล่มเป็น chunk แล้วส่งเข้า GPT-4 เพื่อ ค้นหาช่วงข้อความที่เกี่ยวข้อง
ตอนนั้นการค้นหาหนึ่งครั้งมีต้นทุนราว 1 ดอลลาร์ แต่ตอนนี้ถูกลงมากแล้ว
ในบทความ contextual retrieval ของ Anthropic ก็พูดเหมือนกันว่าถ้าเอกสารใส่ลงใน context ได้หมด ก็ใส่ไปตรง ๆ เลยดีกว่าใช้ RAG
แต่ถ้า context ยาวเกินไป คุณภาพก็จะลดลง และยังมีปัญหาเรื่องต้นทุนกับความเร็ว
ตอนนี้เอาหนังสือทั้งเล่มใส่ใน context ได้ในระดับ 1 เซนต์ แล้ว
ส่วนที่ยากที่สุดของ RAG คือ การ parse เอกสาร
ถ้ามีแค่ข้อความล้วนยังพอได้ แต่ถ้ามีตาราง ตารางข้ามหลายหน้า แผนภูมิ สารบัญ เชิงอรรถ ฯลฯ ความแม่นยำจะตกฮวบ
เพื่อแก้ปัญหานี้ มีแนวทางแบบ RAPTOR pattern ที่ให้ LLM สรุปและตั้งคำถามจากเนื้อหาแล้วเก็บไว้ใน vector DB
แต่ RAG pipeline แบบครอบจักรวาล ที่ใช้ได้กับทุกกรณียังเป็นโจทย์ยากอยู่ดี
เลยสงสัยด้วยว่า vector DB จัดการกับกลุ่มข้อความยาว ๆ กับข้อมูลรูปแบบตาราง แบบไหนได้ดีกว่ากัน
มุมมองใหม่ที่เอา full-text search มาใช้กับ RAG น่าสนใจมาก
อินไซต์เกี่ยวกับลูปของเครื่องมือแบบ agent และวิธีจัดการ fuzzy search ก็น่าประทับใจ
สงสัยว่ามี ชุดข้อมูลสำหรับประเมินผล ของระบบแบบนี้ที่เป็นมาตรฐานหรือไม่
ถ้ามี benchmark ที่ประกอบด้วยชุดเอกสารและชุดคำถาม โดยที่เอกสารหรือ chunk ที่ถูกต้องควรขึ้นมาเป็นผลลัพธ์ที่เกี่ยวข้องที่สุด ก็น่าจะดี