RAG สำหรับการสนับสนุนลูกค้า: ทำอย่างไรให้คำตอบของ AI แม่นยำจริง

หากไม่มีการค้นคืน LLM ที่ตอบคำถาม "ฉันจะรีเซ็ตรหัสผ่านได้อย่างไร?" จะให้คำตอบที่ฟัง ดูสมเหตุสมผลแต่มักจะผิด — ปุ่มคนละปุ่ม ขั้นตอนคนละแบบ URL คนละอัน RAG (การสร้างที่เสริมด้วยการ ค้นคืน) แก้ปัญหานี้ด้วยการแทรกชิ้นส่วน (chunk) ที่ถูกต้องจากเอกสารของคุณเข้าไปใน prompt ก่อนที่ โมเดลจะพูด

ภาพรวมของไปป์ไลน์

สามขั้นตอน: นำเข้า ค้นคืน และสร้าง

1. นำเข้า

• อัปโหลดไฟล์ PDF, Markdown และ Office ผ่านหน้าจัดการความรู้
• Worker ดึงข้อความออกมา แล้วแบ่งเป็นชิ้นละประมาณ 800 token โดยซ้อนทับกัน 100 token
• แต่ละชิ้นถูกฝัง (embed) ด้วย text-embedding-3-small (1536 มิติ)
• จัดเก็บใน Postgres พร้อมส่วนขยาย pgvector

2. ค้นคืน

เมื่อผู้เยี่ยมชมส่งข้อความเข้ามา เราจะฝังคำค้นแล้วทำการค้นหาด้วยระยะโคไซน์เทียบกับชิ้นส่วน ของผู้เช่า (tenant) นั้น Top-K (ค่าเริ่มต้น 5) จะถูกดึงเข้ามา พร้อมเกณฑ์ความคล้ายเพื่อตัด การจับคู่ที่ไม่เกี่ยวข้องออก

SELECT id, content, 1 - (embedding <=> $1) AS similarity
FROM knowledge_chunks
WHERE tenant_id = $2
ORDER BY embedding <=> $1
LIMIT 5;

3. สร้าง

ชิ้นส่วนที่ค้นคืนมาจะถูกวางไว้ด้านหน้าของ system prompt พร้อมคำสั่งที่ชัดเจน: อ้างอิงแหล่ง ที่มา ปฏิเสธหากบริบทไม่ครอบคลุมคำถาม และส่งต่อให้เจ้าหน้าที่ที่เป็นมนุษย์หากความมั่นใจต่ำ

ลดบิลค่า token

สามเทคนิคที่ช่วยประหยัดเงินจริงบนฐานความรู้ขนาดใหญ่:

• แคชการฝัง (embedding) — ข้อความค้นเดียวกัน → การฝังเดียวกัน ใช้คีย์แฮช SHA1 ตั้ง TTL 24 ชั่วโมงใน Redis ลดต้นทุนการฝังซ้ำให้เป็นศูนย์สำหรับคำถามที่ถามซ้ำ
• การแคช prompt — cache_control ของ Anthropic และการแคช อัตโนมัติของ OpenAI ทำให้ system prompt แบบคงที่ถูกนับเพียงครั้งเดียวต่อหน้าต่าง 5 นาที
• การข้ามตามเกณฑ์— หากไม่มีชิ้นส่วนใดผ่านเกณฑ์ความคล้าย ก็อย่าแทรก อะไรเลย ปล่อยให้โมเดลพูดว่า "ฉันไม่ทราบ"

เมื่อ RAG ยังไม่พอ

RAG จัดการคำถามแบบ "ฉันจะทำ X ได้อย่างไร?" ได้ดี แต่ล้มเหลวกับข้อมูลเฉพาะบุคคล ("คำสั่งซื้อของฉันอยู่ที่ไหน?") — สิ่งนั้นต้องใช้ การเรียกฟังก์ชัน (function calling) ซึ่งเราจะกล่าวถึงในบทความแยกต่างหาก การผสานทั้งสองอย่างนี้คือสิ่งที่ทำให้คุณ ได้ AI ระดับ Intercom ในราคาเพียงเศษเสี้ยวของต้นทุน