Tool: rag_search — ค้นเอกสารในคลังด้วย pipeline expand→retrieve→rerank→gate
rag_search เป็นเครื่องมือหลักของ ENDEAVOR RAG สำหรับค้นหาส่วนของเอกสารที่ตรงกับคำถาม แล้วส่งเฉพาะบริบทที่เกี่ยวข้องให้โมเดลตอบ ไม่ใช่ส่งทั้งคลังความรู้ทุกครั้ง
Tool นี้คืออะไร
ค้นคลังความรู้ในเครื่อง คืนผลเป็น 2-3 chunk ที่เกี่ยวข้องที่สุดพร้อมแหล่งอ้างอิง — เป็น tool เดียวที่รวม pipeline ทั้งหมดที่อธิบายไว้ใน บทความ how it works เข้าด้วยกัน: expand → retrieve (hybrid RRF) → rerank (LLM) → quality gate จากมุมมองของโมเดลที่เรียกใช้ นี่คือการเรียก tool เดียว แต่เบื้องหลังมี 4 ขั้นตอนทำงานต่อกันเป็นลูกโซ่
Agent เรียก tool นี้เมื่อไร
Docstring บอกไว้ชัดเจนทั้งด้านที่ควรและไม่ควรเรียก: ใช้เมื่อคำถามอาจมีคำตอบอยู่ในคลังความรู้ — และห้ามใช้กับ “general knowledge, math, small talk, or coding questions” เพราะสิ่งเหล่านั้นไม่ใช่เนื้อหาที่คลังความรู้เก็บไว้ การเรียก rag_search กับคำถามที่ไม่เกี่ยวกับเอกสารในคลังจะได้ผลลัพธ์ที่ไม่มีความหมาย (หรือ [low_quality]) เปล่าประโยชน์
สัญญาณ [low_quality]: tool บอกตัวเองว่าไม่มั่นใจ
จุดที่สำคัญที่สุดของ contract ของ tool นี้: ผลลัพธ์อาจขึ้นต้นด้วย [low_quality] — เป็นสัญญาณที่คำนวณจากตัวเลขจริง (คะแนน dense สูงสุด, จำนวนผลลัพธ์, การมี lexical hit ยืนยันหรือไม่ ตามที่อธิบายละเอียดใน how it works) ไม่ใช่ความเห็นของโมเดล — docstring บอกโมเดลตรงๆ ว่า “caller should retry with rephrased query” เมื่อเจอ prefix นี้ แทนที่จะสรุปคำตอบจาก context ที่ไม่น่าเชื่อถือราวกับมั่นใจเต็มร้อย
ผลลัพธ์มาพร้อม path เต็มของแหล่งอ้างอิงเสมอ
Format ผลลัพธ์เริ่มด้วยบรรทัด SOURCES: ที่มี absolute path ของทุกไฟล์ต้นทาง (ผ่าน _to_abs/source_path ที่ตรวจสอบว่า path นั้นอยู่ในขอบเขต knowledge root จริง) ตามด้วยเนื้อหาแต่ละ chunk ที่ระบุชื่อไฟล์และคะแนนของมันกำกับ (retriever=hybrid, score=0.812 เป็นต้น) — ให้ผู้ใช้ตรวจสอบย้อนกลับได้เสมอว่าคำตอบมาจากไฟล์ไหนจริง ไม่ใช่แค่ข้อความสรุปลอยๆ
ทำไมเรื่องนี้ถึงสำคัญ
rag_search เป็นตัวอย่างของ tool ที่ซับซ้อนข้างในมาก แต่ interface ง่ายมาก — โมเดลแค่ส่ง query string เข้ามา ไม่ต้องรู้เลยว่าเบื้องหลังมีการขยาย query เป็น 3 แบบ ค้นแบบ hybrid สองวิธี รวมคะแนนด้วย RRF และให้ LLM อีกตัวช่วย rerank — ความซับซ้อนทั้งหมดถูกซ่อนไว้หลัง interface เดียว และสื่อสารกลับมาแค่สัญญาณเดียวที่โมเดลต้องรู้จริงๆ: ผลลัพธ์นี้เชื่อถือได้แค่ไหน ([low_quality] หรือไม่)
ความคิดเห็น
กำลังโหลดความคิดเห็น...