สถานการณ์: รู้จักงานก่อนสร้างเครื่องมือ

ตลอดคอร์สนี้เราจะสร้าง “ผู้ช่วยจัดการแล็บ” (Lab Operations Assistant) หนึ่งตัว จาก script ธรรมดา ๆ ให้กลายเป็น agent ที่ เชื่อถือได้พอจะนำไปใช้จริง แต่ก่อนจะเขียนโค้ดสักบรรทัด หรือเรียกโมเดลสักครั้ง บทนี้ทำสิ่งที่วิศวกรที่ดีทำเป็นอย่างแรกเสมอ — นิยาม “งาน” ให้ชัด: คำถามอะไรที่เกิดซ้ำทุกวัน ข้อมูลอะไรที่เรามีอยู่แล้ว และคำตอบผิดหนึ่งครั้งราคาแพงแค่ไหน

พูดแบบเข้าใจง่าย

ลองนึกถึงห้องปฏิบัติการสอนของภาควิชา มีห้องหลายห้อง มีเครื่องมือที่ต้องยืม–คืน–สอบเทียบ และมีตารางเรียนที่ใช้ห้องเหล่านั้นอยู่ทุกวัน เจ้าหน้าที่ต้องตอบคำถามชุดเดิม ๆ ซ้ำไม่จบ: พฤหัสบ่ายมีห้องไหนว่าง? เครื่องมือตัวนี้เลยกำหนดคืนหรือยัง? การจองนี้ชนคาบเรียนไหม?

ทุกวันนี้คำถามเหล่านี้ตอบได้อยู่แล้ว — ด้วยคนที่เปิดระบบจองกับตารางสอนแล้วไล่ดูทีละบรรทัด สังเกตให้ดี: คำตอบเหล่านี้เป็น ข้อเท็จจริงที่อยู่ในข้อมูลที่เรามีอยู่แล้ว ไม่ใช่ความเห็น เป้าหมายของเราจึงไม่ใช่ “ใส่ AI ให้เท่” แต่คือ เครื่องมือที่เรากล้าเอาไปใช้จริง — และก่อนจะไปถึงตรงนั้น ต้องรู้ก่อนว่างานคืออะไรกันแน่

ในระบบของเรา — วันนี้คำตอบมาจากไหน (ยังไม่มี AI)

ลองดูว่าคำถามหนึ่งข้อถูกตอบยังไง ตอนนี้ ก่อนที่เราจะแตะ AItools ใด ๆ — ทุกขั้นเป็นการ “เปิดดูข้อมูลจริง” ล้วน ๆ ไม่มีการเดา:

ของมีค่าที่สุดที่เรามีอยู่แล้วคือ ข้อมูลที่เป็นแหล่งความจริง (source of truth) — ไม่ใช่ตัวโมเดล นี่คือสิ่งที่ผู้ช่วยจะต้องพึ่งพา ไม่ใช่ความจำของมันเอง:

ทำพลาด vs ทำถูก

ดู “ไม่ดี” ก่อน เพื่อให้บทเรียนไปลงที่ “วิธีคิดที่ถูก”:

ลองเอง — แยกแยะว่างานไหน “ต้องใช้ AI” จริง

สรุปบทที่ 01

• ก่อนสร้าง agent ใด ๆ ให้ นิยามงานก่อน: คำถามที่เกิดซ้ำ · ข้อมูลที่มี · ต้นทุนของคำตอบผิด · เกณฑ์ความน่าเชื่อถือ
• ของมีค่าคือ ข้อมูลที่เป็นแหล่งความจริง ที่เรามีอยู่แล้ว — ผู้ช่วยต้องอ้างอิงสิ่งนี้ ไม่ใช่ความจำของตัวเอง
• คำถามจัดการแล็บส่วนใหญ่เป็น การค้น/คำนวณ — AI คุ้มเฉพาะตอนต้องใช้ภาษาหรือการสังเคราะห์
• “ถูก” ต้องนิยามให้วัดได้ ไม่งั้นจะไม่มีทางรู้ว่า agent ที่สร้างมาใช้ได้จริงไหม