บทที่ 07 · ประกอบ Harness · Grounding & Verification
Grounding & Verification
ผู้ช่วยตอบว่าจองได้ที่ “ห้อง Lab 9” — ทั้งที่ห้องนั้นไม่มีอยู่จริง โมเดล ทำนายข้อความ
มันไม่ได้ “เห็น” โลกจริง บทนี้คือการลดช่องว่างระหว่างสิ่งที่โมเดล คิดว่า จริง กับสิ่งที่
เป็น จริง: ตอบจากข้อมูลจริง ตรวจจากสภาพแวดล้อม (ไม่ใช่จากคำพูดของตัวเอง) และกั้นการกระทำที่ย้อนไม่ได้ด้วยมนุษย์
พูดแบบเข้าใจง่าย
LLM ทำนายข้อความ มันไม่ได้สังเกตโลก ปล่อยไว้เฉย ๆ มันจะรายงานว่า “จองแล้ว” “พบ 3 ห้องว่าง” ได้สบายมาก
ไม่ว่าจะเกิดขึ้นจริงหรือไม่ หน้าที่ของ harness คือ หดช่องว่างระหว่าง “คิดว่าจริง” กับ “เป็นจริง” ด้วย 3 ทาง:
- Grounding — เครื่องมือคืน สถานะจริง (อ่านค่ากลับจากระบบ, สถานะ HTTP จริง) ให้รอบถัดไปคิดจากข้อเท็จจริง ไม่ใช่การเดา
- Schema-first — ยื่น “ค่าที่ใช้กรองได้จริง” ให้ก่อน โมเดลจะได้ กรองด้วยห้อง/รุ่นที่ไม่มีจริงไม่ได้
- Human-in-the-loop gate — ก่อนการกระทำที่ย้อนไม่ได้ ต้อง echo-back สิ่งที่เข้าใจ แล้วรอ “ใช่” และเครื่องมือเองก็ปฏิเสธถ้าไม่มีธง confirmed=true
สำคัญ: การ verify ต้องมาจากช่องทางที่เป็นอิสระจากโมเดล — ถามโมเดลซ้ำว่า “สำเร็จไหม” คือการวิ่งชนจุดบอดเดิม
เปรียบเทียบ: ช่างสำรวจปักหมุดก่อนเทคอนกรีต
ช่างสำรวจไม่เชื่อพิกัดในแบบแปลนเฉย ๆ — เขาเดินไปที่มุมจริง ตั้งกล้อง แล้วยิงค่าจริงบนพื้นก่อนเท
แบบแปลน = คำพูดมั่นใจของโมเดล; การยิงค่าด้วยกล้อง = grounding ที่คืนสถานะจริง; ตารางพิกัดที่ใช้ได้ = schema-first
(ปักนอกกริดไม่ได้ เหมือนกรองด้วยห้องที่ไม่มีไม่ได้); และโฟร์แมนเซ็นอนุมัติก่อนเท โดยมองพื้นจริง ไม่ใช่อ่านแบบซ้ำ = gate ที่ตรวจจากช่องทางอิสระ
ในระบบของเรา — ตอบจากของจริง ปักหมุดก่อนกระทำ
คำถาม“มีห้องว่างพฤหัสบ่ายไหม?”
→
Schema-firstยื่นรายชื่อห้อง/ช่วงเวลาที่มีจริงก่อน → เดาห้องที่ไม่มีไม่ได้
→
Groundingดึงสถานะจริงกลับมา (ว่าง/ชน/ปิด)
→
Gateถ้าจะ “จอง” ต้อง echo-back + รอ “ใช่” ก่อนถึงจะยิงจริง
ในระบบจริง เครื่องมือเขียนปฏิทินของเราจะ ปฏิเสธจนกว่าจะมี confirmed=true — รอบแรกมันคืนข้อความว่า
“ยังไม่ยืนยัน โปรด echo-back ให้ผู้ใช้ก่อน” ไม่มีอะไรถูกเขียนเลย และกลุ่มเครื่องมือข้อมูลก็เป็น schema-first
(เรียก “ดูรายการที่มีจริง” ก่อนเสมอ) ผู้ช่วยจึงตอบว่า “ไม่มีรุ่น 70 รุ่นล่าสุดคือ 68” แทนที่จะแต่งจำนวนขึ้นมา
ทำพลาด vs ทำถูก
⚠️ แย่ · เชื่อ “สำเร็จ!” มากกว่าคำตอบจริงของระบบ
เขียนแล้วไม่อ่านค่ากลับ
เครื่องมือส่งคำขอแล้วถือว่าสำเร็จทันทีโดยไม่ดูสถานะตอบกลับ — เคยเกิดจริงในระบบเรา: payload ผิดทำให้เซิร์ฟเวอร์คืน 500
แต่ผู้ช่วยรายงาน “ส่งเรียบร้อย” งานยังค้างเป็นฉบับร่าง รู้ตอนคนเปิดดูเอง
⚠️ แย่ · ใช้ self-report เป็นการ verify
ถามโมเดลว่า “สำเร็จไหม”
“บันทึกแล้ว 24 รายการ” ทั้งที่ไม่มีการนับจริง — โมเดลสรุปจากข้อความของตัวเอง ถ้าเขียนพลาดเงียบ ๆ มันก็ยังตอบ “สำเร็จ”
เพราะมันทำนาย รูปร่างของข้อความสำเร็จ ไม่ได้อ่านจำนวนแถวจริง
✅ ดี · gate ฝั่งเซิร์ฟเวอร์ + schema-first
ปักหมุดก่อนเท
การกระทำที่ย้อนไม่ได้ถูกบังคับด้วย confirmed=true ในโค้ด (ไม่ใช่แค่ความสุภาพใน prompt) และการกรองทำได้เฉพาะค่าที่
ระบบบอกว่ามีจริง — โมเดลจึงเดาห้อง/รุ่นที่ไม่มีไม่ได้ และ verify มาจากการอ่านสถานะจริงกลับมาเสมอ
ลองเอง — เลือกแหล่ง verify ที่จับโกหกได้
กิจกรรม · เกมตัดสินใจ
Trust but Verify: Catch the Lie
แต่ละรอบ ผู้ช่วยรายงานบางอย่างอย่างมั่นใจ — แต่มันโกหก เลือก หนึ่ง แหล่งตรวจสอบ
แล้วดูว่าแหล่งไหนจับได้จริง คุณจะรู้สึกเองว่ามีแค่แหล่งที่ “แตะโลกจริง” เท่านั้นที่ไว้ใจได้
เลือกแหล่งตรวจสอบในแต่ละรอบ
มองไปข้างหน้า — ปักหมุดได้แล้ว แต่ใครให้สิทธิ์มันลงมือ?
grounding หยุดการ “แต่งเรื่อง” ได้ แต่ยังมีคำถามว่า มันควรได้รับอนุญาตให้ทำอะไรบ้าง
บทที่ 08 ว่าด้วย Permissions & Safety — แยก “อ่าน” ออกจาก “ทำ” และกั้นสิ่งที่ย้อนไม่ได้
สรุปบทที่ 07
- LLM ทำนายข้อความ ไม่ได้สังเกตโลก — “สำเร็จ!” คือการทำนาย ไม่ใช่หลักฐาน
- หดช่องว่างด้วย grounding (คืนสถานะจริง), schema-first (ค่าที่ใช้ได้จริง), HITL gate
- verify ต้องมาจากช่องทางอิสระ — self-report และ success toast โกหกได้
- กั้น “การกระทำที่ย้อนไม่ได้” ด้วย confirmed=true ในโค้ด ไม่ใช่แค่คำขอร้องใน prompt
Harness Scorecard · มิติ: “ตอบจากของจริง + verify จากช่องทางอิสระไหม?”
ผู้ช่วยจัดการแล็บ ✅ — schema-first กันการเดา, gate ฝั่งเซิร์ฟเวอร์กันการเขียนพลาด
📋 build-your-harness checklist · บรรทัดที่ 7
“grounding + schema-first + verify จากช่องทางอิสระ + gate การกระทำที่ย้อนไม่ได้”