วางระบบเปลี่ยนเสียงพูด
ให้เป็น second brain ที่เชื่อถือได้

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

ขอย้ำกฎเดิมไว้ก่อน เพราะทุกอย่างในบทความนี้คือการทำให้กฎข้อนี้เกิดขึ้นเองได้ ห้ามให้สิ่งที่ AI สรุป กลายเป็นความรู้ จนกว่ามันจะชี้กลับไปหาหลักฐานในเสียงจริงได้ ที่เหลือเป็นแค่วิธีวาง Pipeline รอบกฎข้อนี้

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

ช่วงที่ 1เตรียมเสียงให้พร้อมตรวจ

ทำไมตัวหนังสือดิบ ๆ ยังตรวจไม่ได้

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

• ใครพูด (diarization) ถ้าไม่รู้ว่าประโยคนี้ใครพูด พอ AI สรุปว่า "ทีมตัดสินใจ X" เราจะตามกลับไม่ได้ว่าจริง ๆ ใครเป็นคนพูด
• ตัดช่วงยังไง (chunking) จะหั่นตามเวลา ตามคนพูด หรือตามใจความ แต่ละแบบให้ผลต่างกัน ตัดตามใจความช่วยให้แต่ละท่อนเป็นเรื่องเดียวจบ ตรวจง่ายกว่าตัดดิบ ๆ ตามนาที
• คำที่อ้างไม่ชัด (coreference) เวลาคนพูดว่า "ไอ้นั่น" หรือ "โปรเจกต์เมื่อกี้" ต้องระบุก่อนว่าหมายถึงอะไร ไม่งั้นพอตัดเป็นท่อน ความหมายจะหลุด

ทำสามอย่างนี้ยังไง

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

พอทำครบสามอย่าง ตรวจว่าได้ผล ด้วยการสุ่มอ่านสักท่อน ถ้าอ่านจบแล้วเข้าใจได้โดยไม่ต้องเปิดท่อนข้าง ๆ มาช่วย แปลว่าเตรียมมาดีพอจะตรวจต่อได้

ช่วงที่ 2ด่านตรวจในฐานะสัญญา

หัวใจของระบบคือมองด่านตรวจเป็น สัญญา ไม่ใช่ฟังก์ชันลึกลับ สัญญาบอกแค่ว่า ของอะไรเข้า ของอะไรออก ส่วนข้างในทำยังไงเป็นเรื่องของกล่องดำ ข้อดีของการมองแบบนี้คือ จะสลับวิธีทำข้างในเมื่อไหร่ก็ได้ โดยไม่กระทบ Pipeline ทั้งเส้น

สองอย่างที่สัญญานี้รับประกัน

• ผูก claim เข้ากับหลักฐาน ทุก claim ที่ผ่านออกมา ต้องแนบมาด้วยว่าหลักฐานอยู่ช่วงไหนของเสียงจริง อันไหนแนบไม่ได้ ก็ไม่ผ่าน
• ตรวจด้วยการอ่านซ้ำ ไม่ใช่เชื่อคะแนน การยืนยันคือกลับไปอ่านช่วงนั้นในต้นฉบับว่าพูดเรื่องเดียวกันจริง ไม่ใช่ดูเลขความมั่นใจแล้วเชื่อ ตัวเลขสวย ๆ ไม่ได้แปลว่าจริง

ตอนแรกของซีรีส์ทิ้งบทเรียนไว้ว่า "หาไม่เจอ" ไม่เท่ากับ "ของปลอม" (จำ Edward Thorp ได้ไหม) พอวางเป็นระบบ งานก็แบ่งกันชัดระหว่างเครื่องกับคน เครื่องค้นในต้นฉบับให้อัตโนมัติว่า claim นี้พูดอยู่ตรงไหน แล้วดึงข้อความช่วงนั้นขึ้นมาให้ดู ส่วนคนก็อ่านแล้วตัดสินเองว่าใช่เรื่องเดียวกันไหม ถ้าเครื่องหาไม่เจอ ก็แปลว่า ยังไม่มีหลักฐาน (unsupported) ไม่ใช่ของปลอม (fabricated) เพราะคำอาจเพี้ยนตอนถอดเสียง หรือพูดเป็นแนวคิดโดยไม่ได้เอ่ยศัพท์ตรง ๆ เครื่องช่วยให้เร็วขึ้น แต่คนยังเป็นคนตัดสินอยู่ดี

ที่ต้องระวังเป็นพิเศษคือ AI ไม่ได้มั่วแบบสุ่ม แต่เติมของที่ "น่าจะมี" เข้ามา ความเนียนสมเหตุสมผลนี่แหละคือจุดที่พลาด ไม่ใช่ความผิดมั่ว ๆ ที่จับได้ง่าย เพราะงั้นด่านถึงต้องชี้กลับหลักฐานทุกอัน ไม่ใช่แค่อ่านผ่านว่าฟังดูดี

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

ช่วงที่ 3เก็บเข้าคลังอย่างเป็นระบบ

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

หัวโน้ตที่บอกที่มาเสมอ

ทุกโน้ตติดหัวข้อมูล (frontmatter) แบบเดียวกัน อย่างน้อยมีสี่ช่อง Tags Date Source Status ช่องพวกนี้เป็นเรื่องพื้นฐานของการจดโน้ตให้เป็นระเบียบ ไม่ใช่ความลับอะไร ที่สำคัญคือ Source ที่ชี้กลับไปหาเสียงต้นทาง และ Status ที่ทำหน้าที่เป็นตัวบอกระดับความน่าเชื่อ โน้ตที่มาจากเครื่องมือที่ตอบพร้อมอ้างอิงอยู่แล้ว เชื่อได้เลย ส่วนโน้ตที่สังเคราะห์จากเสียงดิบ ตั้งไว้ก่อนว่า "ยังไม่ตรวจ" แล้ว จัดอันดับต่ำกว่า จนกว่าจะผ่านด่าน พอผ่านค่อยเลื่อนเป็น "ตรวจแล้ว" เปิดคลังมาก็เห็นทันทีว่าอันไหนเชื่อได้แค่ไหน ไม่ใช่ปนกันมั่ว

จะเขียนทับ ต่อท้าย หรือสร้างโน้ตใหม่

พอมีของใหม่เข้ามา ต้องตัดสินว่าจะเอาไปไว้ไหน หลักง่าย ๆ คือ ถ้าเป็นเรื่องเดิมที่อัปเดต ก็ต่อท้ายโน้ตเดิม ถ้าเป็นมุมที่ขัดกับของเก่า อย่าเขียนทับ ให้เก็บไว้ทั้งสองด้านแล้วโยงถึงกัน ถ้าเป็นเรื่องใหม่จริง ก็สร้างโน้ตใหม่แล้วลิงก์เข้าโน้ตที่เกี่ยวข้อง

สารบัญที่อัปเดตเองโดยไม่พัง

โน้ตทุกอันไปรวมที่ MOC หรือโน้ตสารบัญกลาง พอมีโน้ตใหม่ก็เพิ่มทางเข้าให้โน้ตนั้นใน MOC ที่ถูกหมวด ไม่ใช่โยนทิ้งไว้ลอย ๆ ทำแบบนี้คลังจะโตขึ้นโดยที่ยังหาของเจอ ไม่ใช่โตแล้วรก

ช่วงที่ 4ต่อ Pipeline ให้เดินเอง

สามช่วงแรกทำมือก็ได้ ช่วงนี้คือการต่อให้มันเดินเองตั้งแต่ต้นจนจบ รูปร่างของ Pipeline เป็นแบบนี้

ตัวเชื่อมปลายทางคือ Obsidian Local REST API ที่ให้เขียนโน้ตเข้า vault ได้จากนอกโปรแกรม ส่วนที่สำคัญที่สุดของช่วงนี้คือหลักที่เรียกว่า HITL (human in the loop) หรือการมีคนคอยกำกับอยู่ในวงจร ไม่ปล่อยให้เครื่องตัดสินเองทั้งหมด พูดง่าย ๆ คือของที่ด่านมั่นใจก็ปล่อยให้ไหลต่อ ส่วนของที่ด่านไม่มั่นใจ ให้ กันไว้แล้วเรียกคนมาดู ไม่ใช่ตัดทิ้งเงียบ ๆ เพราะการตัดทิ้งอัตโนมัติคือการทำของจริงหายโดยไม่มีใครรู้ ส่วนเส้นว่ามั่นใจแค่ไหนถึงไม่ต้องเรียกคน เป็นค่าที่จูนตามความเสี่ยงของงานแต่ละแบบ

บทความนี้เล่าหลักการครบทุกช่วง พอเอาไปประกอบเองได้ ส่วนตัวเครื่องมือที่ทำให้ทำซ้ำได้จริงในสเกลใหญ่ เป็นส่วนที่เรากำลังพัฒนาอยู่

สรุปเอาไปใช้กับงานของคุณ

สิ่งที่ต้องจำ

1. เตรียมเสียงก่อนตรวจ แยกผู้พูด ตัดตามใจความ แทนคำที่อ้างไม่ชัดด้วยชื่อจริง
2. มองด่านเป็นสัญญา claim + หลักฐานเข้า claim ที่ตรวจแล้วออก ข้างในเป็นกล่องดำได้
3. ยืนยันด้วยการอ่านซ้ำ ไม่ใช่เชื่อคะแนนความมั่นใจ
4. เก็บเข้าคลังด้วยหัวโน้ตที่บอกที่มา และตัดสินให้เป็นว่าจะต่อท้าย เก็บคู่ขนาน หรือสร้างใหม่
5. ของที่ไม่มั่นใจ กันไว้ให้คนมาดู อย่าตัดทิ้งเงียบ ๆ

เริ่มยังไงดี

ไม่ต้องต่อ Pipeline ทั้งเส้นตั้งแต่แรก ลองทำช่วงที่ 1 กับ 2 ด้วยมือกับบันทึกเก่าสักอันก่อน พอเห็นว่าการเตรียมเสียง + ด่านตรวจช่วยได้จริง ค่อยขยับไปเก็บเข้าคลังให้เป็นระบบ แล้วจึงต่อให้เดินเองเป็นช่วงสุดท้าย ทำทีละช่วง ระบบจะค่อย ๆ โตโดยที่ยังเชื่อถือได้ทุกขั้น