Capstone — ออกแบบ Harness ของคุณเอง
ใช้ checklist ที่สะสมมาทั้งคอร์ส ออกแบบ harness ให้สถานการณ์ที่คุณเลือก — เลือกขั้นบันได เครื่องมือ การ์ดกั้น และ eval ไม่ต้องเขียนโค้ด — เป็นดีไซน์ที่ปกป้องได้ต่อหน้าวิศวกรอาวุโส และก่อนอื่น มาเก็บบทเรียนสุดท้าย: ลูปนั้นไม่ขึ้นกับ modality — เสียง ภาพ การสัมผัส เป็นแค่ของที่ “คลิป” ไว้ที่ขอบ
พูดแบบเข้าใจง่าย
harness คือลูปเล็ก ๆ: ยื่นข้อความ + รายการ tool ให้โมเดล → มันตอบหรือขอเรียก tool → รัน tool → ป้อนผลกลับ → วนจนตอบ ลูปนี้ รู้จักแค่ข้อความกับการเรียก tool — มันไม่รู้ว่าข้อความมาจากคีย์บอร์ดหรือไมโครโฟน และไม่สนว่าคำตอบจะถูกพิมพ์ พูด หรือลิปซิงค์
ดังนั้น “multimodal” ไม่ใช่ลูปแบบใหม่ แต่คือชิ้นส่วนที่คลิปไว้ที่ ขอบ ของลูป: STT ขาเข้า, TTS + avatar ขาออก, และ RAG = tool อีกตัว ที่ลูปเรียกได้ · harness ขั้นต่ำที่ไว้ใจได้ = ลูป + tool + verify + trace + eval ส่วน sense เป็นวงแหวนนอกที่ใส่เพิ่มทีหลังได้
เปรียบเทียบ: drivetrain ของรถ
เครื่องยนต์ + เกียร์ + พวงมาลัย = ลูป · กล้องถอยหลัง ไมค์สั่งงาน จอแดชบอร์ด = sense ที่บล็อกเข้ากับ ขอบ
คุณไม่เคยผ่าบล็อกเครื่องยนต์เพื่อใส่กล้องถอย — สเปก drivetrain ไม่เปลี่ยน sense คลิปที่ขอบ
ในระบบของเรา — sense 3 อย่างบนลูปเดียวที่ไม่เปลี่ยน
voice-inเสียง → ข้อความ (เข้า query เดิม)
→
LOOPลูปเดิม: เรียก tool · verify · ตอบ
→
voice-out + avatarข้อความ → เสียง + ลิปซิงค์
ในระบบจริง query เดียวกัน ให้บริการทั้งคำถามที่พิมพ์ พูด และที่มาทาง LINE — เสียง (STT บนเบราว์เซอร์ + TTS), RAG, และ avatar ถูกแยกไว้ นอก ลูป เพื่อให้ลูปยังเป็น text-in/text-out, อยู่ในงบเวลา และนำกลับมาใช้ได้ทั้งบนเดสก์ท็อป LINE และการรันทดสอบเงียบ ๆ
ทำพลาด vs ทำถูก
⚠️ แย่ · เชื่อม sense เข้าไป “ใน” ลูป
เอา TTS ไปไว้ในลูปที่จับเวลา
ให้ลูปสังเคราะห์เสียงและรอเล่นจบ ก่อน คืนค่า — ลูปพึ่ง GPU, พังบนเซิร์ฟเวอร์ไร้ลำโพง,
และเวลาเล่นเสียงไปกินงบ timeout จนงานยาว ๆ หลุด — เท่ากับ “บัดกรี” modality ติดตายเข้ากับเครื่องยนต์
⚠️ แย่ · capstone ที่ไม่มี verify จริง + ไม่มี trace
เชื่อ “เสร็จแล้ว” ของโมเดล
ลูป + 2 tool ที่พิมพ์ SUCCESS เพราะโมเดลบอกว่าสร้างไฟล์/ส่งอีเมลแล้ว — ทั้งที่ไม่เคยเช็คว่าไฟล์มีจริง
ไม่มี trace ให้รู้ว่า tool ไหนรัน ไม่มี eval ให้รู้ว่าผลจริงไหม
✅ ดี · sense ที่ขอบ + harness ขั้นต่ำ 5 ชิ้น
ลูป + tool + verify + trace + eval
STT/TTS/RAG คลิปที่ขอบ ลูปไม่เปลี่ยน; และของขั้นต่ำที่ทำให้ “เดโม” กลายเป็น “harness ที่ไว้ใจได้”
คือ verify จากสภาพแวดล้อม + trace ต่อการเรียก + eval หนึ่งตัวที่ยืนยันผลจริง
ลองเอง — คลิป sense เข้ากับลูป แล้วประกอบ harness ขั้นต่ำ
กิจกรรม · คลิกเลือกชิป แล้วคลิกช่อง
Clip the Senses onto the Loop
คลิป harness parts (TOOL/VERIFY/TRACE/EVAL) และ sense (VOICE-IN/RAG/VOICE-OUT/AVATAR) เข้าช่องที่ใช่ —
ลองคลิป sense ใส่กล่อง LOOP ดู มัน เข้าไม่ได้ เพราะลูปไม่ขึ้นกับ modality
พอ harness ขั้นต่ำครบ จะปลดล็อก สเปก harness ของคุณ
คลิกชิป → คลิกช่อง (sense จะ “เด้ง” ออกจาก LOOP)
โจทย์ capstone ของคุณ
เลือกสถานการณ์จริงสักอัน (เช่น “ผู้ช่วยตอบคำถามคู่มือแล็บ” หรือ “ตัวช่วยร่างรายงานประเมิน”) แล้วเขียน ดีไซน์ สั้น ๆ ตอบ:
(1) งานนี้อยู่ขั้นไหนของบันได — ต้องใช้ LLM จริงไหม? (2) tool อะไรบ้าง + คำอธิบายสั่งให้เลือกถูก? (3) บริบท/กติกาที่ต้องป้อน?
(4) การ์ดกั้นอะไรบนสิ่งที่ย้อนไม่ได้? (5) verify จากช่องทางไหน? (6) eval วัดยังไง? (7) คนอยู่ในลูปตรงไหน?
— ปกป้องดีไซน์นี้ได้ต่อหน้าวิศวกรอาวุโส โดยไม่ต้องมีโค้ดสักบรรทัด
ตัวอย่าง capstone ที่ตอบจนจบ — ใช้เป็นแม่แบบ
ก่อนคุณจะเขียนของตัวเอง นี่คือ 7 คำถามข้างบนที่ตอบจนจบ ให้กับสถานการณ์จริงหนึ่งอันจาก fleet ของเรา — “ผู้ช่วยอ่านงานในแล็บ” (แยก ‘ติดจริง’ ออกจาก ‘แค่ช้า’) จากระบบฟีดแบ็กงานในบทที่ 16 เป็นตัวอย่างที่ดีเพราะมันโชว์ชัดว่า LLM ควรเข้าตรงไหน และ ‘ไม่ควร’ เข้าตรงไหน ลอกโครงนี้ไปปรับกับโจทย์ของคุณได้เลย
สถานการณ์: ระหว่างแล็บ 3 ชั่วโมง อาจารย์อยากรู้ — จากงานที่นักศึกษา “เพิ่งส่งตอนนี้” ที่เช็คพอยต์นี้
ปัญหาเชิงแนวคิดร่วมคืออะไร ใครติดจริง (งานสับสน) กับใครแค่ช้า (งานถูกแต่ตามเวลาไม่ทัน)
และช่วยร่างคอมเมนต์เชิงกระบวนการที่อาจารย์ตรวจก่อนส่ง — โดยมอนิเตอร์/คะแนน/CSV เดิม ยังทำงานเหมือนเดิมทุกอย่าง
| คำถาม capstone | คำตอบสำหรับ “ผู้ช่วยอ่านงานในแล็บ” |
|---|---|
| 1 · งานนี้อยู่ขั้นไหนของบันได — ต้องใช้ LLM จริงไหม? | เกือบทั้งหมดอยู่ ขั้น 0: สถานะการ์ดสี (สาย/ตรงเวลา) · คะแนนรวม · CSV · และแม้แต่ รายการคำถามนิรนาม ล้วนเป็นเลขคณิตของนาฬิกาและการนับ — ไม่แตะ LLM · LLM คุ้ม จุดเดียว: แยก “ติดจริง vs แค่ช้า” โดย อ่านเนื้องานที่ส่ง — สิ่งที่ตัวนับเวลาทำไม่ได้เพราะมันไม่เคยอ่านเนื้องานเลย · เป็น agent แบบ เรียกครั้งเดียวตามสั่ง ไม่ใช่ autonomous ไม่ตั้งเวลา |
| 2 · tool อะไรบ้าง + คำอธิบายสั่งให้เลือกถูก? | อ่านอย่างเดียว 3 ตัว: “เนื้องานทั้งเช็คพอยต์ + ชนิดไฟล์ (ภาพ/pdf/โค้ด) + สถานะที่คำนวณไว้แล้ว”, “โจทย์/เกณฑ์ของเช็คพอยต์นั้น” (คำอธิบายสั่งให้ ยึด ‘สิ่งที่ควรทำ’ จากเกณฑ์จริง ไม่ใช่เกณฑ์ที่แต่งเอง), และ “รายละเอียดงานหนึ่งชิ้น” (ดึงไฟล์เฉพาะตอนอาจารย์คลิกเปิด ไม่ดึงยกแผง) · มี tool ร่างคอมเมนต์ที่ ไม่เขียนเอง — แค่คืนร่างให้อาจารย์ |
| 3 · บริบท/กติกาที่ต้องป้อน? | เล็กและจำกัดราย “เช็คพอยต์เดียว”: งาน ~15–30 ชิ้น + โจทย์ของเช็คพอยต์นั้นเป็นเกณฑ์ + ป้ายสถานะ · ไม่ป้อน: งานชิ้นอื่น สมุดคะแนนทั้งเล่ม ตัวตนของผู้ถามคำถาม (ถอดออกตั้งแต่ต้นทาง) หรือไฟล์เต็มถ้าไม่ได้เปิด · ใช้กรอบ plan→build→test→evaluate เป็น “เลนส์” ให้คอมเมนต์พูดภาษากระบวนการ |
| 4 · การ์ดกั้นอะไรบนสิ่งที่ย้อนไม่ได้? | อ่านเป็นหลักล้วน — เครื่องมือทุกตัว “อ่านอย่างเดียว” · การเปลี่ยนแปลงเดียวที่เกิดคือคอมเมนต์ที่ อาจารย์กดอนุมัติ แล้ว ระบบเดิม เป็นคนเขียน · agent ไม่มีทางให้คะแนน เปลี่ยนสถานะ หรือติดธงเลย และช่องคำถามถูกถอดชื่อโดยโครงสร้าง (de-anonymize ไม่ได้) |
| 5 · verify จากช่องทางไหน? | ทุกข้อสรุปต้อง อ้างเนื้องานจริงที่วางไว้ข้าง ๆ ให้อาจารย์ค้านได้ในแวบเดียว · อนุญาตให้ตอบ “ไม่มีรูปแบบร่วมชัดเจน” แทนการแต่งขึ้น · และถ้าขัดกับตัวนับเวลา (“สายตามนาฬิกาแต่งานดูครบ — อาจส่งมีปัญหา”) ให้ รายงานเป็นสัญญาณ ไม่ใช่ไปแก้สถานะ · มอนิเตอร์ deterministic ยังเป็น “ความจริงตั้งต้น” |
| 6 · eval วัดยังไง? | ชุด fixture ออฟไลน์: ตรึง “ตัวอย่างเนื้องาน → ผลสรุปที่คาดหวัง” รวมเคส “ไม่มีรูปแบบร่วม” ไว้ด้วย เพื่อกันการถดถอยเมื่อเปลี่ยน prompt/โมเดล · สัญญาณคุณภาพสด = อัตราที่อาจารย์ อนุมัติ/แก้/ทิ้งร่างคอมเมนต์ |
| 7 · คนอยู่ในลูปตรงไหน? | อาจารย์เป็นคน กดเรียก (ปุ่ม “อ่านเช็คพอยต์นี้” / “ร่างคอมเมนต์” — ไม่ออโต้ ไม่เด้งเองตอนมีงานส่ง), อ่านทุกข้อที่มีหลักฐานอ้าง, แล้ว แก้+อนุมัติทุกคอมเมนต์ก่อนถึงนักศึกษา · agent “เสนอ” เท่านั้น คนกับระบบเดิมเป็นคน “ตัดสิน” — เน้นกระบวนการ ไม่ใช่จับผิด |
ทำไมตัวอย่างนี้ถึง “ปกป้องได้”
มันไม่ได้ตอบว่า “ใส่ AI ตรงไหนได้บ้าง” แต่ตอบว่า “ตรงไหนที่ query ทำแทนไม่ได้จริง ๆ”
(= แยกติด/ช้าจากเนื้องาน) แล้วล้อมจุดนั้นด้วย verify ที่อ้างหลักฐาน · การ์ดกั้นการเขียน · และคนกดอนุมัติทุกครั้ง —
นี่คือ รูปร่างของคำตอบที่วิศวกรอาวุโสจะเชื่อ และเป็นโครงเดียวกับที่คุณจะตอบให้โจทย์ของตัวเอง
อยากเทียบกับระบบอื่นทั้ง fleet — ว่าแต่ละระบบ LLM คุ้มตรงไหน อ่อน/แข็งมิติไหน — ดูได้ที่ 🗂️ Fleet Gallery (สรุปรวม 5 ระบบเทียบกันทีละมิติ)
สรุปบทที่ 20 — และทั้งคอร์ส
- ลูป agent ไม่ขึ้นกับ modality — sense คลิปที่ขอบ ไม่ใช่ในลูป
- harness ขั้นต่ำที่ไว้ใจได้ = ลูป + tool + verify + trace + eval sense เป็นของเสริม
- ความน่าเชื่อถือเป็นสิ่งที่ ออกแบบ ไม่ใช่ซื้อ — โมเดลตัวเดิม harness ดี = ของที่ไว้ใจได้
- พิสูจน์ขั้น deterministic ก่อนเสมอ — LLM คุ้มเฉพาะการสังเคราะห์ ภาษา และการตัดสินเชิงคุณภาพ
🎓 build-your-harness checklist — ครบสมบูรณ์
18 บรรทัดที่เราสะสมมาตั้งแต่บทที่ 01 คือ สเปก harness ของคุณ — ฉบับเต็มอยู่ด้านล่างนี้
(คลิกหมายเลขเพื่อติ๊กไว้ขณะออกแบบของคุณเอง) · นี่คือสิ่งที่ติดตัวกลับไป — ไม่ใช่โค้ด แต่เป็น วิธีคิดแบบวิศวกร harness
📋 build-your-harness checklist — ฉบับเต็ม 18 บรรทัด
18 บรรทัดสะสมจากบท 01–19 (บท 10 เป็นบทสรุปแกนกลาง จึงไม่เพิ่มบรรทัดใหม่) · ไล่ตอบให้ครบ = สเปก harness ที่ปกป้องได้ · คลิกเลขเพื่อติ๊กว่าทำแล้ว
- 1 · ใบประกาศงาน บท 01 คำถามที่เกิดซ้ำ + ข้อมูลที่เรามีอยู่แล้ว + ต้นทุนของคำตอบผิด
- 2 · แยกงาน script ออกจากงานภาษา บท 02 งานที่ขั้นตอนตายตัวเขียนเป็น script (ไม่ใช้ LLM) แยกจากงานที่ต้องใช้ภาษายืดหยุ่น
- 3 · ลูปที่มี verify จากของจริง บท 03 เชื่อโลกจริง ไม่เชื่อคำว่า “เสร็จแล้ว” ของโมเดล
- 4 · เครื่องมือที่คัดมาแล้ว บท 04 คำอธิบายบอกชัดว่าเมื่อไรควร/ไม่ควรใช้ + error ที่บอกวิธีแก้ตัว
- 5 · บริบทที่ถูกต้อง บท 05 ตัวตน + กติกา/ค่าคงที่ที่เกี่ยวข้อง — เล็กแต่ตรงประเด็น
- 6 · memory: ชั่วคราว vs ต้องคงอยู่ บท 06 ตัดสินทีละข้อ — ของที่ต้องคงอยู่เขียนลง external memory / แหล่งความจริง
- 7 · grounding + gate บท 07 grounding + schema-first + verify จากช่องทางอิสระ + gate การกระทำที่ย้อนไม่ได้
- 8 · permissions + HITL gate บท 08 deny-by-default allow-list + least privilege + คนกดยืนยันบนทุกการกระทำที่ย้อนไม่ได้
- 9 · เพดานลูป + trace บท 09 max turns + timeout + trace ต่อคำขอที่มี trace_id · parent · intent
- 10 · ทำการเข้าถึงให้เป็นมาตรฐาน (MCP) บท 11 เลือกชนิดให้ถูก: tools (โมเดลคุม) · resources (แอปแนบ) · prompts (ผู้ใช้เลือก)
- 11 · แพ็กขั้นตอนซ้ำเป็น Skill บท 12 progressive disclosure + กัน definitions/ผลลัพธ์ออกจาก context
- 12 · context เล็กสุด-สัญญาณแรงสุด บท 13 schema-first · ดึง just-in-time · สรุปก่อน · วางของสำคัญไว้ต้น/ท้าย
- 13 · เนื้อหาภายนอก = ไม่น่าเชื่อถือ บท 14 ตัดขา trifecta อย่างน้อยหนึ่งขาให้เหลือศูนย์ · อย่าเพิ่ม exfil ให้ agent ที่ปรึกษา
- 14 · เลือกขั้นบันไดต่ำสุดที่ทำงานได้ บท 15 ขึ้นเฉพาะเมื่อขั้นล่างพัง · บางงานไม่ต้องใช้ LLM เลย
- 15 · ชุด eval ส่วนตัว บท 16 ~50 เคสจากงานจริง · ให้คะแนน 3 ระดับ · สอบเทียบ LLM-as-judge ก่อนใช้
- 16 · วาง harness เป็นชั้น advisory บน fleet บท 17 cockpit ศูนย์ LLM เป็นคนคัด/อนุมัติ/มองเห็น/กำกับ · เลือก tradeoff ให้เหมาะบริบท
- 17 · เมื่อ act เป็นกายภาพ บท 18 safety envelope จากเซนเซอร์จริง · teleop fallback · verify จากเซนเซอร์ ไม่ใช่ความมั่นใจของ policy
- 18 · จับคู่ autonomy กับความเสี่ยง บท 19 control handoff + สัญญาณให้คนรู้ว่าเมื่อไรควรแทรก · ปรับ trust ให้ไม่เกินไม่ขาด