AI SDK แก้บั๊ก thinking: disabled: บทเรียนง่าย ๆ เรื่องตั้งค่าโมเดลต้องมีหลักฐาน

ข่าวนี้เป็นข่าวเล็กใน GitHub release แต่บทเรียนสำหรับทีมที่ใช้ AI agent ไม่เล็กเลยครับ

Vercel ออกแพตช์ @ai-sdk/[email protected] เพื่อแก้พฤติกรรมที่ providerOptions.anthropic.thinking = { type: 'disabled' } เคยถูก schema รับไว้ได้ แต่ไม่ได้ถูกส่งต่อไปยัง Anthropic Messages API จริง ผลคือสำหรับโมเดลที่เปิด thinking เป็นค่าเริ่มต้น ระบบอาจยังใช้ thinking อยู่ และอาจกิน max_tokens budget จนงานตอบไม่ครบหรือช้ากว่าที่คิด

แปลเป็นภาษาคนทำงาน: เราไม่ได้มีปัญหาเพราะ “AI ฉลาดไม่พอ” เสมอไป หลายครั้งปัญหาอยู่ที่ plumbing ระหว่าง app, SDK, provider option, middleware และ API จริง

So what: ทำไม founder/operator/ทีมเล็กควรสนใจ

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

หนึ่ง ต้นทุนต่อ request อาจสูงกว่าที่คิด เพราะ reasoning หรือ thinking ถูกเปิดอยู่โดยไม่ตั้งใจ

สอง งานที่มี output budget จำกัดอาจตอบไม่ครบ เพราะ budget ถูกใช้ไปกับส่วนที่ผู้ใช้ไม่ได้เห็น

สาม ทีมอาจ debug ผิดจุด คิดว่า prompt ไม่ดี โมเดลไม่ดี หรือ agent ทำงานช้า ทั้งที่จริงคือ option ไม่ได้ถูกส่งไปถึง provider ตามที่คาด

ประเด็นสำคัญไม่ใช่ว่าทุกคนต้องปิด thinking เสมอไป แต่คือถ้าเราตั้งใจเปิดหรือปิดอะไร เราต้องมีหลักฐานว่าค่านั้นไปถึง API จริง

How to use: วิธีเอาไปใช้จริง

1. แยก config intent กับ payload truth

ในโค้ดเราอาจมี intent เช่น “งานนี้ใช้ thinking ต่ำ”, “งานนี้ปิด thinking”, “งานนี้จำกัด token” แต่สิ่งที่ต้องตรวจคือ payload ที่ออกจากระบบจริงหลังผ่าน SDK, middleware, wrapper และ provider registry แล้ว

ให้ทีมตั้งคำถามง่าย ๆ ว่า request สุดท้ายที่ส่งออกไปมี field สำคัญครบไหม และค่าไม่ถูก override ระหว่างทางใช่ไหม

2. ทำ test ให้ setting ที่กระทบเงินและเวลา

ไม่ต้อง test ทุก option เท่ากันหมด ให้เริ่มจาก option ที่มีผลต่อ cost, latency, output length, tool use และ safety behavior

ตัวอย่างในข่าวนี้คือ thinking: { type: 'disabled' } กับ max_tokens เพราะถ้าพฤติกรรมไม่ตรง อาจทำให้งานสั้นกลายเป็นงานแพง หรือคำตอบที่ควรครบกลายเป็นถูกตัดกลางทาง

3. เก็บ log แบบเห็นโครง payload แต่ไม่เปิดข้อมูลลูกค้า

ทีมเล็กไม่จำเป็นต้องทำ observability ใหญ่โตทันที แต่ควรมี safe debug log ที่เห็นว่า provider option สำคัญถูกส่งออกจริง

อย่า log prompt ลูกค้าเต็ม ๆ โดยไม่จำเป็น ให้ mask หรือแยกเฉพาะ metadata เช่น provider, model, max_tokens, thinking mode, tool count และ request id

4. หลังอัปเดต SDK ให้ลองงานเล็กก่อนงานยาว

แพตช์ระดับ provider อาจกระทบ behavior ของงานจริง ให้มี smoke test สั้น ๆ เช่น request ที่ตั้ง token budget ต่ำ แล้วเช็กว่าผลลัพธ์ไม่ถูก thinking แย่ง budget ตามคาด

ถ้าทีมใช้ agent ที่ทำงานยาว เช่น สรุปลูกค้า ตรวจ ticket หรือแก้โค้ดหลายไฟล์ อย่าเพิ่งปล่อยงาน batch ใหญ่ทันทีหลังอัปเดต provider package

5. เขียน runbook ให้คนไม่ใช่ dev ก็เช็กอาการได้

อาการแบบนี้ไม่ได้เจอเฉพาะ engineer ทีม support, ops หรือ founder เองอาจเห็นแค่ “AI ตอบสั้นผิดปกติ”, “ค่าใช้จ่ายขึ้น”, “งานช้ากว่าเดิม”

ควรมี runbook สั้น ๆ ว่าเมื่อเจออาการเหล่านี้ ให้เช็กอะไรบ้างก่อนโยนว่าเป็นปัญหา prompt

Operator Kit: Payload Proof Checklist

ใช้ checklist นี้กับ AI workflow ที่เริ่มมี provider options, SDK wrapper หรือ agent หลายชั้น

A. ก่อนปล่อย workflow ใหม่

• ระบุ option ที่กระทบเงิน เวลา และความยาวคำตอบ เช่น max_tokens, reasoning/thinking, temperature, tool choice, timeout
• เขียนตัวอย่าง request ที่คาดว่าจะถูกส่งไป provider
• มี test หรือ debug mode ที่ยืนยัน field สำคัญใน payload สุดท้าย
• เช็กว่า middleware หรือ wrapper ไม่มี default ที่ override ค่าของเราโดยไม่รู้ตัว
• เก็บ request id เพื่อไล่ย้อนจาก user symptom ไปถึง provider call ได้

B. หลังอัปเดต SDK หรือ provider package

• อ่าน changelog เฉพาะ provider ที่ใช้งานจริง
• รัน smoke test กับงานสั้นหนึ่งชุด งานยาวหนึ่งชุด และงานที่จำกัด token หนึ่งชุด
• เทียบ latency, output length และ token usage ก่อนกับหลังอัปเดต
• ถ้ามี agent ทำงานอัตโนมัติ ให้เริ่มจาก dry-run หรือกลุ่มงานเล็กก่อน
• จดสิ่งที่เปลี่ยนไว้ใน runbook เพื่อให้คนอื่น debug ต่อได้

C. เมื่อเจออาการผิดปกติ

• อย่าเริ่มจากการแก้ prompt ทันที
• เช็กว่า model และ provider ที่เรียกจริงตรงกับที่คิดไหม
• เช็กว่า option สำคัญถูกส่งจริงไหม
• เช็กว่า output ถูกตัดเพราะ budget หรือ timeout ไหม
• ถ้าใช้หลาย provider ให้แยก test ทีละ provider เพื่อไม่ให้สรุปผิด

Caveat: ไม่ใช่ทุกงานควรปิด thinking

บางงานต้องการ reasoning มาก เช่น วิเคราะห์โค้ดหลายไฟล์ สรุปเอกสารซับซ้อน หรือวางแผนงานหลายขั้น การเปิด thinking หรือใช้ effort สูงอาจคุ้มกว่า

แต่ทีมควรเลือกอย่างรู้ตัว ไม่ใช่ปล่อยให้ default หรือ bug ในชั้น SDK ตัดสินแทน

อีกอย่างคือพฤติกรรม thinking ของแต่ละโมเดลและแต่ละ provider ไม่เหมือนกัน บางโมเดลใช้ adaptive thinking บางโมเดลรองรับ budget แบบ manual บางโมเดลไม่รองรับ disabled ในรูปแบบเดียวกัน ดังนั้นให้ยึดเอกสาร provider และ changelog ของ SDK ที่ใช้อยู่จริง

เริ่มลองวันนี้

ถ้าคุณมี AI workflow อยู่แล้ว ให้เลือกหนึ่ง workflow ที่มีค่าใช้จ่ายหรือ latency เริ่มสูง แล้วทำ payload proof ภายใน 30 นาที

ไม่ต้องสร้างระบบใหญ่ แค่พิสูจน์ให้ได้ว่า setting ที่คิดว่าส่ง ได้ถูกส่งไปจริง และเมื่อเปลี่ยน setting ผลลัพธ์ที่เห็นเปลี่ยนตามจริง

นี่คือวิธีคิดที่ Data-Espresso ชอบใช้กับ AI news ครับ ไม่ใช่จำชื่อแพตช์ให้หมด แต่แปลงข่าวเล็ก ๆ ให้กลายเป็นนิสัยการทำงานที่ทีมเอาไปใช้ได้จริง

ถ้าคุณอยากให้ทีมเริ่มใช้ AI แบบเป็น workflow ไม่ใช่แค่ลอง prompt ไปเรื่อย ๆ Data-Espresso และ OPB Stack ช่วยออกแบบ sandbox, runbook, checklist และระบบทดลองที่วัดผลได้ทีละขั้นได้ครับ