Claim Decomposition ของ AI Agent: แยกคำตอบอย่างไรไม่ให้สร้างข้ออ้างใหม่

คำตอบโดยตรง: Claim Decomposition คือการแยกคำตอบยาวเป็นข้อกล่าวอ้างย่อยเพื่อให้ตรวจทีละข้อ แต่ต้องตรวจการแยกก่อนตรวจความจริง: แต่ละข้อยังตรงกับข้อความเดิมหรือไม่ เก็บเนื้อหาครบหรือไม่ และรักษาบุคคล รุ่น เงื่อนไขกับขอบเขตหรือไม่ จากนั้นจึงตรวจข้อย่อยกับแหล่งอ้างอิงแยกอีกชั้น ข้อที่มีหลักฐานรองรับภายนอกอาจเป็นข้อใหม่ที่คำตอบเดิมไม่เคยกล่าว ข้อที่แยกตรงต้นฉบับก็อาจยังไม่มีหลักฐานหรือขัดกับแหล่งข้อมูลได้

บทความมี Conceptual Architecture / HYPOTHESIS สำหรับผู้สร้าง Agent พร้อม Interactive และเกม SIMULATION สำรวจความต่างของการแยกกับการตรวจหลักฐาน ตัวจำลองใช้รายการข้อกล่าวอ้างที่ผู้เขียนกำหนด ไม่เรียก LLM, parser หรือ NLI และไม่สร้างผล benchmark ของ AI

ทำไมตัวตรวจความจริงต้องตรวจตัวแยกข้อความด้วย

สมมติคำตอบบอกว่า “Atlas Lab รุ่น2.1 อ่าน PDF ออฟไลน์ได้เฉพาะบนเดสก์ท็อป” ถ้าตัวแยกสร้างข้อย่อยว่า “อ่าน PDF ออฟไลน์ได้บนทุกอุปกรณ์” มันไม่ได้เพียงทำประโยคให้สั้นลง แต่เพิ่มขอบเขตที่คำตอบไม่ได้รับรอง ตัวตรวจปลายทางจึงกำลังตรวจข้อความอีกเรื่องหนึ่ง

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

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

บทความนี้เจาะคุณภาพตัวแยก ต่างจาก Retrieval Evaluation ที่ตรวจผลค้น/บริบท/คำตอบ และ Evidence Sufficiency ที่ตรวจว่าข้อเชื่อมพอสำหรับคำถามหรือไม่

Scientific Foundations: Atomic Claim เป็นหน่วยตรวจ ไม่ใช่ใบรับรองความจริง

FACT: งาน FActScore แยกข้อความเป็น atomic facts แล้วประเมินสัดส่วนที่แหล่งความรู้ที่กำหนดรองรับ โดยสูตรหลักคิดสัดส่วนต่อคำตอบและเฉลี่ยเหนือคำตอบที่ตอบจริง งานนี้ศึกษาชีวประวัติภาษาอังกฤษกับ Wikipedia จึงเป็นการตรวจ precision ตามแหล่งและเงื่อนไขของงาน ไม่ใช่ความครบหรือความจริงทั่วโลก FActScore, EMNLP 2023

งาน A Closer Look at Claim Decomposition แยกคุณภาพตัวแยกเป็น coverage, coherence และ atomicity และเสนอ DecompScore ที่ใช้ข้อความต้นฉบับเป็นแหล่งตรวจ สูตรดั้งเดิมเป็นจำนวนข้อย่อยที่ต้นฉบับรองรับโดยเฉลี่ยต่อ passage ไม่ใช่เปอร์เซ็นต์ความจริงจากเอกสารภายนอก การแยกผิดสามารถเปลี่ยนผลประเมินข้อความเดิมได้ DecompScore, *SEM 2024

Coverage ถามว่าเก็บสาระเดิมครบเพียงใด Coherence ถามว่าข้อที่แยกยังสอดคล้องกับสิ่งที่ต้นฉบับกล่าวหรือไม่ Atomicity ถามว่าแยกย่อยพอให้ระบุตำแหน่งปัญหาได้หรือยัง ทั้งสามไม่ได้แทนกัน รายการที่ตรงต้นฉบับแต่ขาดหลายข้อยัง coverage ต่ำ ส่วนประโยคที่รวมหลายข้ออาจตรงแต่ระบุข้อผิดพลาดรายส่วนได้ยาก

Atomic ต้องผูกกับเกณฑ์งาน “ออฟไลน์เฉพาะเดสก์ท็อป” ต้องรักษาเงื่อนไขกับความสามารถ การแยกคำเงื่อนไขลอย ๆ ไม่ได้ทำให้ตรวจดีขึ้น

ตรวจสองทิศ: คำตอบเดิมกับหลักฐานภายนอก

ชั้นแรกตรวจ Original Answer → Subclaim ถามว่าคำตอบเดิมกล่าวข้อย่อยนี้ด้วย entity รุ่น และเงื่อนไขใด การผ่านชั้นนี้หมายถึงแยกตรงในขอบเขตที่ตรวจ ไม่ได้หมายถึงเนื้อหานั้นจริง

ชั้นสองตรวจ Reference Source → Subclaim ถามว่าแหล่งที่กำหนดรองรับ ขัดแย้ง หรือยังไม่มีข้อมูลสำหรับข้อย่อยนั้น ต้องเก็บ reference IDs และช่วงข้อความที่ใช้ต่างจาก source spans ของคำตอบเดิม เพราะเป็นคนละต้นทาง

ตัวอย่างสมมติ C8 บอกว่า Atlas Lab รุ่น2.1 เปิด DOCX เมื่อออนไลน์ มี R5 รองรับ แต่ต้นฉบับไม่เคยกล่าวคุณสมบัตินี้ C8 จึงผ่านเรื่องหลักฐานภายนอกและไม่ผ่านเรื่องการแยก การเพิ่มข้อที่เอกสารรองรับก็ยังเป็นเนื้อหาใหม่

ในทางกลับกัน ข้อ “Nova Lab รุ่น1.4 แปลภาษาละตินได้” อยู่ในคำตอบเดิม แต่เอกสารสมมติไม่มีข้อมูลยืนยัน ควรเก็บข้อย่อยนี้พร้อมสถานะ NOT_IN_REFERENCE ไม่ลบให้คะแนนดูดี ส่วน “เก็บประวัติ30วัน” อยู่ในต้นฉบับแต่ขัดกับ R3 จึงต้องเก็บพร้อม CONTRADICTED การแก้ข้อความให้ตรงเอกสารเป็นขั้นแก้คำตอบอีกงานหนึ่ง

ตัวอย่าง Atlas Lab / Nova Lab: เก็บอะไรไว้บ้าง

ผลิตภัณฑ์ทั้งหมดต่อไปนี้เป็น SIMULATION คำตอบต้นฉบับมีห้าหน่วย U1–U5 และชุดเอกสาร R1–R5 ที่ผู้เขียนกำหนด ไม่ใช่ข้อเท็จจริงของซอฟต์แวร์ที่จำหน่ายจริง

source span คือช่วงของข้อความเดิมที่ข้อย่อยอ้างว่าแยกออกมา ให้เก็บข้อความช่วงนั้นพร้อม start/end และหน่วยตำแหน่ง ใน Lab ใช้ UTF-16 code units และ end แบบไม่รวมตำแหน่งสุดท้าย การมีตำแหน่งถูกยืนยันแค่การอ้างช่วง ไม่พิสูจน์ว่าการตีความช่วงนั้นถูก

Record ควรมี claim ID, original version, entity, predicate, qualifiers, spans และผลสองชั้น ห้ามผสม Atlas2.1กับNova1.4 การแก้สรรพนามต้องอิงต้นฉบับและคงความกำกวมเมื่อแก้ไม่ได้

Interactive: คะแนนสูงขึ้นเพราะเนื้อหาถูกทำหายหรือไม่

เริ่มจากข้อย่อย C1–C5 ที่รักษาห้าหน่วยเดิม ลองเปลี่ยนเป็นโหมดเลือกเฉพาะข้อที่เอกสารรองรับ C1–C3 แล้วดู Original Coverage แม้สัดส่วนที่เอกสารยืนยันจะเป็น3/3 แต่เนื้อหาคงเหลือเพียง3/5ของคำตอบเดิม ผลนี้ไม่ใช่การตรวจครบ

ลองโหมดเพิ่มข้อใหม่ C8 แล้วดูว่ามีหลักฐาน R5 แต่ไม่มี source span ในคำตอบเดิม หรือเลือก C7 ที่เปลี่ยน “เฉพาะเดสก์ท็อป” เป็น “ทุกอุปกรณ์” ส่วน C9/C10 แสดงการสลับผลิตภัณฑ์และเปลี่ยนรุ่น

โหมดสำเนาเพิ่ม C6 ซึ่งสื่อเรื่องเดียวกับ C1 อัตราบนรายการดิบจะเปลี่ยนได้ แต่จำนวนข้อไม่ซ้ำและ coverage ไม่เพิ่ม ส่วน C11 รวม U1 กับ U3: รักษาเนื้อหาได้แต่ยังเป็น compound ที่ไม่ผ่านเกณฑ์ atomicity ของตัวอย่าง กด Reset เพื่อกลับสู่ชุดเริ่มต้น

ผลประเมินความสัมพันธ์ทั้งหมดเป็น labels ที่กำหนดใน fixture ไม่ได้เกิดจาก parser หรือ semantic entailment model การเปรียบ C1/C6 ใช้ fingerprint ที่ผู้เขียนให้ ไม่ใช่ระบบรู้ว่าข้อความภาษาไทยทุกคู่มีความหมายเท่ากัน ความจริงภายนอกผลิตภัณฑ์สมมติยัง UNKNOWN

นิยามตัวหารให้เห็นทั้งการรักษาและการตกหล่น

ให้ A เป็นชุดหน่วยเดิมห้าข้อ D เป็นรายการข้อที่เลือก D* เป็นข้อไม่ซ้ำตาม fingerprint และ P เป็นข้อใน D* ที่ labels สมมติบอกว่าตรงกับต้นฉบับ ตัวอย่างนิยามดังนี้

Toy Preservation = จำนวนข้อใน P / จำนวนข้อใน D*
Toy Original Coverage = จำนวน U ที่ข้อใน P รักษาไว้ / 5
Toy Confirmed Support = จำนวนข้อ SUPPORTED ใน D* / จำนวนข้อใน D*
Toy Raw Support = จำนวนรายการ SUPPORTED ใน D / จำนวนรายการใน D

การนับ coverage ใช้ union ของ U ที่รักษา ไม่บวก U1 ซ้ำจาก C1/C6 สัดส่วน support ต้องแสดงจำนวน CONTRADICTED และ NOT_IN_REFERENCE คู่กัน เพราะการยังไม่พบในเอกสารไม่เท่ากับพบว่าขัดแย้ง ถ้าไม่มีข้อให้ตรวจ ตัวหาร preservation/support เป็นศูนย์จึงแสดง N/A ส่วน coverage ยังเป็น0/5

ชุด C1–C5 ได้ preservation และ coverage ครบ แต่ confirmed support เพียง3/5หรือ60%ตาม fixture นี่เป็นผลการแยกที่ดีแม้คำตอบเดิมยังมีปัญหา ตัวเลขทั้งหมดเป็น SIMULATION ไม่ใช่ FActScore หรือ DecompScore ที่เรารันกับโมเดลจริง

ต้องแยกสูตรออกจาก implementation ด้วย เช่น repo FActScore ที่ตรวจมี default length penalty gamma10 และ init_score สำหรับคะแนนก่อน penalty การอ่านเพียงชื่อ score ไม่รับรองว่าเป็น raw fraction FActScore code

System Architecture: แยกหน้าที่ก่อนรวมคะแนน

แผนต่อไปนี้เป็น Conceptual Architecture / HYPOTHESIS สำหรับ application ที่ตรวจคำตอบ Agent ไม่ใช่ implementation ที่งานวิจัยทั้งห้าใช้ร่วมกัน และยังต้องทดสอบการแยกภาษาไทยกับข้อมูลจริง

ผังรวม ContextBinder กับ RedundancySelector เป็นหนึ่งกลุ่ม แต่ตารางแยกหน้าที่ชัด ควรเก็บข้อที่ถูกปฏิเสธหรือไม่แน่ชัดไว้ใน audit record พร้อมเหตุ ไม่ลบทิ้งจนตรวจย้อนหลังไม่ได้

Report + Memory ต้องเก็บข้อเดิมพร้อมสถานะและ provenance ใน audit record การรักษาข้อที่ขัดแหล่งหรือยังไม่ยืนยันไม่ได้อนุญาตให้เผยแพร่หรือใช้เป็น trusted fact รอบถัดไป การแก้ไข/อนุมัติต้องเป็น revisionและสถานะที่ตรวจใหม่

Ledger เป็น External Memory ข้อมูลที่นำมาอ่านเป็น Retrieved Context ใน Context Window การเขียนไฟล์/เปลี่ยนpromptไม่อัปเดต Model Weights การฝึกevaluatorต้องระบุtraining dataและประเมินแยก

Operational Flow: ตรวจต้นฉบับก่อนตรวจเอกสาร

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

ขั้นสอง สร้าง candidate พร้อม source spans และเก็บ entity/version/qualifiers ถ้าระบุต้นทางไม่ได้ให้ส่ง ambiguous หรือ introduced เพื่อทบทวน การมี JSON fields ครบไม่รับรองว่าค่าใน fields รักษาความหมาย

ขั้นสาม ตรวจทั้งข้อที่เพิ่มและข้อที่หาย ต้องดู original→candidate และ original coverage ด้วย ผล audit ไม่ควรตัดสินความจริง ถ้าคำตอบเดิมมีข้อผิด ให้เก็บข้อผิดนั้นตรง ๆ เพื่อส่งไปตรวจ

ขั้นสี่ เติมบริบทโดยแยก target กับ background พร้อม provenance ถ้า target/entity/qualifiersเปลี่ยนให้ตรวจเทียบต้นฉบับใหม่ บริบทจากแหล่งอื่นต้องมีtag ไม่ถูกนับเป็นข้อเดิมโดยเงียบ ๆ จากนั้นคัดข้อซ้ำพร้อมเก็บraw/rejectionlogและคำนวณ originalcoverageหลังคัดใหม่

ขั้นห้า ตรวจ target กับแหล่งที่ระบุ รวมรุ่น วันที่และ evidence spans แยก SUPPORTED, CONTRADICTED และยังไม่มีข้อมูล อย่าอ้างความจริงสากลจากผลเทียบชุดเอกสารที่จำกัด

ขั้นสุดท้าย รายงาน extraction กับ evidence แยกกัน ถ้าจะปรับคำตอบ ให้สร้าง revision ใหม่และ audit ใหม่ ไม่ใช้การลบข้อที่ไม่มีหลักฐานแทนการประเมินว่าคำตอบเดิมกล่าวอะไร Trace ของงานคือ source spans/คำสั่ง/ผลเครื่องมือ ไม่ใช่หลักฐานร่องรอยความคิดภายในโมเดล

# CONCEPTUAL pseudocode — ไม่ใช่โค้ด production ที่รันทดสอบแล้ว
original = capture_answer_snapshot(answer)
candidates = decompose_with_spans(original)
audit = check_preservation_and_missing_units(original, candidates)
if audit.mapping_unknown:
    return review_request_with_original_and_candidates(audit)
pairs = bind_target_and_minimal_context(candidates, original)
bound_audit = reaudit_targets_and_context_provenance(original, pairs)
if bound_audit.target_or_context_unresolved:
    return review_request(bound_audit)
selected, rejected = select_nonredundant_units_with_audit(pairs)
selection_audit = check_original_coverage_after_selection(original, selected)
evidence_results = verify_targets_against_versioned_references(selected)
return report_separate_extraction_evidence_and_limits(
    original, audit, bound_audit, selection_audit, selected, rejected,
    evidence_results)

originalคือsnapshot candidatesคือข้อเสนอ pairsแยกtarget/บริบท bound_auditตรวจหลังbinding selection_auditตรวจcoverageหลังคัด และevidence_resultsเทียบเอกสาร ฟังก์ชันเป็นข้อเสนอ ไม่รับรองsemantic auditที่รันจริง

Technical Comparison: หน่วยประโยค หน่วยเล็ก และหน่วยที่ผ่าน audit

ตารางเป็น ANALYSIS ไม่ใช่ benchmark จัดอันดับ การทำหน่วยเล็กมากไม่ได้ดีเสมอเมื่อขาดบริบท ส่วนการเก็บหน่วยใหญ่ก็ไม่ได้ผิดเสมอ แต่ให้ความละเอียดในการวินิจฉัยต่างกัน ต้องเลือกพร้อมเกณฑ์ completeness และงบของงาน

งาน DnDScore เสนอการสร้างคู่ subclaim กับข้อความที่เติมบริบท และให้ verifier ตรวจ target แยกจากพื้นหลัง เพื่อลดปัญหาการตรวจข้อมูลร่วมซ้ำ การเติมบริบทเองก็อาจผิด งานศึกษา English biographies/LFQA กับแหล่งคงที่ ไม่ยืนยันผลกับทุกภาษา DnDScore, EMNLP 2025

DecompScoreดั้งเดิมเป็นจำนวนเฉลี่ย แต่ตารางDnDScoreรายงานเป็นเปอร์เซ็นต์ ความสัมพันธ์ของ normalization ยัง UNKNOWN จึงไม่รวมสเกลหรือใช้สัดส่วนLabแทนต้นฉบับ

Entity และหน่วยซ้ำ: ทุกข้อผ่าน แต่ข้อความรวมยังทำให้เข้าใจผิดได้

งาน D-FActScore ศึกษากรณีคนชื่อเดียวกันที่ข้อเท็จจริงรายข้อรองรับได้จากคนละคน แต่ข้อความรวมทำให้ผู้อ่านคิดว่าเป็นคนเดียว จึงจัดกลุ่มตามบุคคลที่ผู้อ่านเข้าใจและจำกัดแหล่งตรวจภายในกลุ่ม ข้อนี้เตือนให้ตรวจการผูก entity ระดับข้อความด้วย Merging Facts, Crafting Fallacies, Findings ACL 2024

งาน Core เพิ่มการคัดข้อระหว่าง decomposition กับ verification โดยพิจารณาการรองรับจากต้นฉบับ redundancy แบบ entailment และน้ำหนัก informativeness ใน constrained selection เพื่อรับมือข้อซ้ำหรือข้อความง่ายที่ดันคะแนน การทำนี้มากกว่าลบ string ซ้ำ และไม่รับรองเก็บทุกข้อเดิมครบ Core, Findings ACL 2025

ใน Lab การรู้ว่า C1/C6 เป็นหน่วยเดียวกันเป็น labels ที่กำหนดไว้ ไม่รัน entailment model หรือ MILP ของ Core ในระบบจริงควรเก็บทั้งสิ่งที่เลือกและไม่เลือก เพื่อให้ตรวจได้ว่าหน่วยสำคัญหายระหว่างคัดหรือไม่

เกมจำลอง: รักษาข้อที่ยังไม่มีหลักฐานให้ครบด้วย

เกมมีสี่โจทย์เริ่มต้น: เลือกแต่ข้อที่รองรับ ทำ qualifier หาย ผสมผลิตภัณฑ์ และใช้สำเนาแทนข้อที่ยังขาด คุณเลือกได้ไม่เกิน7 raw candidate slots แต่ละข้อรวมสำเนาใช้หนึ่งช่อง การยกเลิกคืนช่อง ส่วนการระบุสถานะหลักฐานไม่ใช้ช่องเพิ่ม ตัวเลขนี้ไม่ใช่ tokens เวลา ค่า API หรืองบค้นจริง

เป้าหมาย: ครอบคลุม U1–U5 ด้วยข้อ atomic ที่ตรงต้นฉบับ ไม่มีสำเนา/ข้อใหม่/entity/รุ่น/qualifierผิด แล้วระบุสถานะเทียบเอกสารให้ถูก การเลือก C1–C5 หรือใช้ C6แทนC1อย่างไม่ซ้ำยังต้องเก็บ U4 และ U5 พร้อม NOT_IN_REFERENCE/CONTRADICTED แม้ confirmed support ไม่เต็ม

กดตรวจคำตอบเมื่อกำหนดสถานะทุกข้อที่เลือกแล้วเพื่อจบรอบ Empty selection ชนะไม่ได้ และ Reset เริ่มใหม่ได้ การได้ผลครบในเกมรับรองเพียงการเลือก/annotationตาม fixture ไม่วัดความสามารถแยกข้อความของโมเดลหรือการตรวจความจริงภาษาไทย

Applications และเกณฑ์นำไปใช้จริง

Agent ที่สร้างรายงานจากเอกสารสามารถเก็บ claim ledger เพื่อให้บรรณาธิการเห็นข้อที่เพิ่มหรือละพร้อม source spans งานสรุปคุณสมบัติผลิตภัณฑ์ควรรักษาเลขรุ่น เงื่อนไขการใช้งานและ entity pairing ส่วนงานเผยแพร่บทความอาจแยก extraction audit ออกจาก evidence review ก่อนแก้ต้นฉบับ นี่เป็นการประยุกต์ที่เสนอ ไม่อ้างระบบผลิตที่ติดตั้งแล้ว

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

มนุษย์อาจเห็นต่างเรื่อง atomicity จึงต้องมีคู่มือและตัวอย่าง ไม่ถือคำตอบของ LLM อีกตัวเป็น gold โดยไม่ตรวจ ดู คู่มือตรวจคำตอบ AI สำหรับการอ่านแหล่งและตรวจตัวเลขหลังแยก

Limitations / Failure Modes

Qualifier หาย: คำว่าเฉพาะ เมื่อ หรือรุ่นใดจำกัดข้อกล่าวอ้าง การตัดออกอาจขยายขอบเขต ต้องเก็บความสัมพันธ์ ไม่เก็บคำเงื่อนไขเป็นข้อความลอย ๆ

Reference ปะปนกับต้นฉบับ: ข้อมูลจากเอกสารที่ถูกเติมเข้า extraction อาจจริงตามแหล่งแต่ไม่ได้กล่าวในคำตอบ ให้ตรวจ provenance ของ record และแยกการแก้เนื้อหา

ข้อมูลซ้ำกับตัวหาร: การนับ paraphraseเป็นหลายหน่วยหรือทิ้งข้อยากทำให้ supportratioเปลี่ยนโดยสาระไม่ดีขึ้น เก็บ raw/normalized counts และ coverageคู่กัน

Span ถูกแต่ตีความผิด: การอ้าง offsetsและquoteไม่ได้รับรอง entitybindingหรือentailment และoffsetต่างระบบอาจเป็นbytes/codepoints/UTF-16 ต้องระบุหน่วยกับเวอร์ชัน

ผู้ตรวจ semantic ผิด: ทั้ง extractor และ verifier มี error model ข้อมูลภาษาไทย/โดเมนใหม่ยังต้องตรวจ ไม่อนุมานผลทุกภาษาจากการทดลองภาษาอังกฤษ

เอกสารไม่ครบหรือผิด: NOT_IN_REFERENCE ไม่แปลว่าfalse และ SUPPORTED ไม่แปลว่าพิสูจน์โลกจริง ต้องรายงานขอบเขตแหล่งรวมความขัดแย้งที่พบ

Future Directions และ Practical Takeaways

ควรทดสอบ audit ข้อเพิ่ม/ขาดพร้อม uncertainty การรักษา entity/qualifiers และการตรวจใหม่เมื่อต้นทางเปลี่ยน ข้อเสนอเป็น HYPOTHESIS ยังไม่พิสูจน์ผลกับ Agentจริง

เก็บoriginal/span mapping ดูการรักษา ความครบ atomicityและหลักฐานแยกกัน เก็บrejectionlogและcoverageหลังคัด คะแนนเดียวไม่รับรองว่าข้อเพิ่ม/ตกหล่นดีขึ้น

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

FAQ

Claim Decomposition คืออะไร?

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

ข้อย่อยมีหลักฐานภายนอกแล้วถือว่าแยกถูกหรือไม่?

ไม่ ต้องตรวจว่าข้อนั้นอยู่ในคำตอบเดิมด้วย C8ในตัวอย่างมีR5รองรับแต่เป็นเนื้อหาใหม่ที่ต้นฉบับไม่ได้กล่าว

ควรลบข้อที่ไม่มีหลักฐานระหว่างการแยกหรือไม่?

ถ้าประเมินต้นฉบับให้เก็บพร้อมสถานะ การลบทำให้ตรวจความครบไม่ได้ การแก้คำตอบเป็นrevisionแยกต่างหาก

DecompScore กับ FActScore วัดสิ่งเดียวกันหรือไม่?

DecompScoreดั้งเดิมใช้ต้นฉบับตรวจคุณภาพการแยกเป็นจำนวนข้อเฉลี่ย ส่วนFActScoreประเมินสัดส่วนsupportจากknowledge source ต้องระบุรุ่น/สูตรimplementationด้วย

ลบข้อซ้ำรับรองว่าประเมินครบหรือไม่?

ไม่ อาจเหลือชุดไม่ซ้ำแต่มีข้อที่ตกหล่น ต้องตรวจ originalcoverageด้วย และไม่ถือfingerprintสมมติเป็นsemantic equivalenceทั่วไป

เกมฝึกตัวแยกหรือรันงานวิจัยจริงหรือไม่?

เป็นJavaScriptSIMULATIONของcatalogและlabelsที่กำหนด ไม่รันLLM/parser/NLI/MILP ไม่อัปเดตweights และไม่ทำซ้ำbenchmarkต้นฉบับ

References และขอบเขตหลักฐาน

• FActScore, EMNLP2023 — อ่านนิยาม/data/estimator/ข้อจำกัดและ authorcode; gamma/rawscoreขึ้นกับimplementation ไม่รันทำซ้ำ
• A Closer Look at Claim Decomposition, *SEM2024 — อ่านcoverage/coherence/atomicity, DecompScoreและวิธีแยก; exactauthorrunnable repoยังUNKNOWN
• DnDScore, EMNLP2025 — อ่านtarget/contextpair วิธีตรวจและข้อจำกัด; appendixpromptsมี แต่exactauthorrepoยังUNKNOWN ไม่รวมสเกลDecompScoreที่ยังไม่ชัด
• Merging Facts, Crafting Fallacies, FindingsACL2024 — อ่านentitygroupingและข้อจำกัด พร้อม authorrepo
• Core, FindingsACL2025 — อ่านsemanticconstraints/selection/weightsและ README; defaultuniformweightsต่างจากcustomUNLIsetting ไม่มีการรันpackage

สถานะ: FACTคือวิธีและนิยามที่ต้นฉบับระบุ REPORTED CLAIMจำกัดผลไว้กับข้อมูล/โมเดลยุคที่ศึกษา ANALYSISคือการเทียบหน้าที่ HYPOTHESISคือแผนapplication SIMULATIONคือInteractive/เกม/สัดส่วนจากcatalogสมมติ ไม่มีindependentbenchmarkreproduction ผลทดลองLLMภาษาไทย หรือtoken/cost/latencyจริงของHYBRID MINDในบทความนี้