Tool: rag_search — ค้นฐานความรู้ส่วนตัวที่ไม่ได้แถมมาด้วย พร้อม diagnostics ทุกครั้ง
rag_search ค้นฐานความรู้ ของผู้ใช้เอง ที่เตรียมไว้ล่วงหน้า (เอกสารส่วนตัว, โน้ต, ไฟล์อ้างอิง) — ต่างจาก web_search ที่ค้นอินเทอร์เน็ตสาธารณะ
Tool นี้คืออะไร
เป็นแค่ wrapper ที่เรียก RAG engine แยกต่างหาก (BM25 + vector search + RRF fusion) ไม่ใช่ implementation เต็มรูปแบบอยู่ในตัวเอง — engine ตัวจริงเป็นอีกโปรเจกต์ที่ไม่ได้แถมมาในรีโปนี้ ผู้ใช้ต้อง clone เองแยกไว้เป็นโฟลเดอร์พี่น้องข้างๆ ตัวโปรเจกต์หลัก โดยชื่อโฟลเดอร์ต้องเป็น ENDEAVOR_RAG_LITE เท่านั้น เพราะ path นี้ hardcode ไว้ในโค้ด (_RAG_DIR ใน rag_tool.py ชี้ไปที่ ../../ENDEAVOR_RAG_LITE) — git clone https://github.com/halochamp/ENDEAVOR_RAG_LITE ได้ชื่อโฟลเดอร์ถูกต้องอยู่แล้วโดยไม่ต้องเปลี่ยนชื่อเอง
ทำไมถึงไม่แถม knowledge base มาด้วย
โปรเจกต์นี้เป็น public repo — ฐานความรู้ส่วนตัว (เอกสารการเงิน, โน้ตส่วนตัว, ไฟล์งาน) ของใครก็ตามที่พัฒนาโปรเจกต์นี้ไม่ควรหลุดเข้า public repo เด็ดขาด ทางเลือกคือแยก concern ให้ชัด: รีโปนี้แถมแค่ความสามารถ (tool ที่รู้วิธีคุยกับ RAG engine) ส่วนข้อมูลเป็นเรื่องที่ผู้ใช้แต่ละคนต้องจัดการเอง ไม่ผูกติดกับโค้ดที่แจกจ่ายสาธารณะ
ตรวจก่อนเสมอ ไม่ปล่อยให้พังเงียบๆ
ก่อนพยายามค้นหาทุกครั้ง ระบบเช็คก่อนว่า engine มีอยู่จริงไหม (_rag_engine_available()) — ถ้าไม่เจอ ไม่ error ห้วนๆ หรือ crash แต่ตอบกลับเป็นข้อความบอกตรงๆ ว่าต้อง clone/สร้างอะไรที่ path ไหน ให้ agent เอาไปบอกผู้ใช้ต่อได้ทันที แทนที่จะให้ agent เดาว่าเกิดอะไรขึ้นจากข้อความ error ที่ไม่มีความหมาย
ถ้า engine มีอยู่แต่ import ไม่สำเร็จ (เช่น dependency ของ engine เองยังไม่ครบ, ยังไม่ได้ build index) ระบบแยกแยะกรณีนี้ออกจากกรณี “ไม่มี engine เลย” ด้วย — ข้อความ error จะบอกว่า engine เจอแล้วแต่ import ไม่ผ่าน ให้ไปเช็ค setup ของ engine เอง ไม่ใช่ของ tool ตัวนี้
ใส่ diagnostics มาให้ทุกครั้ง ไม่ใช่แค่คืนผลลัพธ์ดิบ
ผลลัพธ์ที่ค้นเจอมาพร้อม RAG_DIAGNOSTICS เสมอ — สรุปว่าคำตอบนี้ควรเชื่อได้แค่ไหนก่อนที่โมเดลจะเอาไปสังเคราะห์คำตอบ:
answerability—direct(ใช้ตอบได้เลย),partial_need_full_file(ควรเปิดไฟล์เต็มก่อนสรุป), หรือlikely_mismatch(คำที่ค้นเจอไม่ตรงกับคำถามจริงมากพอ ห้ามอ้างเป็น [KB] เฉยๆ)matched_query_terms/missing_query_terms— คำสำคัญจากคำถามที่เจอ/ไม่เจอในผลลัพธ์ เทียบง่ายๆ ว่าค้นถูกเรื่องไหมretriever_coverage— จำนวน hit จากฝั่ง dense (vector) กับ BM25 แยกกัน ถ้าฝั่งใดฝั่งหนึ่งเป็น 0 แปลว่าผลลัพธ์มาจาก retriever เดียว ความมั่นใจต่ำกว่าตอนทั้งสองฝั่งเจอตรงกัน
การออกแบบนี้ทำให้ agent (และคนอ่าน log) เห็นได้ทันทีว่า “เจอผลลัพธ์” กับ “เจอผลลัพธ์ที่เชื่อถือได้” เป็นคนละเรื่องกัน แทนที่จะต้องเดาจากเนื้อหาดิบเอง
ต้องกรอก query 4 แบบ ไม่ใช่แค่ 1 คำถาม
รับ sentence_th, sentence_en, keywords_th, keywords_en แยกกัน — แต่ละแบบค้นแยกกันทั้ง dense + BM25 แล้วเอาผลมา fuse ด้วย RRF (Reciprocal Rank Fusion) เหตุผลคือฐานความรู้อาจมีเอกสารทั้งภาษาไทยและอังกฤษปนกัน คำถามเดียวแบบภาษาเดียวจะพลาดเอกสารที่เขียนเป็นอีกภาษาไปเลย — การบังคับให้ agent เตรียมทั้ง 4 มุมก่อนค้นทุกครั้งเพิ่มโอกาสเจอเอกสารที่เกี่ยวข้องจริงข้ามภาษา
ทำไมเรื่องนี้ถึงสำคัญ
rag_search เป็นตัวอย่างที่ชัดว่า public repo ไม่จำเป็นต้องแจกทุกอย่างมาให้ครบเพื่อจะมีประโยชน์ — สิ่งที่แจกคือความสามารถที่ออกแบบมาอย่างรอบคอบ (diagnostics บอกความน่าเชื่อถือ, error message ที่ actionable, 4-query fusion กันพลาดข้ามภาษา) ส่วนข้อมูลจริงเป็นทางเลือกของผู้ใช้แต่ละคนที่จะเติมเข้าไปเอง — โครงสร้างนี้แยก “โค้ดที่แจกจ่ายได้อย่างปลอดภัย” ออกจาก “ข้อมูลที่ไม่ควรแจกจ่าย” อย่างชัดเจนตั้งแต่การออกแบบ ไม่ใช่มาแก้ทีหลัง
ความคิดเห็น
กำลังโหลดความคิดเห็น...