llama.cpp b9743: Local LLM Agent ไม่ได้พังเพราะโมเดลอย่างเดียว แต่พังที่ JSON Gate ได้

Local LLM Agent ไม่ได้พังเพราะโมเดลอย่างเดียวครับ

หลายครั้งมันพังเพราะ “JSON ออกมาไม่เป๊ะ”

ฟังดูเหมือนเรื่องเล็กมาก แต่ถ้า AI Agent ของเราต้องส่งผลลัพธ์ต่อให้ระบบอื่น เช่น CRM, ERP, ticketing, spreadsheet, invoice system หรือ automation workflow เรื่องนี้กลายเป็น production issue ได้ทันที

วันที่ 20 มิถุนายน 2026 ตาม GitHub release metadata, llama.cpp ออก release b9743 โดยมี change หลักคือ common/json-schema-to-grammar : align spacing rules with parsers (#24835)

PR ที่เกี่ยวข้องอธิบายว่า json-schema-to-grammar มี trailing spaces ที่ถูกจัดการเพื่อแก้ ambiguity กับ XML delimiters เช่นรูปแบบ newline ก่อนและหลัง

ถ้าอ่านแบบ developer นี่คือ parser/grammar fix

แต่ถ้าอ่านแบบ operator นี่คือสัญญาณสำคัญกว่า: agent ที่ใช้ local หรือ open-weight model ต้องมี Structured Output Gate

1) เกิดอะไรขึ้น

llama.cpp เป็น runtime สำคัญของโลก local/open-weight LLM เพราะหลายทีมใช้มันเพื่อรันโมเดลบนเครื่องตัวเอง บน server ตัวเอง หรือในระบบที่ต้องการคุมต้นทุนและข้อมูลมากกว่าการเรียก cloud API ตลอดเวลา

release b9743 ไม่ใช่ launch ใหญ่ ไม่ใช่โมเดลใหม่ และไม่ใช่ benchmark ชนะใคร

มันเป็นการแก้ behavior ของ json-schema-to-grammar ให้ spacing rules align กับ parser มากขึ้น

พูดง่าย ๆ คือเมื่อเราใช้ schema หรือ grammar เพื่อบังคับให้ model output เป็นรูปแบบที่ระบบอ่านต่อได้ รายละเอียดเล็ก ๆ อย่างช่องว่าง ท้ายบรรทัด delimiter และ parser expectation กลายเป็นเรื่องจริงจัง

เพราะ output ที่มนุษย์อ่านแล้ว “ก็โอเคนี่” อาจเป็น output ที่ระบบ parse ไม่ผ่าน

2) ทำไมเรื่องนี้สำคัญกับธุรกิจ

หลายธุรกิจเริ่มสนใจ local LLM เพราะเหตุผลที่เข้าใจได้ครับ

• อยากคุมข้อมูลเอง
• อยากลดต้นทุนต่อ token
• อยากรันงานบางอย่างใกล้ระบบภายใน
• อยากเลือก open-weight model ตาม use case
• อยากมี fallback ถ้า provider หลักล่มหรือแพงเกินไป

แต่พอขยับจาก chat demo ไปเป็น agent workflow จริง ปัญหาจะเปลี่ยนทันที

คำถามไม่ได้มีแค่ “โมเดลตอบดีไหม”

คำถามจะกลายเป็น:

1. output เป็น JSON ที่ parse ได้ทุกครั้งไหม
2. field สำคัญหายไปไหม
3. type ตรง schema ไหม
4. string มี delimiter หรือ newline ที่ทำให้ parser งงไหม
5. ถ้า model ใส่คำอธิบายเกินมา ระบบจะทำอย่างไร
6. ถ้า parser fail จะ retry, ask human หรือหยุด workflow
7. log เก็บพอให้ debug ได้ไหม

นี่คือจุดที่ผมมองว่า release เล็กของ llama.cpp รอบนี้มีประโยชน์ต่อการคิดเชิงระบบ

มันเตือนเราว่า production agent ไม่ได้อยู่แค่ใน model layer แต่อยู่ตรง boundary ระหว่าง model output กับ software system ด้วย

3) Structured Output Gate คืออะไร

Structured Output Gate คือด่านตรวจระหว่างคำตอบของ AI กับระบบปลายทาง

หน้าที่ของมันคือไม่ให้ output ที่ “ดูเหมือนถูก” ผ่านเข้าไปทำงานจริง จนกว่าจะพิสูจน์ได้ว่า format, schema, type, constraint และ business rule ผ่านขั้นต่ำที่กำหนด

คิดเหมือนพนักงานใหม่ที่กรอกแบบฟอร์มให้เราเร็วมาก

ถ้าแบบฟอร์มนั้นจะเข้า accounting system เราคงไม่บอกว่า “อ่านแล้วน่าจะถูก ส่งเลย”

เราต้องเช็กว่าเลขครบ ช่องครบ format ถูก และถ้าไม่ครบต้องส่งกลับไปแก้ หรือให้คนตรวจ

AI Agent ก็เหมือนกันครับ

โดยเฉพาะ agent ที่ทำงานกับ local/open-weight model เพราะเรามักเอาไปใช้ในงานที่อยากคุมข้อมูลและต้นทุน แต่ยิ่งคุมเองมากขึ้น เราก็ต้องคุม quality gate เองมากขึ้นด้วย

4) ตัวอย่างในงานจริง

สมมติธุรกิจใช้ local LLM ช่วยแยกอีเมลลูกค้าแล้วส่งต่อเข้า CRM

ระบบคาดหวัง JSON แบบนี้:

{
  "customer_name": "string",
  "intent": "support|sales|billing",
  "urgency": "low|medium|high",
  "summary": "string",
  "next_action": "string"
}

ถ้า AI ตอบกลับมาแบบนี้ มนุษย์อาจอ่านรู้เรื่อง:

ลูกค้าชื่อคุณบี ต้องการสอบถามเรื่องใบแจ้งหนี้ น่าจะ urgency high

แต่นี่ไม่ใช่ JSON ที่ระบบกินต่อได้

หรือถ้า AI ตอบเป็น JSON แต่มี comma เกิน, field หาย, newline แปลก, type ผิด หรือมีคำอธิบายแทรกก่อน { ระบบปลายทางก็อาจ fail

ปัญหาคือ fail แบบนี้บางทีไม่ได้เกิดทุกครั้ง

มันเกิดเฉพาะบาง prompt, บางภาษา, บาง delimiter, บาง context ยาว ๆ หรือบาง model version

นี่แหละครับที่ทำให้ parser test และ grammar behavior สำคัญมาก

5) อย่าดูแค่ model benchmark

เวลาเลือก local/open-weight model หลายทีมชอบดู benchmark ก่อน

ผมไม่ได้บอกว่า benchmark ไม่สำคัญนะครับ

แต่ถ้า use case ของเราคือ agent ที่ต้องส่งข้อมูลเข้า software system ผมจะให้คะแนนเรื่องเหล่านี้ด้วย:

• structured output reliability
• JSON/schema adherence
• function/tool call consistency
• retry behavior
• latency under constrained decoding
• observability เมื่อ parse fail
• ability to run deterministic regression tests

เพราะ agent ที่ตอบเก่งแต่ส่ง JSON พัง 5% อาจสร้างต้นทุน manual review สูงกว่า agent ที่คะแนน benchmark ต่ำกว่าเล็กน้อย แต่ output นิ่งกว่าใน workflow จริง

Operator Kit: Structured Output Gate Checklist

ถ้าทีมของคุณจะใช้ local LLM หรือ open-weight model กับ agent workflow จริง ลองใช้ checklist นี้ก่อนเปิดให้แตะระบบ production ครับ

A) Contract: นิยาม output ให้ชัด

1. เขียน JSON Schema หรือ Pydantic model สำหรับ output สำคัญทุกประเภท
2. ระบุ required fields, enum, type, min/max length และ nullable ให้ชัด
3. หลีกเลี่ยง field ที่ตีความกว้างเกินไป เช่น data, result, note โดยไม่มี constraint
4. แยก output สำหรับคนอ่านกับ output สำหรับเครื่องอ่านออกจากกัน

B) Parser: อย่าเชื่อ text ที่ดูถูก

1. ให้ระบบ parse output จริง ไม่ใช่ใช้สายตาอ่าน
2. reject ทันทีถ้ามี text นอก JSON block ในงานที่ต้อง machine-readable
3. ทดสอบ whitespace, newline, delimiter, quote, comma และ Unicode edge cases
4. เก็บ raw output และ parse error แบบไม่เปิดเผยข้อมูลลับ เพื่อใช้ debug

C) Test: มี regression ก่อนเชื่อ

1. สร้าง test set จาก prompt จริงที่เคยพัง ไม่ใช่ prompt สวย ๆ อย่างเดียว
2. ทดสอบกับข้อมูลภาษาไทยและ Thai-English mixed text
3. ทดสอบ context ยาว, input สั้นมาก, input คลุมเครือ และ input ที่มี delimiter แปลก ๆ
4. pin runtime/model version เวลาทำ baseline เพื่อรู้ว่าอะไรเปลี่ยนหลัง upgrade

D) Fallback: fail แล้วต้องรู้ทางไป

1. ถ้า parse fail ครั้งแรก ให้ retry ด้วย prompt ที่สั้นและเข้มขึ้น
2. ถ้ายัง fail ให้ส่งเข้า human review แทนการเดาเติม field เอง
3. ถ้า field สำคัญขาด ให้ถามกลับหรือ mark incomplete ไม่ใช่ fabricate
4. ถ้า output จะไปแตะเงิน ลูกค้า สัญญา หรือข้อมูลส่วนบุคคล ต้องมี approval gate

E) Observability: เห็นปัญหาก่อนลูกค้าเห็น

1. วัด parse success rate แยกตาม model, version, task และ language
2. alert ถ้า parse failure เพิ่มหลังอัปเกรด runtime หรือเปลี่ยน prompt
3. เก็บ sample ที่ sanitize แล้วสำหรับ regression รอบต่อไป
4. มี kill switch เพื่อหยุด agent path ที่ส่ง output ผิดซ้ำ ๆ

6) บทเรียนสำหรับทีมไทย

สำหรับธุรกิจไทย ผมมองว่า local/open-weight LLM น่าสนใจมาก โดยเฉพาะงานที่เกี่ยวกับเอกสารภายใน ความรู้บริษัท หรือ workflow ที่ต้องคุมต้นทุน

แต่การคุมเองไม่ได้แปลว่าปลอดภัยเอง

ถ้าใช้ cloud API บางเจ้าจะมี structured output helper, tool calling format, validator หรือ SDK ที่ช่วยบางส่วน

พอเรามาอยู่ในโลก local runtime เราได้อิสระมากขึ้น แต่ก็ต้องสร้าง discipline เองมากขึ้นด้วย

อย่าเริ่มจาก “เอาโมเดลนี้มาแทนทุกอย่าง”

เริ่มจาก workflow เล็ก ๆ ที่มี input/output ชัด เช่น:

• classify ticket
• extract invoice fields
• summarize support case
• convert meeting note เป็น task list
• map lead intent เข้า CRM

แล้ววัดก่อนว่า structured output ผ่านกี่เปอร์เซ็นต์

ถ้ายังไม่ถึงระดับที่ไว้ใจได้ อย่าเพิ่งให้ agent เขียนเข้าระบบจริงโดยตรง

7) สรุป

ในความเห็นของผม llama.cpp b9743 เป็นข่าวเล็กที่ให้บทเรียนใหญ่ครับ

มันไม่ได้บอกว่า local LLM พร้อมหรือไม่พร้อม

แต่มันเตือนว่า ถ้าเราจะเอา local/open-weight model ไปทำงานแบบ agent จริง จุดที่ต้องใส่ใจคือ boundary ระหว่างภาษาและระบบ

AI อาจตอบเป็นภาษาคนได้ดีมาก

แต่ธุรกิจไม่ได้รันด้วยคำตอบที่ “น่าจะถูก” อย่างเดียว

ธุรกิจรันด้วย format ที่ parse ได้, rule ที่ตรวจได้, log ที่ตามย้อนกลับได้ และ approval ที่หยุดความผิดพลาดก่อนถึงลูกค้า

สุดท้าย agent ที่ดีไม่ใช่แค่ฉลาดครับ

แต่ต้องส่งงานในรูปแบบที่ระบบปลายทางเชื่อถือได้ด้วย