AI Capstone: ผู้ช่วยตอบคำถามจากฐานความรู้ (RAG)
ประมาณ 25 นาที
เป้าหมายของบท
- สร้างผู้ช่วยตอบคำถามแบบ RAG ตั้งแต่ retrieval, prompt, การเรียกโมเดล, การตรวจผล จนถึงการประเมินด้วยตัวเลข
- ใช้ rubric ตรวจงานตัวเอง (baseline, การอ้างอิง, คำถามนอกขอบเขต, ต้นทุน, ความลับของ API key) ก่อนเผยแพร่
- เผยแพร่ notebook พร้อม README ที่บอกวิธีรันแบบออฟไลน์และข้อจำกัดอย่างซื่อตรง
Notebook
งานหลักของบทนี้ทำใน Jupyter notebook ไม่ใช่ในเว็บ — โหลดไฟล์ไปเปิดในเครื่อง หรือเปิดตรงบน Google Colab ก็ได้
โจทย์
สร้าง ผู้ช่วยตอบคำถามลูกค้าจากฐานความรู้ร้านค้า (kb_docs.csv 24 เอกสาร + ชุดคำถามมีเฉลย kb_questions.csv 30 ข้อ) ที่:
- ค้นหาเอกสารที่เกี่ยวข้อง (retrieval)
- ประกอบ prompt ที่ยึดบริบท อ้างอิง doc id และตอบ “ไม่รู้” เมื่อไม่มีข้อมูล
- เรียกโมเดลสร้างคำตอบ (ใน notebook ต่อ API จริงได้ หรือใช้ตัวสำรองแบบไม่ต้องมี API key)
- ตรวจผลลัพธ์ (การอ้างอิง) และ fallback
- ประเมินผลด้วยตัวเลข ทั้ง retrieval และคำตอบ พร้อมวิเคราะห์จุดที่พลาด
เตรียมตัว
ดาวน์โหลด notebook เริ่มต้นด้วยปุ่มด้านบน มีเซลล์ที่รันได้ทั้งหมดแบบ ออฟไลน์ (retrieval ด้วย TF-IDF, ตัวสร้างคำตอบสำรองแบบสกัดประโยค) และเซลล์ที่ต่อ API จริงเมื่อคุณตั้งค่า ANTHROPIC_API_KEY
เก็บ API key ไว้ในตัวแปรสภาพแวดล้อมหรือ Colab Secrets เท่านั้น ห้ามพิมพ์ลงใน notebook หรือ commit ขึ้น GitHub
ตัวเลขอ้างอิงจากบทเรียน (TF-IDF + stop words บน 30 คำถาม)
- retrieval: hit@1 0.6333, hit@3 0.8333, MRR 0.752 — จุดอ่อนอยู่ที่หมวด returns และคำถามที่ใช้คำต่างจากเอกสาร (paraphrase)
- ตัวสำรองแบบสกัดประโยค: ประโยคที่เลือกมาจากเอกสารเฉลย 19 จาก 30 ข้อ (0.6333)
- ตัวเลขเหล่านี้คือ baseline ที่ต้องเอาชนะ — โมเดลจริงและ retrieval ที่ดีขึ้น (embeddings, hybrid, query expansion) ควรทำได้ดีกว่า แต่ต้องวัดเอง ไม่ต้องเชื่อว่าจะดีกว่า และอย่าจูนกับ 30 ข้อเดียวจนแนบชุดนั้น (เขียนชุดคำถามใหม่อีกอย่างน้อย 10 ข้อไว้ตรวจสุดท้าย)
Rubric ตรวจงานตัวเอง
- มี baseline และตัวเลข retrieval (hit@k, MRR) พร้อมวิเคราะห์หมวดที่พลาด
- prompt สั่งให้ยึดบริบท อ้างอิง doc id และปฏิเสธเมื่อไม่มีข้อมูล
- มีการตรวจฝั่งโค้ด: id ที่อ้างต้องอยู่ในชุดที่ดึงมา, มี fallback เมื่อไม่ผ่าน
- มีชุดคำถามนอกขอบเขตและวัดว่าระบบปฏิเสธถูกกี่ข้อ
- ประมาณต้นทุนต่อคำถามและต่อเดือน (บอกว่าใช้ราคาสมมติหรือราคาจริงจากผู้ให้บริการ)
- ไม่มี API key/ข้อมูลส่วนบุคคลใน repo
- notebook รันได้ทั้งไฟล์จากบนลงล่าง (อย่างน้อยเส้นทางออฟไลน์) โดยไม่ error
- มีหัวข้อ “ข้อจำกัด” และ “ทำอะไรต่อ” ที่ซื่อตรง
ต่อยอด (ถ้ามีเวลา)
- ใช้ embedding model จริงแทน TF-IDF แล้วเทียบด้วยชุดคำถามเดิม
- เพิ่มเครื่องมือ (เช่น ดูสถานะออเดอร์จากตาราง orders) ให้กลายเป็น agent ที่ตอบได้ทั้ง “นโยบาย” และ “ข้อมูลลูกค้า” พร้อมกันสิทธิ์ตาม module agents
- ทำหน้าเว็บ/CLI เล็กๆ และบันทึก log คำถาม-คำตอบ-ต้นทุน
เผยแพร่บน GitHub
repo สาธารณะ + notebook + README.md (โจทย์ วิธีรันทั้งแบบออฟไลน์และแบบมี API key ตัวเลขประเมินผลและข้อจำกัด) — ย้ำใน README ว่า key ถูกเก็บนอก repo แล้วแปะลิงก์ใน resume/LinkedIn
แบบฝึกท้ายบท
บทนี้จะนับว่าเสร็จเมื่อผ่านข้อพื้นฐานและประยุกต์ครบ ข้อท้าทายได้ดาวเพิ่ม
🟢 พื้นฐาน
ตรวจว่าข้อมูลพร้อม: docs มีกี่เอกสาร (n_docs) qs มีกี่คำถาม (n_questions) และเอกสารเฉลยของคำถามทั้งหมดครอบคลุมกี่เอกสารที่ไม่ซ้ำ (n_gold_docs)
baseline retrieval: อันดับ 1..3 ของ retrieve (ให้ไว้ ค้นด้วย TF-IDF + stop words) มีเอกสารเฉลยอยู่กี่สัดส่วนของคำถามทั้งหมด (hit@3 ปัด 4 ตำแหน่ง) เก็บไว้ในตัวแปร hit3
🟡 ประยุกต์
ประมาณต้นทุน: ประกอบ prompt ของทุกคำถามด้วย TEMPLATE_RAG (context = top-3 ในรูป "[doc_id] title: text" หนึ่งบรรทัดต่อเอกสาร) แล้วหา token ที่ประมาณ (est_tokens) เฉลี่ยต่อคำถาม (ปัด 2 ตำแหน่ง) เก็บไว้ใน avg_prompt_tokens และต้นทุน input ต่อวัน (USD) ถ้ามี 1,000 คำถามต่อวันที่ราคาสมมติ 3.0 USD ต่อ 1 ล้าน token (ปัด 4 ตำแหน่ง) ไว้ใน daily_input_cost
สรุป
- Capstone RAG: retrieval → prompt ที่ยึดบริบท/อ้างอิง/ปฏิเสธ → เรียกโมเดล (API จริงหรือตัวสำรอง) → ตรวจ+fallback → ประเมินด้วยตัวเลขและวิเคราะห์จุดที่พลาด
- baseline จากบทเรียน: hit@3 0.8333, MRR 0.752, ประโยคจากเอกสารเฉลย 0.6333 — วัดเองเมื่อปรับปรุง และเก็บชุดคำถามใหม่ไว้ตรวจสุดท้าย
- เก็บ API key นอก repo เสมอ; รายงานข้อจำกัดและต้นทุนอย่างตรงไปตรงมา
คำถามสัมภาษณ์
เล่าโปรเจกต์ RAG ของคุณใน 1 นาทีให้คนสัมภาษณ์ฟัง
โครง: ปัญหา (ตอบคำถามลูกค้าจากฐานความรู้) → สถาปัตยกรรม (chunk/ค้นหา/prompt ที่ยึดบริบทและอ้างอิง/ตรวจผล/fallback) → วิธีประเมิน (ชุดคำถามมีเฉลย hit@k MRR อัตราการปฏิเสธถูก การอ้างอิงถูกต้อง ต้นทุนต่อคำถาม) → ผลและสิ่งที่พลาด (เช่น หมวด returns ที่ paraphrase) → สิ่งที่ทำต่อ (embeddings, hybrid, reranker) การชี้จุดอ่อนพร้อมตัวเลขทำให้น่าเชื่อถือ