การออกแบบที่ตรงกันข้ามกับเดิม
ใน chatbot รุ่นแรก ๆ FAQ ที่คนเขียนเองมักจะถูกใช้เป็น "ตาข่ายรองรับ" — เมื่อ AI ไม่สามารถตอบได้ ระบบจะตกลงไปใช้ FAQ ที่เคยเขียนเอาไว้ แต่ใน Sapien RESPOND เราออกแบบตรงกันข้าม — FAQ ที่คนยืนยันแล้วคือชั้นแรก ส่วน generative search คือชั้นรอง
เหตุผลตรงไปตรงมา: เราอยากให้ส่วนของระบบที่คนตรวจสอบได้ง่ายที่สุด ทำงานในกรณีที่คาดเดาได้บ่อยที่สุด
โครงสร้างของระบบ
Sapien RESPOND มี pipeline สามชั้น:
- Embedding match กับคู่ FAQ ที่คนยืนยันแล้ว ถ้า similarity > threshold → ตอบจาก FAQ ตรง ๆ
- ถ้าไม่ผ่าน threshold → เข้า generative search บนเอกสารองค์กร พร้อม citation
- ถ้า generative search ไม่มี source ที่มั่นใจพอ → ส่งต่อให้คน พร้อมข้อมูลที่รวบรวมไว้
การ trade-off ที่ตามมา
การออกแบบแบบนี้ trade-off กับ "ความฉลาดผิวเผิน" — บางครั้งคำตอบที่ออกมาจะเรียบ ๆ ไม่ปรับให้เข้ากับบริบทคำถามมากนัก เพราะมันคือคำตอบที่เคยเขียนไว้ตรง ๆ แต่สิ่งที่เราได้กลับมาคือ:
- ผู้ใช้สามารถแยกแยะได้ว่าคำตอบใดมาจากคน คำตอบใดมาจากการ generate
- ทีมที่ดูแลระบบสามารถปรับ FAQ ได้โดยตรง โดยไม่ต้องผ่าน prompt engineering
- เมื่อมีการเปลี่ยนนโยบาย — แก้ FAQ ก็จบ ไม่ต้องเทรนใหม่
แล้ว long tail ล่ะ
คำถามที่ไม่ตรงกับ FAQ จะเข้าสู่ generative search ส่วนนี้คือ "ส่วนที่ฉลาด" ของระบบจริง ๆ มันใช้ vector search บนเอกสารองค์กรที่ผ่านการ ingest แล้ว และให้คำตอบพร้อม citation ที่กดดูได้
เมื่อ generative search ตอบสำเร็จและคำถามนั้นถูกถามซ้ำเกิน 3 ครั้ง — ระบบจะ flag ขึ้นมาให้ทีม content เห็นว่า "ควรเพิ่มเข้า FAQ" คำถามใหม่ ๆ ค่อย ๆ เลื่อนขึ้นมาเป็นคำตอบที่ยืนยันแล้ว
ผลในระบบจริง
ใน 12 เดือนที่ใช้งานในสำนักงานบุคลากร KMUTT:
ตัวเลขที่น่าสนใจที่สุดคือ "0 ครั้งที่ตอบผิดในชั้น FAQ" — เพราะมันคือคำตอบที่คนเขียนเอง ถ้าผิดก็คือคนเขียนผิด แต่ส่วนนี้เราตามแก้ได้ตรง ๆ ไม่ต้องผ่านการ train
ก้าวต่อไป
เรากำลังพัฒนา UI ใหม่ที่ให้ทีม content เห็น "candidate FAQ" — คำถามที่ generative search ตอบดี และน่าจะถูกเลื่อนขึ้นชั้น FAQ — เป็น dashboard รายสัปดาห์ เพื่อให้กระบวนการนี้ไม่ต้องอาศัย vigilance ของคนคนเดียว
