อ่านข้อมูลย่อยได้ถูกต้องยังไม่พอสำหรับ agent ที่ต้องทำธุรกรรมต่อ งานเคลมประกันเป็นตัวอย่างที่ต้องเชื่อมข้อมูล ระบบ และการตรวจหลายขั้น ก่อนถือว่างานจบแล้ว
Vasant Kearney จาก Onlay ทางช่อง AI Engineer อธิบายแนวทางใช้ X12 เป็นส่วนหนึ่งของ harness รอบ AI Agent ในงานเคลมประกัน คลิปนี้เล่าการออกแบบ workflow ทางธุรการของทีมเขา โดยชวนกำหนดว่าเรื่องใดให้ agent ตีความได้ และเรื่องใดต้องตรวจด้วยกติกาที่ชัดเจน
VibeSolo ชวนทีมที่ทำงานกับเอกสารหรือระบบหลายตัวนำแนวคิดนี้ไปพิจารณาเรื่องโครงสร้างข้อมูล สิทธิ์ และหลักฐานก่อนส่งต่องาน ตัวอย่างธุรกิจไทยในบทความเป็นการประยุกต์ทางวิศวกรรมของ VibeSolo
เริ่มจากเป้าหมายธุรกิจ ไม่ใช่เริ่มจากความสามารถของ model
Vasant ระบุเป้าหมายของงานที่เขาพูดถึงไว้สองเรื่อง คือ ลดต้นทุนการติดต่อกับประกัน และทำให้ประสบการณ์ของผู้รับบริการดีขึ้น เขาเสนอให้ยึดเป้าหมายเหล่านี้เมื่อเลือกเทคโนโลยี ไม่ได้รายงานผลทดลองว่าต้นทุนหรือผลลัพธ์ผู้ป่วยดีขึ้นเท่าใด
คำถามเพิ่มเติมที่ VibeSolo เสนอคือ งานที่ให้ AI ทำลดเวลาคน งานซ้ำ หรือภาระตรวจได้จริงหรือไม่ ควรกำหนดผลลัพธ์ที่จะวัดก่อนเพิ่มความซับซ้อนของ agent
ตัวอย่างประยุกต์ของ VibeSolo คือระบบช่วยสรุปใบเสนอราคา ติดตามสถานะคำสั่งซื้อ หรือจัดหมวดหมู่เคสลูกค้า สิ่งที่อาจวัดได้รวมถึงเวลาที่งานจบ จำนวนเคสที่ต้องส่งต่อ และงานแก้เมื่อข้อมูลไม่ครบ
แยกให้ออกระหว่าง AI ทำงานย่อยได้ กับ AI ปิดงานได้จริง
Vasant ใช้การอ่านตัวเลขบนเช็คเป็นตัวอย่าง: แม้ทำงานย่อยนี้ได้ ก็ยังไม่ได้แปลว่าระบบพร้อมฝากเช็คและส่งเงินเข้าบัญชีที่ถูกต้อง
เขาอธิบายว่ายังต้องอ่านข้อมูลส่วนอื่น เชื่อมกับโครงสร้างของระบบ และตรวจบัญชีปลายทาง แล้วเทียบกับงานเคลมที่มีหลายขั้น ตั้งแต่ตรวจสิทธิ์ไปจนถึงเงินเข้าบัญชีผู้ให้บริการ
ตัวอย่างประยุกต์ของ VibeSolo คือ แยกการอ่าน PDF สรุปอีเมล หรือค้นข้อมูล ออกจากสิทธิ์อนุมัติคืนเงิน ส่งใบแจ้งหนี้ และแก้ข้อมูลลูกค้า การผ่านเดโมอ่านเอกสารยังไม่ตอบว่าขั้นทำรายการมีการตรวจเพียงพอหรือไม่
ประเด็นของผู้พูดคือ ดู workflow ตลอดเส้นทาง เพราะข้อผิดพลาดในขั้นหนึ่งอาจส่งต่อไปยังขั้นอื่น เขายกตัวอย่างงานที่มีราว 50 ขั้นเพื่ออธิบายปัญหา ไม่ใช่จำนวนขั้นมาตรฐานของทุกงานเคลม
รักษา context ต้นทางไว้ เมื่อข้อมูลมีหลายรูปแบบ
Vasant ยกตัวอย่างภาพที่ถูกย่อให้เหลือรายการข้อค้นพบ แล้วนำไปใช้กับข้อมูลหรือโมเดลปลายทาง การย่อเช่นนี้อาจทำให้บริบทที่ขั้นถัดไปต้องใช้หายไป เขายังยกงาน desktop ที่ต้องเข้าใจองค์ประกอบภาพเป็นอีกกรณีหนึ่ง
มุมที่นำมาใช้กับการออกแบบระบบคือ พิจารณาว่าสรุปข้อความเพียงอย่างเดียวพอกับงานปลายทางหรือไม่ ตัวอย่างในคลิปอธิบายปัญหาการสูญเสียบริบท ไม่ได้ทดสอบความแม่นยำในการวินิจฉัยหรือยืนยันประสิทธิผลของโมเดลทางการแพทย์
ตัวอย่างสมมติที่ VibeSolo เสนอคือเคสที่มีใบเสร็จลายมือ ภาพสินค้าที่เสียหาย แชตลูกค้า และหลักฐานการโอน หากใช้เพียงสรุปสั้นๆ ทีมอาจขาดรายละเอียดที่ต้องเปิดตรวจเมื่อตัดสินใจต่อ
ข้อเสนอของ VibeSolo คือให้ผลสรุปเชื่อมกลับไปยังเอกสาร ภาพ หรือข้อความต้นทาง พร้อมกำหนดว่าเคสใดต้องให้คนตรวจหลักฐาน
เข้าใจว่า Agentic Execution Layer คือจุดที่ความเสี่ยงเริ่มจริง
ตามนิยามในคลิป agentic execution layer คือชั้นที่โมเดลลงมือทำ เช่น ค้นฐานข้อมูล อ่าน schema ดู code ทำธุรกรรมประกัน โทรศัพท์ เปิด portal หรือเชื่อมระบบ EHR ผู้พูดย้ำว่าบาง action มีผลในการเขียนข้อมูล
VibeSolo เสนอให้ดูสิทธิ์อ่านกับสิทธิ์เปลี่ยนข้อมูลแยกกัน เพราะ action อย่างส่งอีเมล คืนเงิน หรือแก้ข้อมูลลูกค้ามีผลหลังออกจากหน้าสนทนา ตัวอย่างเหล่านี้เป็นการต่อยอดจากแนวคิดเรื่อง write implications ในคลิป
ตัวอย่างการแบ่งสิทธิ์ตามงานที่ VibeSolo เสนอให้พิจารณาคือ:
- อ่านและเตรียมข้อมูล: ค้นหา สรุป และจัดหมวดหมู่
- เสนอการกระทำ: สร้างร่างอีเมลหรือรายการให้ตรวจ
- ทำเมื่อผ่านเกณฑ์: เรียก action ที่ระบบตรวจสิทธิ์และเงื่อนไขแล้ว
- ส่งต่อข้อยกเว้น: หยุดให้คนพิจารณาเมื่อหลักฐานไม่ครบหรือขัดกัน
การแบ่งนี้เป็นข้อเสนอสำหรับออกแบบ workflow ไม่ได้รับรองว่าระดับใดปลอดภัยโดยอัตโนมัติ ทีมยังต้องทดสอบ action และผลปลายทางของงานที่เลือก
สร้าง harness รอบ Agent แทนการปล่อยให้คิดและทำอย่างอิสระ
Vasant ใช้คำว่า harness ในความหมายกว้าง คือองค์ประกอบรอบการใช้เหตุผลของ agent ทั้ง memory, tools, checks, permissions, handoffs และ evals รวมถึง X12 ในบริบทงานเคลมที่เขาอธิบาย
ในแนวทางของผู้พูด X12 ให้ โครงสร้างและข้อตกลงของข้อมูลที่สื่อสารกับบริษัทประกัน เขามองว่าฟิลด์และค่าที่มีขอบเขตช่วยจำกัดสิ่งที่โมเดลต้องคาดเดา จึงใช้รูปแบบธุรกรรมที่มีอยู่เป็นฐาน แทนการให้ agent สร้าง schema ใหม่ตามใจ
ตัวอย่างประยุกต์ของ VibeSolo คือแบบฟอร์มภายใน รหัสสินค้า นโยบายคืนเงิน หรือสถานะงานที่องค์กรกำหนดไว้แล้ว สิ่งเหล่านี้อาจเป็นฐานของ schema และกติกาตรวจสำหรับงานของทีม โดยไม่จำเป็นต้องนำ X12 มาใช้กับทุกธุรกิจ
ข้อเสนอของ VibeSolo คือเริ่มจากข้อมูลบังคับ สถานะงาน และเงื่อนไขตัดสินใจที่ใช้อยู่ แล้วทดสอบว่า harness ปฏิเสธรายการที่ไม่ผ่านเงื่อนไขได้อย่างไร โครงสร้างข้อมูลเพียงอย่างเดียวยังไม่ได้รับรองว่าข้อมูลข้างในเป็นจริง
วางสมดุลระหว่างการให้ AI คิด กับการกำหนดกฎตายตัว
Vasant อธิบายข้อแลกเปลี่ยนว่า การใช้ agent reasoning หลายขั้นอาจเพิ่มเวลา ต้นทุน และโอกาสให้ความผิดพลาดส่งต่อ ขณะที่ hardcode ทุกอย่างก็อาจทำให้ code ดูแลยาก เขาจึงเสนอให้หาสมดุลระหว่างสองส่วนนี้ในระบบของทีม
ตัวอย่างการแบ่งหน้าที่ที่ VibeSolo เสนอให้ลองออกแบบคือ:
- ให้ กฎและ validation ตรวจข้อมูลบังคับ รูปแบบ และเงื่อนไขที่กำหนดชัดเจน
- ให้ AI ช่วยสรุปหรือตีความข้อมูลที่ต้องนำไปพิจารณาต่อ
- ให้ คน ตรวจข้อยกเว้นหรือหลักฐานขัดกันก่อน action ที่มีผลสำคัญ
ทีมควรทดสอบว่าส่วนที่เลือกใช้กฎ ส่วนที่เลือกใช้ AI และจุดส่งต่อทำงานร่วมกันได้ตามเกณฑ์ของ workflow นั้น แทนการสมมติว่าการเพิ่มกฎหรือเปลี่ยนโมเดลจะทำให้ผลลัพธ์ดีขึ้นเอง
ใช้ memory เพื่อช่วยงาน แต่ต้องเปิดทางให้แก้ความเคยชินของระบบ
Vasant เล่าว่าทีมใช้ memory ในระดับ partner องค์กร และผู้ใช้ เพื่อช่วยตีความงานที่เกิดซ้ำ เช่น ผู้ใช้ที่ตรวจสิทธิ์ประกันเป็นประจำ เขามองว่า memory ช่วยบอกบริบทที่คำสั่งสั้นๆ อาจหมายถึง
แต่เขาเตือนว่า memory ข้ามวันและข้ามบทสนทนาอาจสร้างอคติ หากระบบคิดว่าผู้ใช้ต้องการทำแบบเดิม ทั้งที่วันนี้ต้องการงานอื่น จึงต้องเปิดทางให้ผู้ใช้หลุดจากสมมติฐานนั้นได้
ในระบบที่ผู้พูดอธิบาย ทีมเก็บ memory ในฐานข้อมูลเพื่อแยกส่วนทางตรรกะ แทนการเขียนลง desktop แบบที่เขายกเป็นตัวอย่างของเครื่องมือ coding การออกแบบนี้เป็นแนวทางของทีมเขา ไม่ใช่ข้อรับรอง compliance หรือข้อกำหนดทางกฎหมายทั่วไป
ข้อเสนอประยุกต์ของ VibeSolo คือให้คนเห็นเมื่อคำแนะนำอิง memory และเลือกแก้สมมติฐานหรือเปลี่ยนแนวทางได้ โดยกำหนดสิทธิ์และขอบเขตการเก็บให้เหมาะกับข้อมูลของทีม
อย่าเชื่อข้อมูลจากระบบเดียว แม้มันจะตอบตรงกันหลายช่องทาง
Vasant ย้ำว่า ข้อมูลที่อยู่ในรูปแบบ X12 ก็อาจผิดได้ ระบบโทรศัพท์ portal และชั้นธุรกรรมของบริษัทประกันอาจดูแลโดยคนละทีมหรือผู้รับจ้าง และหลายช่องทางก็อาจเห็นตรงกันบนข้อมูลที่ผิด
เขายกสถานการณ์ที่ช่องทางต่างๆ บอกว่าผู้รับบริการมีสิทธิ์ แต่ภายหลังเคลมถูกปฏิเสธเพราะไม่ครอบคลุมในช่วงนั้น เพื่ออธิบายว่าข้อมูลที่ได้รับอาจถูกหักล้างได้ ไม่ใช่การยืนยันสิทธิ์หรือขั้นตอนรักษาสำหรับผู้ป่วยรายใด
แนวทางที่เขาอธิบายคือแปลงธุรกรรมจากหลายช่องทางให้อยู่ในโครงสร้างภายในที่ทีมใช้ร่วมกัน โดยยังยอมรับว่าเป็นข้อมูลที่อาจเปลี่ยนได้เมื่อมีหลักฐานปลายทางตามมา การมีรูปแบบเดียวช่วยจัดการข้อมูล แต่ไม่เปลี่ยนมันให้เป็น ground truth
ข้อเสนอเพิ่มเติมของ VibeSolo คือบันทึกแหล่งที่มาและเวลารับข้อมูล รวมถึงสถานะรอตรวจเมื่อหลักฐานไม่ครบ เช่น “ได้สถานะจาก portal รอบล่าสุด” เพื่อให้ทีมตรวจได้ว่ากำลังตัดสินใจบนข้อมูลใด
ทดสอบ model ใหม่เหมือนเปลี่ยนชิ้นส่วนสำคัญของระบบ
Vasant เตือนว่า model ใหม่ที่ได้คะแนน eval บางชุดดีกว่า ไม่ได้แปลว่าจะเหมาะกับทุกสถานการณ์ในระบบเดิม เพราะพฤติกรรมของโมเดลเปลี่ยนได้ จึงต้องจัดการ evals การทดสอบ และ validation เมื่อเปลี่ยนโมเดล
ตัวอย่างสิ่งที่ VibeSolo เสนอให้ตรวจเพิ่มคือรูปแบบคำตอบ การเรียก tool และการจัดการเคสที่ข้อมูลไม่ครบหรือขัดกัน โดยดูผลหลังเชื่อมกับ workflow จริง
ทีมอาจใช้เคสย้อนหลังที่เหมาะกับสิทธิ์และข้อมูลของตน วัดความถูกต้อง ต้นทุนต่อเคส เวลา และการส่งต่อข้อยกเว้นตามเกณฑ์ที่กำหนด ข้อเสนอนี้ต่อยอดจากคำเตือนเรื่องทดสอบโมเดลและต้นทุนของงานซ้ำ ไม่ใช่หลักฐานผลลัพธ์ทางคลินิก
ที่มา: Healthcare’s Agent Bytecode: X12 as the Harness for AI Agents — Vasant Kearney, Onlay โดย Vasant Kearney จาก Onlay ทางช่อง AI Engineer อัปโหลด 19 สิงหาคม 2026 ตามเวลาไทย เนื้อหาและประสบการณ์ของทีมเป็นสิ่งที่ผู้พูดรายงานในเวลานั้น ตัวอย่างประยุกต์และข้อเสนอเพิ่มเติมที่ระบุชื่อ VibeSolo เป็นมุมมองของกองบรรณาธิการ
