Constraint-Aware Planning: ให้ AI Agent ตรวจข้อจำกัดก่อนลงมือด้วยตัวแก้ปัญหา

คำตอบโดยตรง: Constraint-Aware Planning คือการวางแผนโดยระบุสิ่งที่ต้องเป็นจริงอย่างชัดเจน เช่นลำดับงาน เวลา และจำนวนทรัพยากร แล้วใช้โปรแกรมค้นหรือทดสอบแผนกับเงื่อนไขเหล่านั้น LLM อาจช่วยแปลงคำขอหรือเสนอแผน ส่วน solver ค้นคำตอบ และ validator ตรวจแผนที่ได้รับ ผลตรวจรับรองได้เฉพาะโมเดลและข้อมูลที่ใส่ไว้ ไม่ได้ยืนยันว่าโลกจริงถูกจำลองครบหรือการกระทำได้รับสิทธิ์แล้ว

ทำไมแผนที่อ่านลื่นจึงยังลงมือไม่ได้

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

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

เรื่องนี้ต่อจาก World Model ของ AI Agent แต่เจาะตัวตรวจเงื่อนไขและการค้นคำตอบ ไม่ใช่คู่มือตรวจรับทั่วไป ผู้อ่านจะได้เห็นทั้งแผนที่ไม่ผ่าน โมเดลที่ขาดข้อกำหนด และกรณีค้นไม่พบในขอบเขตที่กำหนด

รากฐาน: Variables, Domains, Constraints และ Objective

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

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

เอกสาร OR-Tools อธิบาย CP-SAT สำหรับโมเดลที่ใช้จำนวนเต็ม และแยกสถานะคำตอบออกจากสถานะที่ยืนยัน optimum การมี objective ไม่ได้ทำให้ทุกคำตอบที่พบเป็นคำตอบดีที่สุด OR-Tools CP-SAT Solver

Scheduling กับ Action-State Planning ต่างกันอย่างไร

Scheduling เริ่มจากงานที่กำหนดไว้แล้วและเลือกว่าจะจัดเมื่อไร ภายใต้ทรัพยากรและลำดับ ตัวอย่าง Job Shop ของ OR-Tools ใช้เวลาเริ่ม/จบ ระยะเวลา precedence และข้อจำกัดงานไม่ซ้อนกัน OR-Tools Job Shop

Action-State Planning เช่นปัญหา PDDL ต้องค้นด้วยว่าทำ action อะไรจากสถานะเริ่มต้นเพื่อให้ถึงเป้าหมาย โดย action มี preconditions และ effects งานสองประเภทเชื่อมกันได้ แต่ไม่ได้เป็นกลไกเดียวกันโดยอัตโนมัติ เอกสาร Fast Downward ระบุขอบเขต classical planning และไม่รองรับ temporal planning หรือ numeric planning ทั่วไป เกมจัดตารางในบทความนี้จึงไม่ใช่ Fast Downward implementation Fast Downward PDDL Support

โมเดลจำลอง: งานสี่รายการและทรัพยากรร่วมกัน

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

งาน	หน้าที่	ระยะเวลา	ต้องรออะไรเสร็จ
A	เตรียมข้อมูล	2	ไม่มี
B	สร้างร่าง	3	A
C	ตรวจข้อมูล	2	A
D	ส่งงานในแบบจำลอง	1	B และ C

แต่ละงานใช้ทรัพยากรหนึ่งหน่วย ค่า capacity บอกจำนวนงานที่ทำพร้อมกันได้ เริ่มต้นมี capacity = 1 และขอบเวลาค้นหา H = 8 ทุกงานต้องเริ่มไม่ติดลบและจบไม่เกิน H

ให้ s_i เป็นเวลาเริ่มงาน i, d_i เป็นระยะเวลา และ e_i = s_i + d_i เป็นเวลาจบ เงื่อนไข A ก่อน B คือ e_A ≤ s_B และ D ต้องรอทั้ง e_B ≤ s_D กับ e_C ≤ s_D ช่วงทำงานใช้ [s_i, e_i) ซึ่งรวมจุดเริ่มแต่ไม่รวมจุดจบ จึงให้งานถัดไปเริ่มตรงเวลาที่งานก่อนจบได้

ข้อจำกัดทรัพยากรตรวจจำนวนงานที่ active ในแต่ละช่วงให้ไม่เกิน capacity ส่วน objective ของตัวอย่างคือลด Makespan หรือเวลาจบของงานสุดท้าย max(e_A, e_B, e_C, e_D) ไม่ใช่ลดเวลาเริ่มของ D อย่างเดียว

Interactive: แก้เวลาแล้วอ่านข้อผิดพลาดที่ตรวจได้

Explorer ด้านล่างให้เปลี่ยนเวลาเริ่ม capacity และ H ตรวจ candidate ที่เลือก หรือค้นทุกค่าเวลาเริ่มในช่วงที่อนุญาต แสดง input, timeline, เงื่อนไขที่ละเมิด และผลตรวจ พร้อม Reset

SIMULATION · CONSTRAINT EXPLORER

แผนนี้ผ่านกฎชุดไหน?

ลองขยับเวลาเริ่ม A–D แล้วตรวจลำดับงานและความจุ เครื่องมือนี้นับช่วงเวลาแบบ [start,end): งานหนึ่งจบที่ t=2 อีกงานเริ่มที่ t=2 จึงไม่ทับกัน

A เตรียมข้อมูล · duration 2B สร้างร่าง · duration 3C ตรวจข้อมูล · duration 2D ส่งงาน · duration 1ความจุทรัพยากรต่อช่วง1 หน่วย2 หน่วยขอบเขตเวลา H5 ช่วงเวลา6 ช่วงเวลา7 ช่วงเวลา8 ช่วงเวลา9 ช่วงเวลา10 ช่วงเวลา

ใส่กฎ “ตรวจข้อมูลเสร็จก่อนส่ง” C→D

ตรวจแผนนี้ค้นทุกแผนในช่วง Hลองแบบจำลองตกหล่นกฎReset

ยังไม่ได้ตรวจ — ลองแผนที่ B กับ C ใช้ทรัพยากรพร้อมกัน

โจทย์เต็ม: ต้องมี A,B,C,D ครบ · duration=2,3,2,1 · A→B, A→C, B→D, C→D · ใช้ทรัพยากรงานละ 1 หน่วย · start เป็นจำนวนเต็มและทุกงานจบภายใน H · เป้าหมายลด makespan การปิดกฎ C→D เปลี่ยนแบบจำลอง แต่โจทย์เต็มใน Gate 2 ยังเหมือนเดิม

ผลจากกฎจำลองที่เราระบุเอง ไม่มี LLM หรือ CP-SAT/VAL ทำงานอยู่เบื้องหลัง ไม่ใช่การวัดประสิทธิภาพ Agent จริง

ลองเริ่มด้วยเวลา [A=0, B=2, C=2, D=5] ถ้า capacity = 1 งาน B กับ C ชนกัน แม้ precedence ผ่าน เมื่อเปลี่ยนเป็น capacity = 2 แผนนี้ผ่านและจบที่ 6 ส่วนแผน [0,2,5,7] ผ่านเมื่อ capacity = 1 และจบที่ 8

เราอธิบายขอบล่างได้ด้วยมือ: capacity หนึ่งช่องต้องรองรับระยะเวลารวม 2+3+2+1 = 8 จึงจบเร็วกว่า 8 ไม่ได้ ส่วนเส้นทาง A→B→D มีระยะเวลา 2+3+1 = 6 แม้มีสองช่องก็จบก่อน 6 ไม่ได้ แผนที่แสดงทำได้เท่าขอบล่าง จึงเป็น optimum ของ โมเดลจำลองนี้ ไม่ใช่ตัวเลข benchmark

ต้นแบบค้นด้วย Exact Enumeration แจกแจงเวลาเริ่มทั้งหมดใน domain ที่จำกัด ไม่ใช้ CP-SAT, VAL หรือ LLM สามารถยืนยันแผนดีที่สุดในช่วงเมื่อค้นครบ หาก H = 5 และ capacity = 2 จะไม่มีคำตอบใน H นี้ เพราะเส้นทางบังคับต้องใช้เวลาอย่างน้อย 6 ไม่ได้แปลว่าโจทย์ไม่มีทางทำสำเร็จเมื่อเพิ่มเวลา

โมเดลที่ขาดเงื่อนไข: ผ่านตัวตรวจ แต่ผิดเจตนาได้

ปุ่มตัวอย่างโมเดลไม่ครบใน Explorer เปิดให้ลองปิดกฎ C→D สมมติแผนเป็น [0,2,6,5] ใน capacity หนึ่งช่องและ H เท่ากับ 8 งานไม่ชนกันและผ่านกฎที่ยังเปิดไว้ แต่ D ถูกส่งก่อน C เริ่ม จึงขัด brief ต้นฉบับที่ต้องตรวจข้อมูลก่อนส่ง

นี่เป็น SIMULATION ของ specification error ไม่ใช่การเจาะระบบ ตัวตรวจไม่ได้รู้ข้อกำหนดที่เราลืมใส่ เปรียบเทียบผล “ผ่านกฎที่เปิด” กับ “ผ่าน brief เต็ม” ซึ่งทั้งสองชุดกฎนิยามไว้ให้ตรวจในตัวอย่าง แผนผ่านจากโมเดลชุดแรกจึงไม่ควรถูกอธิบายว่าได้รับการพิสูจน์ครบทุกความต้องการ

ในระบบจริงต้องตรวจ mapping ระหว่างข้อความผู้ใช้กับ formal model ด้วย เช่น entity ที่ถูกต้อง ข้อกำหนดที่ห้ามตกหล่น และหน่วยเวลา การใช้ LLM แปลโจทย์แล้วให้ solver ตรวจเพียง syntax ไม่ตรวจว่าแปลถูกความหมายยังเหลือจุดผิดพลาดสำคัญ

Architecture: แยกผู้เสนอ ผู้ค้น และผู้ตรวจ

ผังนี้เป็น Conceptual Architecture / HYPOTHESIS ของ HYBRID MIND ดัดแปลงแนวคิด tool-assisted planning ส่วนที่ทดสอบจริงคือ scheduling toy และตัวตรวจใน Lab ไม่ใช่ระบบ Agent ทั้งผังหรือผลทดลองงาน production

Module	Input → Output และ Data Structure	สิ่งที่ตรวจได้และ Failure Mode
State & Brief Intake	คำขอ/ผลเครื่องมือ → snapshot พร้อม version, entities, goal	อ่านสถานะกลับ; snapshot เก่าหรือข้อมูลรับผิด entity
Specification Builder	brief → variables, domains, hard constraints, objective	เทียบข้อกำหนดกับต้นฉบับ; แปลหน่วยผิดหรือทำ hard constraint หาย
Specification Review	encoded model → ข้อแก้/สถานะพร้อมทดสอบ	ตรวจ completeness ตามโจทย์; syntax ผ่านแต่ความหมายผิด
Candidate Proposer	model/context → candidate plan ที่มี ID	แปลงเป็นข้อมูลตรวจได้; LLM สร้าง task/action ที่ไม่มีใน model
Solver	model กับ budget → solution/status/objective	อ่านผลและขอบเขต; timeout หรือใช้ objective ไม่ตรงงาน
Plan Validator	model กับ candidate → รายการละเมิด/ผ่าน	คำนวณลำดับและทรัพยากรซ้ำ; ใช้กฎชุดเก่าหรือตรวจไม่ครบ
Action Gate & Executor	validated plan/version/สิทธิ์ → action result	ตรวจ snapshot และขอบเขตสิทธิ์; plan ผ่านแต่โลกเปลี่ยนหรือ action ล้มเหลว
Feedback & Trace	ผลจริงกับผลคาด → revalidation/replanning log	จับคู่ ID และผลเครื่องมือ; บันทึกความคาดหวังเป็นผลสำเร็จ

Candidate Proposer ไม่จำเป็นต้องเป็น LLM และไม่ต้องใช้ทั้ง proposer กับ solver ทุกครั้ง บางงานสร้างแผนจาก solver โดยตรงได้ ส่วน validator ตรวจ candidate ไม่ได้มีหน้าที่ค้นคำตอบอื่นเสมอไป

Plan certificate หรือผลตรวจควรผูกกับ model version, state snapshot, candidate ID และกฎที่ใช้ หาก capacity เปลี่ยนหลังตรวจ ต้องประเมินแผนกับสถานะใหม่ก่อนลงมือ ผลตรวจเดิมยังอธิบายได้ว่าแผนผ่านในโมเดลใด แต่ไม่ใช่ผลตรวจของโมเดลที่เปลี่ยนแล้ว

Operational Flow: วงรอบที่ตรวจร่องรอยได้

ตัวอย่าง Pseudocode ต่อไปเป็น แนวคิด ไม่ใช่โค้ดเชื่อม production solver ที่รันทดสอบแล้ว ส่วน JavaScript ของ Lab มีหลักฐานทดสอบแยก

snapshot = read_state_with_version()
model = encode_and_review(brief, snapshot)
candidate, search_status = solve_or_propose(model, budget)
if candidate is absent: return report(search_status, scope)
validation = check(candidate, model)
if validation fails: return violations for revision
if live_version differs from snapshot:
    snapshot = read_state_with_version()
    model = encode_and_review(brief, snapshot)
    validation = check(candidate, model)
    if validation fails: return violations for revision or replanning
if action is authorized: execute and verify observed result

วงรอบอาจส่ง violations เช่น “C จบที่ 8 แต่ D เริ่มที่ 5” กลับให้ผู้เสนอแก้ นี่เป็น feedback ที่คำนวณซ้ำได้ แตกต่างจากคำบรรยายว่า “ฉันตรวจครบแล้ว” ซึ่งไม่แสดงว่าระบบได้รันตัวตรวจจริง ร่องรอยที่ควรเปิดให้ดูคือค่าตัวแปร กฎ ผล solver ผล validator และ action result

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

เกมจำลอง: จัดสี่งานให้ผ่านเงื่อนไข

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

SIMULATION · SCHEDULING GAME

เกมจัดตาราง: ตรวจให้ผ่านก่อนรัน

แก้เวลาเริ่มของงานจริงในตารางจำลอง ผ่านสี่ด่านด้วยกฎเดียวกับบทความ คะแนนเป็นของเกมสอนแนวคิดเท่านั้น ไม่มีการส่งงานภายนอก

เลือกด่าน1 แก้แผนชนกัน2 ใช้ความจุให้คุ้ม3 ไม่มีแผนใน H นี้4 โลกเปลี่ยนหลังตรวจ

A เตรียมข้อมูล · duration 2B สร้างร่าง · duration 3C ตรวจข้อมูล · duration 2D ส่งงาน · duration 1

ตรวจแผนค้นทุกแผนใน Hจำลองรันแผนที่ตรวจReset ด่านReset เกมทั้งหมด

ช่วงเวลา [start,end) · กฎ A→B, A→C, B→D, C→D · resource=1 ต่องาน · ต้องทำครบ A–D และจบใน H การค้นสำรวจเวลาเริ่มจำนวนเต็มครบในขอบเขตที่แสดง หากยังไม่ค้น ด่าน 3 ให้ UNKNOWN ไม่ใช่ไม่มีแผน

ใบตรวจผูกกับข้อมูลและ model version เมื่อโลกเปลี่ยนต้องตรวจใหม่ การจำลองรันเป็นการตรวจตารางขนาดเล็ก ไม่มีการเรียก API, ฝึกโมเดล หรือรับรองความปลอดภัยของระบบจริง

ด่านทรัพยากรหนึ่งช่องต้องแก้ตารางที่ชนกัน ด่านสองช่องให้หาคำตอบที่จบเร็วภายใต้กฎเดิม ด่าน H = 5 ฝึกยอมรับว่าค้นครบแล้วไม่มีแผนในช่วงนี้ ส่วนด่านข้อมูลเปลี่ยนหลังตรวจให้ผูกผลตรวจเข้ากับ version และตรวจใหม่ เกมไม่ได้พิสูจน์ว่า AI รุ่นใดทำงานเร็วขึ้นหรือปลอดภัยกว่า

อย่าถอดเงื่อนไขสำคัญหรือทิ้ง task เพื่อทำให้ผ่าน การแก้เวลาจาก 8 เป็น 6 โดยใช้ capacity สองช่องเป็นผลภายใต้ทรัพยากรที่เปลี่ยน ไม่ใช่การปรับนโยบายหรือเรียนรู้น้ำหนักจากการเล่นซ้ำ

เปรียบเทียบสามแนวทาง

แนวทาง	กลไก	เหมาะกับ	ข้อจำกัด
LLM Proposal + Validator	เสนอ candidate แล้วตรวจใน model	มีข้อมูลภาษาและอยากใช้ feedback แก้แผน	อาจไม่เสนอคำตอบที่มีอยู่; encoding อาจผิด
Constraint Solver / Scheduling	เลือกค่าตัวแปรให้ผ่าน constraints และอาจ optimize	เวลา/ทรัพยากร/การจัดสรรที่เขียนเป็นกฎได้	ค่า search ขึ้นกับ domain/budget; ไม่รู้เงื่อนไขที่ตกหล่น
Symbolic Action-State Planner	ค้นลำดับ actions จาก preconditions/effects	ต้องหา actions ที่ทำให้ goal จริงในแบบจำลอง	domain และ initial state ต้องเหมาะ; รองรับเวลา/ตัวเลขต่างกันตามเครื่องมือ

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

หลักฐานจากงานวิจัยและเครื่องมือจริง

LLM+P: ภาษาเชื่อมกับโมเดลที่เตรียมไว้

LLM+P เป็น preprint ปี 2023 เสนอให้ LLM แปลงโจทย์เป็น PDDL problem ใช้ planner ค้นแผน แล้วแปลงกลับเป็นภาษา การทดลอง v3 ใช้ domain ที่ผู้เชี่ยวชาญเตรียมและตัวอย่างหนึ่งคู่ ใช้ GPT-4 ณ กันยายน 2023 กับ Fast Downward 22.12.0 และงบค้น 200 วินาที ไม่ใช่ระบบที่สร้าง domain ถูกต้องจากศูนย์ในทุกงาน ความผิดพลาดในการแปลโจทย์ยังทำให้ planner แก้ปัญหาผิดเรื่องได้ LLM+P v3

LLM-Modulo: Generate–Test–Critique พร้อมขอบเขตของข้อเสนอ

งาน Position: LLMs Can’t Plan, But Can Help Planning in LLM-Modulo Frameworks เป็น ICML 2024 Position paper เสนอวงรอบ generate, test, critique โดยแยก hard critics จากคำวิจารณ์ด้านอื่น ชื่อและจุดยืนว่า LLM วางแผนไม่ได้เป็นท่าทีของผู้เขียนตามการวิเคราะห์นั้น ไม่ใช่ข้อสรุปครอบคลุมโมเดลทุกตัวในปี 2026 หลักที่นำมาใช้คือแยกข้อเสนอภาษาจากการตรวจเงื่อนไขจริง Kambhampati et al., PMLR 235

PlanBench และ Critical Investigation เป็นคนละงาน

PlanBench อยู่ใน NeurIPS 2023 Datasets and Benchmarks ประเมินหลายงานทั้ง generation, verification, การติดตามผล action และ replanning มี domain เช่น Blocksworld/Logistics และการเปลี่ยนชื่อสัญลักษณ์เพื่อทดสอบความทนทาน ผลต้องอ่านกับโมเดลและวิธีทดลองของยุคนั้น PlanBench

On the Planning Abilities of Large Language Models — A Critical Investigation เป็นอีกบทความใน NeurIPS 2023 Main ใช้การตรวจแผนและ feedback ภายใต้เงื่อนไขทดลองที่กำหนด การทดลองวน feedback ในส่วนหนึ่งเลือกโจทย์ที่ล้มเหลวและจำกัดจำนวนรอบ ไม่ควรขยายเป็นรับรองความสำเร็จทุกโจทย์ของรุ่นปัจจุบัน Critical Investigation

Solver กับ Validator ที่มีเอกสารและโค้ด

Fast Downward มี paper JAIR ปี 2006 และเอกสารขอบเขต PDDL ที่รองรับ ส่วน VAL มีโปรแกรม Validate รับ domain, problem และ candidate plan เพื่อตรวจ preconditions/invariants ตามโมเดลและการตั้งค่าที่ใช้ การมีโค้ดให้ตรวจไม่แปลว่าเราได้ build หรือรันเครื่องมือแล้ว บทความนี้ไม่ได้ทดลอง native Fast Downward, CP-SAT หรือ VAL Helmert, JAIR 2006, VAL Applications

อ่านสถานะให้ถูกก่อนสรุปว่า “ทำไม่ได้”

OR-Tools แยกสถานะ FEASIBLE ว่าพบคำตอบผ่านข้อจำกัดแต่ยังไม่ได้ยืนยันดีที่สุด จาก OPTIMAL ที่ยืนยัน optimum ตาม model/objective ส่วน INFEASIBLE คือพิสูจน์ว่าโมเดลที่ส่งไม่มีคำตอบ MODEL_INVALID คือโมเดลไม่ผ่าน validation และ UNKNOWN คือการค้นหยุดโดยยังไม่มีคำตอบหรือข้อพิสูจน์ที่เพียงพอ Timeout จึงไม่เท่ากับ infeasible CP-SAT Statuses

ถ้าแบบจำลองจำกัด H, domain หรือ action set ข้อพิสูจน์ไม่มีคำตอบก็ผูกกับขอบเขตนั้น Lab ใช้สถานะของ simulation ตามการตรวจ candidate และการแจกแจงจริง ไม่ได้คืนผลจาก CP-SAT อย่านำ status code ของตัวอย่างไปใช้เป็น certificate ของ production solver

Failure Modes: โมเดลถูกตรวจ แต่โลกยังไม่ครบ

Perception และ encoding ผิด: ตัวเลข capacity ล้าสมัย initial state รับจากแหล่งผิด หรือข้อกำหนดมีสองความหมาย ทำให้ solution ผ่านในโจทย์ที่ไม่ตรงโลก ต้องตรวจ specification และแหล่งของข้อมูลก่อนอ้างผล

Objective กลบข้อบังคับ: หากลด makespan โดยยอมส่งก่อนตรวจ ผลอาจดีตามคะแนนและผิด brief นี่เป็นการเปลี่ยนปัญหา ไม่ใช่ความสำเร็จของปัญหาเดิม

ผลตรวจเก่า: โลกเปลี่ยนหลัง validation ต้องเชื่อม version หรือวิธีตรวจ state ใหม่ การที่ candidate เคยผ่านไม่ได้ทำให้ผ่านทุก snapshot

Feedback ไม่ครบ: ข้อความที่ชี้เพียงหนึ่ง violation ไม่ได้ยืนยันว่าไม่มีข้ออื่น และการให้ LLM ตรวจตัวเองซ้ำไม่มีหลักฐานว่ารันเครื่องมือภายนอก ต้องเก็บผลจริงกับ ID ของแผน

สิทธิ์และ execution: ความเป็นไปได้ตามกฎเวลาไม่ให้สิทธิ์ส่งข้อมูลหรือแก้ระบบ การตรวจสิทธิ์เป็นอีกเงื่อนไขของ executor และการตรวจผลหลัง action ยังจำเป็น โดยไม่มีการลงมือจริงใน Lab

Memory กับ learning ปะปน: Context Window คือข้อมูลในรอบประมวลผล Retrieved Context คือส่วนที่ค้นคืน External Memory อาจเก็บ constraints กับ trace ส่วน weight updates เป็นการฝึกพารามิเตอร์ การแก้ model specification หรือจด violation ไม่ได้ฝึกน้ำหนักอัตโนมัติ

ทดสอบและต่อยอดอย่างไร

เริ่มจากแผนที่รู้เฉลย ตรวจ adjacency ที่งานหนึ่งเริ่มตรงงานก่อนจบ การชนทรัพยากร precedence ทุกเส้น และขอบ H ต่อด้วยโมเดลที่ขาดกฎกับ snapshot ที่เปลี่ยน แล้วตรวจว่าระบบแยก invalid candidate, bounded infeasible และยังไม่รู้ผลได้

หากใช้ความไม่แน่นอนของสถานะร่วมด้วย ต้องระบุว่า constraints ใช้กับทุกสถานการณ์หรือเพียงสถานะประมาณการ บทความ Belief State อธิบายส่วนประมาณสถานะ แต่ probability สูงไม่แทนเงื่อนไขหรือขอบเขตความเสี่ยงที่ต้องการ

ทิศทางวิจัยคือการตรวจว่าภาษาแปลงเป็นกฎครบหรือไม่ การเลือก feedback ที่ช่วยแก้โดยไม่วน และการวางแผนใหม่ภายใต้งบเวลา หากเปรียบเทียบระบบ ต้องควบคุม model version, dataset, solver configuration, budget และเกณฑ์สำเร็จ ไม่ใช้ผลเกมนี้แทน benchmark

Practical Takeaways

1. เขียนตัวแปร domain ข้อบังคับ และ objective แยกกันก่อนค้นแผน
2. ตรวจความหมายของ formal model เทียบ brief ไม่ตรวจแค่ syntax
3. แยกการเสนอ candidate การค้นคำตอบ และการตรวจ candidate
4. ผูกผลตรวจกับ model/snapshot/version และอ่าน status พร้อมขอบเขต
5. ตรวจผลของ action จริง และแยก memory update จากการฝึกน้ำหนัก

FAQ

Constraint-Aware Planning ต้องมี LLM หรือไม่

ไม่จำเป็น หากโจทย์เป็นข้อมูลชัดเจน สามารถใช้ solver และ validator ได้โดยตรง LLM อาจช่วยแปลภาษาแต่ต้องตรวจ encoding

แผน FEASIBLE หมายถึงดีที่สุดหรือไม่

หมายถึงผ่านเงื่อนไขที่ระบุ ต้องมีหลักฐานเพิ่มเติมตามเครื่องมือและ objective ก่อนเรียกว่า optimal

ค้นหมดเวลาแล้วควรบอกว่าไม่มีคำตอบหรือไม่

ไม่ควรสรุป infeasible จาก timeout ต้องรายงานว่าไม่พบข้อสรุปในงบที่ใช้ หรือใช้ status ที่เครื่องมือส่งจริง

ทำไมแผนผ่านแล้วจึงยังผิด brief ได้

โมเดลอาจแปลข้อกำหนดผิดหรือตกหล่น ผลผ่านรับรองเฉพาะกฎที่นำเข้า ไม่รวมสิ่งที่ไม่ได้เขียน

Validator ต่างจาก Solver อย่างไร

Validator ตรวจ candidate ที่ได้รับ Solver ค้นค่าหรือลำดับที่ผ่าน model บางระบบมีทั้งสองหน้าที่แต่ต้องระบุว่าได้รันขั้นไหน

เกมนี้รัน CP-SAT หรือพิสูจน์ความสามารถของ AI หรือไม่

เป็น exact enumeration และตัวตรวจ JavaScript ใน scheduling toy ไม่ใช่ CP-SAT/VAL/LLM และไม่ใช่ benchmark AI

การแก้แผนจาก feedback คือการเรียนรู้โมเดลหรือไม่

ในต้นแบบเปลี่ยนข้อมูลกับแผน ไม่ฝึกพารามิเตอร์ ระบบอื่นต้องระบุกลไกการเรียนรู้และหลักฐานแยกต่างหาก

References และสถานะหลักฐาน

• LLM+P v3, 2023, original code — preprint; แยก domain ที่เตรียมไว้ รุ่นโมเดล และงบทดลอง
• LLM-Modulo ICML 2024 Position — peer-reviewed Position paper; ไม่ใช้จุดยืนผู้เขียนเป็นข้อเท็จจริงของโมเดลทุกยุค
• PlanBench, NeurIPS 2023 Datasets and Benchmarks, code — benchmark methodology ต้องผูกกับรุ่นและเงื่อนไข
• Critical Investigation, NeurIPS 2023 Main — คนละงานกับ PlanBench; อ่านข้อจำกัดชุดทดลองและ feedback
• Fast Downward, JAIR 2006, full paper upload ปี 2011, PDDL Support — ปี upload ไม่ใช่ปีตีพิมพ์; ไม่ได้รัน native planner
• OR-Tools CP-SAT — official model/status docs; ไม่ได้รัน CP-SAT
• OR-Tools Job Shop — official scheduling tutorial; ตัวอย่างบทความดัดแปลงเพื่อการสอน
• VAL original repository, Applications — original code/docs; ไม่ได้ build/run

แยกหลักฐาน: กลไกตามเอกสารเป็น FACT ผลทดลองของผู้วิจัยเป็น REPORTED CLAIM การเปรียบเทียบเป็น ANALYSIS ผังต่อยอดเป็น HYPOTHESIS และตัวอย่าง/เกมเป็น SIMULATION การรัน native tools หรือทำซ้ำ benchmark โดย HYBRID MIND ยัง UNKNOWN