บทที่ 37: ห้องทดลองค้นความรู้ของเจ้าของธุรกิจ

ผลลัพธ์ของบทนี้

เมื่อจบบทนี้ คุณจะมี “แฟ้มค้นความรู้ฉบับจำลอง” หนึ่งชุด ประกอบด้วย

1. ใบค้นหา
2. บันไดคำค้น
3. ตารางผลค้นและการคัดออก
4. ชุดคำตอบสี่ส่วน
5. ร่างบัตรบทเรียน
6. บันทึกเส้นทางของข้อมูล
7. ใบส่งต่องาน (handoff)
8. บันทึกการตัดสินใจ (decision record) พร้อมวันทบทวน

ห้องทดลองนี้ออกแบบให้ทำได้บนกระดาษหรือไฟล์ Markdown ธรรมดา ผู้เรียนไม่จำเป็นต้องมี Arra ทำงานอยู่ และไม่ต้องให้สิทธิ์เขียนระบบใด

สถานการณ์ใกล้ตัว

ธุรกิจจำลอง “ครัวเมล็ดดี” ขายชุดอาหารแห้ง มีพนักงานใหม่ถามว่า

“ถ้าลูกค้าขอเปลี่ยนวันที่จัดส่งหลังร้านแพ็กสินค้าแล้ว ทีมควรทำอย่างไร”

เจ้าของจำได้ว่าเคยมีกรณีคล้ายกัน แต่ไม่อยากตอบจากความจำ เพราะอาจมีนโยบายใหม่ เขาจึงมอบหมายให้ทีมทำแฟ้มหลักฐาน ไม่ใช่ขอคำตอบเปล่า ๆ

นี่คือชุดเอกสารสังเคราะห์ทั้งหมดในห้องทดลอง:

ไม่มีชื่อบุคคล ลูกค้า เลขออเดอร์ หรือพาธจริง ทุกอย่างถูกสร้างเพื่อฝึกแยกหลักฐาน

ต้นทุนที่ห้องทดลองต้องป้องกัน

ถ้าทีมค้นเพียงคำว่า “เลื่อน” อาจพบ DOC-F และตอบเรื่องชำระเงิน ถ้าเลือกเอกสารใหม่สุด อาจเลือก DOC-B ทั้งที่ยังรออนุมัติ ถ้าเลือกเอกสารที่อนุมัติแล้ว อาจพบว่า DOC-C ไม่ตอบกรณีหลังแพ็ก

ผลลัพธ์ที่รับผิดชอบอาจตอบได้มากกว่า “ทำได้” หรือ “ทำไม่ได้” เช่น

“พบแนวทางร่างสำหรับกรณีหลังแพ็ก แต่ยังไม่มีนโยบายที่อนุมัติครอบคลุมโดยตรง ให้ผู้จัดการประเมินตามเคสและเร่งยืนยันรุ่น 2 ก่อนสัญญาลูกค้า”

คำตอบนี้ไม่สมบูรณ์แบบ แต่มันบอกสถานะจริงและหยุดความมั่นใจเกินหลักฐาน

ภาพเปรียบเทียบ

ห้องทดลองนี้เหมือนโต๊ะซ้อมคัดเอกสารของบรรณารักษ์ เราวางบัตรจำลองไว้หกใบ ลองค้น จัดกลุ่ม และเขียนรายงาน โดยไม่เดินเข้าไปย้ายหนังสือในห้องสมุดจริง

เป้าหมายคือฝึกวิธีคิด ไม่ใช่พิสูจน์ว่าเครื่องมือในเครื่องของผู้เรียนติดตั้งหรือทำงานเหมือนชุดรุ่นที่ผู้เขียนตรวจ

ขอบเขตตามตัวอักษร: โต๊ะซ้อมหมายถึงเอกสารสังเคราะห์หรือพื้นที่ที่ผู้ดูแลแยกไว้ ไม่ใช่การรับรองว่าเรียกเครื่องมือใดก็ปลอดภัย หากไม่ยืนยันโหมดอ่านอย่างเดียวและสิทธิ์ข้อมูล ให้ทำบนกระดาษเท่านั้น

ศัพท์ใหม่ในบทนี้

• ห้องทดลองแบบอ่านอย่างเดียว (read-only lab): แบบฝึกที่ไม่สร้าง แก้ หรือลบข้อมูลในระบบเป้าหมาย
• ผลลวง (false positive): ผลค้นที่ดูเกี่ยวจากคำหรือความหมาย แต่ไม่ตอบขอบเขตจริง
• ผลตกหล่น (false negative): เอกสารที่เกี่ยวข้องแต่ไม่ปรากฏในผลค้น
• แฟ้มหลักฐาน (evidence pack): ชุดคำตอบพร้อมแหล่ง ข้อจำกัด และขั้นต่อไป
• จุดที่ต้องให้คนอนุมัติ (human gate): จุดที่คนมีอำนาจตรวจและตัดสินใจก่อนมีผลจริง

ผลงานประจำบท: แฟ้มค้นความรู้แปดชิ้น

ให้ใช้แฟ้มเดียวแบ่งเป็นแปดแท็บตามลำดับ: ใบค้นหา บันไดคำค้น ตารางผลค้น ชุดคำตอบ ร่างบทเรียน บันทึกเส้นทางของข้อมูล ใบส่งต่องาน และบันทึกการตัดสินใจ ทุกแท็บต้องอ้างกลับไปยังรหัส DOC-A ถึง DOC-F ได้ และต้องไม่เปลี่ยนข้อมูลในระบบจริง

แก่นของเรื่อง

ห้องทดลองแบ่งเป็นเจ็ดรอบ แต่ละรอบเพิ่มผลงาน ไม่เพิ่มสิทธิ์

รอบ 1: เขียนใบค้นหา

กำหนดคำถาม ผู้ใช้ ขอบเขต หลักฐานที่ต้องการ สิ่งที่ห้ามเดา และผู้อนุมัติ

ตัวอย่างสิ่งที่ห้ามเดา: “ห้ามสรุปว่าร่างรุ่น 2 ใช้ได้เพียงเพราะวันที่ใหม่กว่า”

รอบ 2: ทำบันไดคำค้น

• คำตรง: เปลี่ยนวันส่ง, หลังแพ็ก
• ภาษาหลากหลาย: เปลี่ยนกำหนด, นัดส่งใหม่, พักการจัดส่ง
• ความหมาย: เมื่อลูกค้าต้องการรับของช้าลงหลังร้านเตรียมสินค้าแล้ว

คาดการณ์ผลลวงล่วงหน้า: เอกสารเรื่องเลื่อนชำระเงิน

รอบ 3: จำลองผล FTS และ semantic

รอบ FTS ด้วยคำว่า “เปลี่ยนวันส่ง” อาจพบ DOC-A

รอบคำพ้องอาจพบ DOC-B และ DOC-E

รอบความหมายอาจพบ DOC-A, DOC-B, DOC-D และ DOC-E แต่ก็อาจดึง DOC-F เพราะมีแนวคิดเรื่องการเลื่อน

ถ้าระบบ vector ไม่พร้อม ให้บันทึกว่า fallback เป็น FTS-only แล้วเพิ่มคำพ้องทีละคำ ห้ามเขียนรายงานเหมือนผลจากสองโหมดเท่ากัน

รอบ 4: เปิดอ่านและคัดสถานะ

ตรวจวันที่ สถานะ การแทนที่ เจ้าของ และเนื้อหาเต็ม

• DOC-A เก่าและถูกแทนที่ จึงใช้ดูประวัติ ไม่ใช้เป็นคำตอบปัจจุบัน
• DOC-B ตรงกรณีที่สุด แต่ยังรออนุมัติ
• DOC-C อนุมัติแล้ว แต่ไม่ครอบคลุมหลังแพ็ก
• DOC-D และ DOC-E ช่วยกำหนดขั้นปลอดภัย แต่ไม่ใช่นโยบาย
• DOC-F เป็นผลลวง

รอบ 5: สร้างชุดคำตอบสี่ส่วน

เขียนคำตอบสั้น ตารางหลักฐาน ช่องว่าง และขั้นต่อไป ห้ามรวมสถานะต่างกันให้กลายเป็นฉันทามติปลอม

รอบ 6: ร่างบันทึกที่มา บทเรียน และใบส่งต่องาน

Trace บอกเส้นทางว่าค้นอะไรและคัดอะไรออก Learning draft อาจเขียนว่า “ตรวจสถานะแพ็กและผู้อนุมัติก่อนสัญญาเปลี่ยนวัน” โดยอ้าง DOC-D/E แต่ยังไม่เรียก oracle_learn

ใบส่งต่องานบอกว่า DOC-B รออนุมัติ ใครต้องยืนยัน และผู้รับช่วงต้องทำอะไร ไม่ส่งบทสนทนาทั้งหมด

รอบ 7: ทำบันทึกการตัดสินใจ

มนุษย์อาจเลือก “ใช้การอนุมัติรายกรณีชั่วคราว และทบทวนร่างนโยบายภายในวันจำลองหนึ่งสัปดาห์” บันทึกเงื่อนไขหยุดและผู้อนุมัติ โดยไม่เพิ่มกำหนดการจริงในห้องทดลอง

แผนที่พื้นผิว Arra สำหรับห้องทดลอง

หากทำบนกระดาษ คุณไม่ต้องใช้เครื่องมือใดเลย

หากผู้ดูแลจัดสภาพแวดล้อมทดลองที่ตรวจแล้วว่าเป็นโหมดอ่านอย่างเดียว ให้ยืนยันรายการเครื่องมือก่อนเริ่ม และจำกัดอยู่ที่พื้นผิวอ่าน เช่น

• oracle_list
• oracle_concepts
• oracle_search
• oracle_read
• oracle_stats
• oracle_verify เฉพาะเมื่อผู้ดูแลยืนยันและกำหนด check=true อย่างชัดเจน; การทำงานปริยายหรือ check=false ถือเป็นการเขียนและห้ามใช้ในห้องทดลอง
• พื้นผิวอ่าน trace/thread/inbox เฉพาะเมื่อใช้ข้อมูลตัวอย่างที่เตรียมไว้

อย่าเรียก oracle_learn, การสร้างหรืออัปเดตกระทู้สนทนา, oracle_trace, oracle_handoff, การแทนที่เอกสาร หรือการเขียนตารางเวลาในห้องทดลองนี้ และอย่าเรียก oracle_verify หากยืนยัน check=true ไม่ได้ การเห็นเครื่องมือเขียนในรายการยังไม่เท่ากับได้รับอนุญาตให้ใช้

ก่อนเผยแพร่บทเรียนจริง ผู้ดูแลต้องยืนยันรายการเครื่องมือ (ListTools) ของ Arra เวอร์ชันเป้าหมายอีกครั้ง เพราะจำนวนเครื่องมือและเอกสารประกอบในชุดที่ตรวจมีความต่างกัน หนังสือจึงยึดชื่อที่รายการในซอร์สปัจจุบันยืนยัน ไม่ยึดจำนวนรวม

ตัวอย่างจำลองตามกระบวนการ Oracle V4

เส้นทางครบ: มนุษย์ส่งเรื่องให้ Earth AI แล้ว Earth AI ส่งต่อให้ Jan เลือก House เมื่อ House ทำงานเสร็จ รายงานจะกลับผ่าน Jan และ Earth AI จนถึงมนุษย์

เจ้าของธุรกิจบอกผลลัพธ์ว่า “ต้องการแฟ้มหลักฐานและข้อเสนอชั่วคราว ไม่ใช่ให้ AI เปลี่ยนนโยบาย” Earth AI ทำรายละเอียดงานแล้วส่ง Jan Jan เลือก House ตามบทบาทและกำหนดให้ส่งรายงานเป็นไฟล์

House ทำเจ็ดรอบในขอบเขตข้อมูลตัวอย่าง ส่งแฟ้มเป็นไฟล์กลับ Jan โดยมีผลค้น แหล่ง ข้อจำกัด และคำถามค้าง Jan ตรวจการส่งมอบแล้วส่งให้ Earth AI ตรวจว่าไม่มีข้อมูลส่วนตัวและไม่มีการเขียนระบบจริง จากนั้น Earth AI ส่งกลับให้มนุษย์อ่านบันทึกการตัดสินใจและเลือกทางต่อ

เส้นทางนี้แสดงหลักการ V4 โดยไม่อ้างว่าทุก House กำลังทำงานหรือพร้อมใช้จริง และไม่เปิดเผยชื่อหน้าจอย่อย พาธ หรือรายงานจริง

หยุดแล้วมองอีกครั้ง

สังเกตว่าห้องทดลองไม่ได้ให้รางวัลกับคนที่ตอบเร็วที่สุด ผู้เรียนที่ตอบว่า “หลักฐานยังไม่พอ” พร้อมชี้ว่าขาดอะไร อาจทำงานได้ดีกว่าคนที่เลือก DOC-B เพียงเพราะใหม่ที่สุด

การรู้ว่าเมื่อใดควรหยุดเป็นทักษะสำคัญของ AI และช่วยป้องกันความเสียหาย

ลองทำอย่างปลอดภัย

ทำเจ็ดรอบจาก DOC-A ถึง DOC-F และรวมเป็นแฟ้มเดียว ใช้เวลา 45-60 นาที หรือแบ่งเป็นสามช่วงตามสคริปต์คอร์สท้าย Part

ช่วง A: ค้นและคัด

1. เติมใบค้นหา
2. ทำบันไดคำค้น
3. จำลองผล FTS, semantic และ fallback
4. ทำตาราง “ใช้ / ใช้เป็นบริบท / คัดออก”

ช่วง B: ตอบและตามรอย

5. ทำชุดคำตอบสี่ส่วน
6. สร้าง trace draft และ learning draft

ช่วง C: ส่งต่อและตัดสินใจ

7. เขียน handoff
8. เติมบันทึกการตัดสินใจกับวันทบทวน

ก่อนเริ่ม (preflight)

• ยืนยันว่าใช้เฉพาะ DOC-A ถึง DOC-F ในบทนี้
• ปิดการเชื่อมต่อข้อมูลจริง หรือทำบนกระดาษ
• หากใช้สภาพแวดล้อมทดลอง ให้ผู้ดูแลยืนยันโหมดอ่านอย่างเดียวและรายการเครื่องมือก่อน
• ตกลงว่าผลลัพธ์ “ยังไม่พบหลักฐานอนุมัติ” ถือว่าผ่าน

ผลที่คาดหวัง (expected result)

• ได้แฟ้มครบแปดผลงาน
• DOC-F ถูกคัดออกด้วยเหตุผล ไม่ใช่เพียงความรู้สึก
• DOC-B ถูกติดป้ายรออนุมัติ ไม่ถูกใช้เป็นนโยบายปัจจุบัน
• มีบันทึกว่าผลจะต่างอย่างไรเมื่อ vector unavailable
• ไม่มีการเขียนข้อมูลเกิดขึ้น

หยุดและถามคนเมื่อ… (stop condition)

• หยุดทันทีหากเห็นข้อมูลจริง ตำแหน่งไฟล์ส่วนตัว รหัสลับ (token) ข้อมูลลูกค้า หรือข้อมูลสุขภาพ
• หยุดหากระบบขอสิทธิ์สร้างไฟล์ ส่งข้อความ เปลี่ยนสถานะ ทำดัชนี หรือแก้ตารางเวลา
• หยุดหากชื่อเครื่องมือในสภาพแวดล้อมไม่ตรงกับรายการที่ผู้ดูแลอนุมัติ
• หยุดก่อนนำคำตอบจำลองไปใช้กับลูกค้าหรือกระบวนการจริง

วิธีกู้คืน (recovery)

• ปฏิเสธคำขอเขียน ออกจากห้องทดลองจำลอง และเริ่มใหม่บนกระดาษ
• ลบหรือปิดบังข้อมูลจริง แล้วใช้รหัส DOC-A ถึง DOC-F เท่านั้น
• หากระบบค้นหาความหมายไม่พร้อม ไม่ต้องซ่อมระบบในบทเรียน ให้บันทึกข้อจำกัด แล้วใช้การค้นหาจากคำตรงและคำพ้องแทน
• หากหลักฐานขัดกัน ให้คงสถานะ pending และส่งคำถามให้บทบาทมนุษย์ที่กำหนด

เกณฑ์ตรวจแฟ้มของตนเอง

ให้คะแนนผ่าน/ต้องแก้ในแปดข้อ

• คำถามมีขอบเขตและผู้ใช้คำตอบ
• มีคำค้นทั้งคำตรงและความหมาย
• ระบุโหมดค้นหรือ fallback
• เปิดอ่านเนื้อหา ไม่ตัดสินจากชื่อไฟล์
• แยกหลักฐานตรง หลักฐานแวดล้อม และผลลวง
• คำตอบมี “ยังไม่รู้” อย่างตรงไปตรงมา
• ร่างบทเรียน/บันทึกเส้นทางของข้อมูล/ใบส่งต่องาน โดยไม่เรียกเครื่องมือเขียน
• บันทึกการตัดสินใจมีเจ้าของ วันทบทวน และจุดที่ต้องให้คนอนุมัติ

หากไม่ผ่านข้อใด ไม่ต้องเริ่มใหม่ทั้งหมด ให้กลับไปแก้ผลงานที่เกี่ยวข้อง นี่คือเหตุผลที่เราแยกระบบเป็นชิ้นเล็ก ๆ

ระวังความเข้าใจผิด

• ห้องทดลองนี้พิสูจน์วิธีคิด ไม่ได้พิสูจน์ว่าการติดตั้ง Arra ใดพร้อมใช้เป็นระบบจริง (production)
• การใช้โหมดอ่านอย่างเดียว (read-only) ลดความเสี่ยงจากการเขียน แต่ไม่ทำให้ข้อมูลที่อ่านปลอดภัยต่อการเผยแพร่โดยอัตโนมัติ
• oracle_verify จะนับเป็นโหมดอ่านอย่างเดียวในแบบฝึกนี้ต่อเมื่อระบุ check=true ชัดเจนเท่านั้น การทำงานปริยาย/check=false อาจเปลี่ยนดัชนีและต้องหยุด
• การพบ DOC-B ด้วย semantic ไม่ทำให้สถานะรออนุมัติหายไป
• การทำแฟ้มครบไม่ได้รับรองคำตอบ หากเอกสารต้นทางผิด
• การเขียนบันทึกการตัดสินใจจำลองไม่อนุญาตให้เปลี่ยนนโยบายจริง

สามเรื่องที่ควรจำ

1. ระบบค้นที่ดีพาไปหาหลักฐาน พร้อมบอกขอบและสิ่งที่ยังไม่รู้
2. การเขียนความรู้ trace, thread, handoff หรือตารางเวลาเป็นอีกระดับของอำนาจ ต้องมีจุดที่ต้องให้คนอนุมัติ
3. เป้าหมายของ Arra คือทำให้ความรู้และเหตุผลเดินทางต่อได้ โดยไม่ตอบแทนเจ้าของ

คำถามชวนคิด

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

สะพานไป Part ถัดไป

เราเข้าใจแล้วว่าความรู้ถูกค้น อ่าน ตามรอย และส่งต่ออย่างไร ส่วนถัดไปจะพาไปดู “หน้าต่างดูงาน” ตั้งแต่โต๊ะเปิดไฟล์ใน VS Code ผู้ช่วย Claude Code และหน้าต่างคำสั่ง Terminal ไปจนถึงการมอง Jan กับบ้านผู้เชี่ยวชาญที่ทำงานอยู่เบื้องหลังผ่าน tmux โดยไม่รบกวนงาน