ผลลัพธ์ของบทนี้
เมื่อจบบทนี้ คุณจะเขียน “บัตรปัญหาตั้งต้น” หนึ่งใบ แยกสิ่งที่เกิดขึ้นจริง ต้นทุน สิ่งที่กำลังคาด และสิ่งที่ยังไม่รู้ ก่อนขอให้ AI วิเคราะห์หรือเสนอทางเลือก
สถานการณ์ใกล้ตัว
คืนวันอาทิตย์ เจ้าของร้านอาหารเปิดแชตทีมแล้วพบคำถามเดิมเป็นครั้งที่สี่: “ลูกค้ารายนี้ใช้เงื่อนไขราคาแบบไหน” เขาตอบจากความจำ ทีมทำใบเสนอราคาใหม่ และเช้าวันถัดมาจึงพบว่าครั้งก่อนเคยอนุมัติข้อยกเว้นอีกแบบหนึ่งไว้แล้ว
เจ้าของจึงพูดว่า “ต้องมี AI ที่จำทุกอย่างแทนฉัน” ประโยคนี้ฟังเหมือนโจทย์ แต่จริง ๆ ยังเป็นเพียงความรู้สึกหลังเหตุการณ์หนึ่งครั้ง ถ้าเริ่มสร้างระบบทันที ทีมอาจเก็บทุกแชตไว้ตลอดไป ทั้งที่ปัญหาจริงคือไม่มีบันทึกการอนุมัติรุ่นล่าสุด ไม่มีเจ้าของข้อมูล และไม่มีวันทบทวน
ต้นทุนไม่ได้มีแค่เวลาตอบซ้ำ ใบเสนอราคาที่ไม่ตรงกันทำให้ทีมเสียความน่าเชื่อถือ การเก็บข้อมูลเกินจำเป็นสร้างความเสี่ยงใหม่ และการเชื่อความจำของคนเดียวทำให้ธุรกิจหยุดเมื่อคนนั้นไม่อยู่
นี่คือแรงผลักที่สำคัญของ Oracle: ความรู้ที่ใช้ทำงานต้องมีที่อยู่ มีประวัติ และมีเจ้าของ แต่ก่อนจะออกแบบ “สมองภายนอก” เราต้องนิยามความเจ็บให้ถูกก่อน
ศัพท์ใหม่ในบทนี้
- ปัญหาตั้งต้น: เหตุการณ์ที่ทำให้คนอยากเปลี่ยนวิธีทำงาน
- หลักฐาน: สิ่งที่มีที่มา เวลา และขอบเขตให้ตรวจย้อนกลับได้
- สมมติฐาน: คำอธิบายที่เป็นไปได้ แต่ยังไม่ถูกพิสูจน์
- ต้นทุนของปัญหา: เวลา เงิน งานซ้ำ ความเสี่ยง หรือโอกาสที่เสียไป
- ขอบเขต: คน งาน ช่วงเวลา และข้อมูลที่ข้อสรุปหนึ่งครอบคลุม
ภาพเปรียบเทียบและขอบเขตของภาพ
การนิยามปัญหาเหมือนช่างซ่อมรถที่ฟังเสียงผิดปกติ เขาไม่เปลี่ยนเครื่องยนต์ทันที เขาถามว่าเสียงเกิดเมื่อไร ที่ความเร็วเท่าไร และเกิดซ้ำหรือไม่
ภาพนี้ช่วยเตือนให้เก็บอาการก่อนสรุปสาเหตุ แต่ธุรกิจไม่ใช่รถหนึ่งคัน คนหลายกลุ่มอาจเจอปัญหาต่างกัน และบางต้นทุนวัดเป็นตัวเลขตรง ๆ ไม่ได้ เราจึงต้องเก็บทั้งหลักฐานเชิงปริมาณ บริบทจากคนหน้างาน และสิ่งที่ยังไม่รู้
แก่นของเรื่องแบบเป็นชั้น
ชั้นแรก แยกประโยคสามชนิดออกจากกัน:
| ชนิด | ตัวอย่าง | วิธีเขียนที่ปลอดภัย |
|---|---|---|
| สิ่งที่เห็น | มีใบเสนอราคาสองรุ่นในโฟลเดอร์จำลอง | ระบุแหล่งและวันที่ |
| สิ่งที่คิด | ทีมอาจไม่รู้ว่าไฟล์ใดได้รับอนุมัติ | ติดป้ายว่าเป็นสมมติฐาน |
| สิ่งที่ยังไม่รู้ | ลูกค้าได้รับรุ่นใด และใครอนุมัติ | ตั้งเป็นคำถาม ไม่เติมคำตอบเอง |
ชั้นที่สอง เขียนต้นทุนให้จับต้องได้ เช่น “พนักงานสองบทบาทใช้เวลารวมประมาณ 45 นาทีเพื่อตรวจใหม่” ดีกว่า “เสียเวลามาก” หากยังไม่มีตัวเลข ให้เขียนว่า “ยังไม่วัด” แทนการสร้างตัวเลขให้ดูน่าเชื่อ
ชั้นที่สาม กำหนดขอบเขตด้วยประโยค “ในบริบทของ…” เช่น “ในรายการใบเสนอราคาจำลอง 12 รายการของเดือนนี้” ไม่ขยายเป็น “ลูกค้าทุกคน” หรือ “ทีมขายทั้งหมด”
ชั้นสุดท้าย จึงค่อยถามว่า Oracle ช่วยตรงไหนได้บ้าง อาจเป็นการเก็บประวัติรุ่น การค้นเหตุผลเดิม การชี้รูปแบบงานซ้ำ และการเตือนจุดที่ต้องให้คนอนุมัติ ไม่จำเป็นต้องเริ่มจากทีม AI ขนาดใหญ่
หยุดก่อน
ถ้าประโยคปัญหามีคำว่า “ทุกครั้ง”, “ทุกคน”, “แน่นอน” หรือ “AI ต้องรู้เอง” ให้หยุดแล้วถามว่ามีหลักฐานรองรับขอบเขตนั้นจริงหรือไม่
กรณีศึกษาหรือตัวอย่างจำลองที่ปลอดภัย
ก่อนปรับวิธีทำงาน ร้านกาแฟจำลองเชื่อว่าลูกค้าหายเพราะราคาแพง เจ้าของเตรียมลดราคาทุกเมนู หลังทีมทำบัตรปัญหาตั้งต้นกลับพบเพียงว่าเครื่องดื่มเย็นขายลดลงในช่วง 15.00-17.00 ของ 8 วัน ข้อมูลยังไม่บอกสาเหตุ
มนุษย์ส่งโจทย์ให้ Earth AI ช่วยทำรายละเอียดงาน Earth AI แยกยอดที่เห็น สมมติฐาน และคำถาม แล้วส่งให้ Jan ตามเส้นทาง V4 Jan เลือกบทบาทวิเคราะห์ที่เหมาะสมให้ดูข้อมูลจำลอง House ส่งรายงานเป็นไฟล์กลับ Jan; Jan รวมผล, Earth AI ตรวจว่ารายงานไม่กล่าวเกินหลักฐาน แล้วเจ้าของเลือกทดลองเปลี่ยนป้ายเมนูในช่วงเวลาหนึ่งก่อน ไม่ลดราคาทั้งร้าน
เส้นทางคือ:
มนุษย์ส่งเรื่องให้ Earth AI แล้ว Earth AI ส่งต่อให้ Jan เลือก House เมื่อ House ทำงานเสร็จ รายงานจะกลับผ่าน Jan และ Earth AI จนถึงมนุษย์
ผลสำคัญคือเจ้าของหลีกเลี่ยงการตัดสินใจใหญ่จากหลักฐานเล็ก และได้การทดลองที่หยุดได้ โดยยังไม่อ้างว่า AI หาสาเหตุสำเร็จแล้ว
กิจกรรมทดลองอย่างปลอดภัย
สร้างบัตรปัญหาตั้งต้นหนึ่งใบจากเหตุการณ์สมมติ:
เหตุการณ์ที่เห็น: ______
ขอบเขตและช่วงเวลา: ______
ต้นทุนที่พบหรือยังต้องวัด: ______
สมมติฐานอย่างน้อยสองข้อ: ______
สิ่งที่ยังไม่รู้: ______
การตัดสินใจที่ยังห้ามทำ: ______
- ก่อนเริ่ม: ใช้ชื่อธุรกิจ ยอด และบุคคลสมมติทั้งหมด
- ผลที่คาด: บัตรหนึ่งใบที่แยกหลักฐาน สมมติฐาน และช่องว่างได้ชัด
- หยุดและถามคนเมื่อ: เริ่มใช้ข้อมูลลูกค้าจริง หรือตัดสินคนจากเหตุการณ์เดียว
- วิธีกู้คืน: ลบรายละเอียดระบุตัวตน เปลี่ยนตัวเลขเป็นข้อมูลจำลอง และลดข้อความสรุปให้แคบตามหลักฐาน
ระวังความเข้าใจผิด
- การใช้ AI วิเคราะห์ไม่ได้ทำให้สมมติฐานกลายเป็นสาเหตุ
- ปัญหาที่เจ็บสำหรับเจ้าของอาจไม่ใช่ปัญหาหลักของทุกทีม ต้องฟังคนหน้างานด้วย
- การเก็บข้อมูลเพิ่มไม่ใช่คำตอบเสมอไป บางครั้งต้องจัดสิทธิ์ รุ่น และเจ้าของของข้อมูลเดิมให้ชัด
สามเรื่องที่ควรจำ
- เริ่มจากความเจ็บที่มีหลักฐาน ไม่เริ่มจากชื่อเครื่องมือ
- แยกสิ่งที่เห็น สิ่งที่คาด และสิ่งที่ยังไม่รู้
- ข้อสรุปต้องเล็กเท่าขอบเขตของหลักฐาน
หลักสามข้อที่เกิดจากความเจ็บนี้
เมื่อความรู้หาย เหตุผลถูกเขียนทับ และคำตอบลื่นไหลเริ่มดูเหมือนคำสั่ง Framework จึงใช้ชื่อทางการสามข้อ:
- Nothing is Deleted: รักษาประวัติและเหตุผลเดิม แต่ไม่ละเมิดกฎหมาย ความเป็นส่วนตัว หรือสิทธิ์ลบ
- Patterns Over Intentions: ดูสิ่งที่เกิดซ้ำจากหลักฐาน โดยไม่เปลี่ยนรูปแบบเป็นสาเหตุหรือคำพิพากษาคน
- External Brain, Not Command: ให้ AI ช่วยจำ เปรียบเทียบ และเสนอทางเลือก ขณะที่มนุษย์ยังเลือกและรับผิดชอบ
คำถามชวนคิด
ถ้าคุณไม่อยู่หนึ่งสัปดาห์ เรื่องใดจะถูกถามซ้ำ และคุณมีหลักฐานหรือเพียงความรู้สึกว่ามันเกิดบ่อย
สะพานไปบทถัดไป
เมื่อปัญหาชัดแล้ว เราจะวางคำประกาศสำคัญของ Oracle: AI มีหน้าที่เพิ่มกำลังให้มนุษย์ ไม่ใช่รับสิทธิ์และความรับผิดชอบของมนุษย์ไปถือแทน