ประโยค “ลองใช้ AI แล้ว ออกมาไม่ดีเลย” ส่วนใหญ่ไม่ได้บอกคุณภาพของปัญญาประดิษฐ์โดยรวม แต่บอกถึงการใช้งานระบบหนึ่งที่ไม่สำเร็จเพียงครั้งเดียว ในตอนนั้นคำว่า “AI” อาจหมายถึงผู้ให้บริการ โมเดล เครื่องมือ โหมดการคิด และชุดข้อมูลที่ต่างกันได้ทั้งหมด พอชั้นใดชั้นหนึ่งเปลี่ยน คำขอเดิมก็เริ่มให้ผลต่างไป
มองให้เป็นห่วงโซ่ของเงื่อนไขจะง่ายกว่ามองเป็นปุ่มเดียว คำตอบเกิดขึ้นตรงจุดที่แพลตฟอร์มทางเทคนิค บริบทที่มีให้ และความชัดเจนของโจทย์มาบรรจบกัน ข้างล่างนี้คือตัวแปรเจ็ดตัวที่คนมักเหมาว่าเป็นเรื่องเดียวกัน
1. ผู้ให้บริการ
OpenAI, Anthropic, Google, DeepSeek และบริษัทอื่นๆ ไม่ได้ขาย “AI ตัวเดียวกันแค่เปลี่ยนโลโก้” ผู้ให้บริการแต่ละรายมีงานวิจัย ข้อมูลที่ใช้ฝึก วิธีปรับแต่งโมเดล และข้อจำกัดของผลิตภัณฑ์เป็นของตัวเอง
ในทางปฏิบัติจึงเห็นจุดแข็งที่ต่างกัน บริการหนึ่งเขียนโค้ดได้สะดวกกว่า อีกบริการจับเอกสารยาวๆ ได้ดีกว่า บริการที่สามทำงานกับรูปภาพได้มั่นใจกว่า บริการที่สี่เน้นความเร็วและราคาถูก นอกจากนี้ผู้ให้บริการยังเป็นคนกำหนดเครื่องมือที่ใช้ได้ ลิมิต รูปแบบ API และกฎของระบบบางส่วนที่ผู้ใช้อาจมองไม่เห็นด้วยซ้ำ
การสรุปว่า “AI ตัวนี้แย่” จึงกว้างเกินไป เหมือนตัดสินอาหารทั้งโลกจากจานเดียวที่กินในสนามบิน ผลที่ได้อาจเป็นเรื่องจริง แต่ข้อสรุปครอบคลุมสิ่งที่ใหญ่เกินไป
2. โมเดลที่ใช้จริง
การเลือกผู้ให้บริการยังไม่ได้กำหนดผลลัพธ์ ในบริการเดียวกันมักมีหลายโมเดล ทั้งรุ่นเร็วและประหยัด รุ่นที่แรงกว่าสำหรับงานยาก และรุ่นเฉพาะทางสำหรับโค้ด รูปภาพ หรืองานที่ใช้บริบทขนาดใหญ่
ของ Anthropic คือไลน์ Opus, Sonnet และ Haiku ของ OpenAI คือ GPT และ Codex รุ่นใหญ่กับรุ่น mini ของ Google คือ Pro และ Flash ชื่อไม่ได้สำคัญในตัวเอง แต่โมเดลแต่ละตัวต่างกันที่ว่าจับเงื่อนไขได้กี่ข้อ ทำตามคำแนะนำได้แค่ไหน ตรวจข้อสรุปของตัวเองลึกแค่ไหน และพลาดบ่อยแค่ไหนเมื่อต้องทำงานหลายขั้นต่อกันยาวๆ
คำขอแบบเดียวกันอาจเหมาะกับโมเดลเร็ว แต่กว้างเกินไปสำหรับงานวิศวกรรมที่ซับซ้อน กลับกันก็เกิดได้ โมเดลตัวแรงเสียเวลาและลิมิตไปกับงานที่แก้ด้วยวิธีที่ง่ายกว่านี้ก็ได้ การเทียบคำตอบจึงมีความหมายก็ต่อเมื่อล็อกโมเดล เวอร์ชัน และการตั้งค่าไว้ ไม่อย่างนั้นเงื่อนไขของการทดลองจะเปลี่ยนหลายอย่างพร้อมกัน
3. Harness รอบโมเดล
โมเดลแทบไม่เคยทำงานในสุญญากาศจริงๆ ข้างบนมันยังมี harness ซึ่งเป็นสภาพแวดล้อมการทำงานที่เชื่อมโมเดลเข้ากับอินเทอร์เฟซ ไฟล์ เครื่องมือ และกฎต่างๆ ตัวอย่างของชั้นนี้คือ Claude Code, Codex, OpenCode, Cursor และสภาพแวดล้อมอื่นๆ
Harness เป็นตัวตัดสินว่าโมเดลจะเห็นอะไรและทำอะไรได้บ้าง:
- ไฟล์และข้อความไหนจะเข้าไปอยู่ในบริบท
- โมเดลได้รับอนุญาตให้ใช้คำสั่งไหน API ไหน และบริการภายนอกอะไรบ้าง
- โมเดลแก้ไฟล์ได้ หรือทำได้แค่เสนอข้อความ
- โมเดลต้องรันการตรวจสอบเองหรือไม่
- หน่วยความจำ ประวัติ และการทำซ้ำขั้นตอนทำงานอย่างไร
- มีคำแนะนำของระบบอะไรถูกเติมเข้าไปในคำขอบ้าง
โมเดลตัวเดียวกันในแชทเปล่าๆ กับในสภาพแวดล้อมแบบเอเจนต์จึงเป็นการตั้งค่าการทำงานสองแบบที่ต่างกัน ในแชท มันมักตอบจากข้อความเดียว แต่ใน harness มันสำรวจรีโพ เรียกเครื่องมือ เห็นข้อผิดพลาด แก้วิธีทำ แล้วตรวจซ้ำได้อีกรอบ คุณภาพตรงนี้จึงไม่ได้ขึ้นกับ “ความฉลาด” ของโมเดลอย่างเดียว แต่ขึ้นกับคุณภาพของกระบวนการรอบตัวมันด้วย
4. Effort และ thinking
บางโมเดลให้เลือกระดับความพยายามได้ คือ low, medium, high, max ในผลิตภัณฑ์อื่นการตั้งค่าแบบเดียวกันนี้เรียกว่า reasoning หรือ thinking มันมีผลต่อปริมาณการคำนวณที่ระบบยอมใช้ก่อนจะสร้างคำตอบ
ถ้าตั้งระดับต่ำ โมเดลจะเดินตามทางที่เห็นชัดได้เร็วกว่า แต่อาจไม่ทันสังเกตความขัดแย้ง กรณีขอบ หรือข้อจำกัดที่ซ่อนอยู่ ถ้าตั้งระดับสูง มันจะมีเวลามากขึ้นในการแยกแยะเงื่อนไข เทียบสมมติฐาน และตรวจทานตัวเอง เห็นชัดมากในการเขียนโปรแกรม การวิเคราะห์เอกสาร และงานที่ต้องทำหลายขั้นที่ขึ้นต่อกัน
Effort สูงไม่ได้เปลี่ยนโจทย์ที่ตั้งผิดให้กลายเป็นโจทย์ที่ถูก ถ้าให้ข้อมูลผิดชุด หรือไม่ได้อธิบายเกณฑ์การตรวจรับผลงาน การคำนวณที่เพิ่มขึ้นก็แค่ช่วยให้แก้โจทย์ผิดข้อได้ละเอียดขึ้น การตั้งระดับความพยายามเป็นพารามิเตอร์หนึ่งของระบบ ไม่ใช่ปุ่มวิเศษ “ทำให้ดีขึ้น”
5. บริบท
บริบทไม่ใช่แค่ปริมาณข้อความในหน้าต่าง แต่รวมถึงไฟล์ การตัดสินใจก่อนหน้า ข้อจำกัด ตัวอย่าง คำนิยามศัพท์ และเกณฑ์ของผลลัพธ์ ไม่ใช่แค่ต้องมีข้อมูลเหล่านี้ แต่ข้อมูลยังต้องเป็นปัจจุบันด้วย เอกสารเก่าหรือกฎที่ขัดกันเองพาคำตอบไปผิดทางได้
ในโปรเจกต์ เอกสารสำหรับเอเจนต์ก็กลายเป็นบริบทด้วย ได้แก่ AGENTS.md, CLAUDE.md, GEMINI.md ลิงก์ที่อยู่ในไฟล์เหล่านั้น สกิล และคอนเน็กเตอร์ที่ใช้ได้ ถ้ากฎสำคัญข้อหนึ่งไม่ได้อยู่ในคำขอ โมเดลก็ไม่รู้ว่าต้องคำนึงถึงมัน และจะเติมช่องว่างด้วยการเดาที่น่าจะเป็นที่สุด
Good context engineering means finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome.
ข้อสรุปจึงง่ายมาก บริบทที่ดีที่สุดไม่จำเป็นต้องยาวที่สุด ไฟล์ที่เกินมาสร้างเสียงรบกวน ส่วนแหล่งข้อมูลที่แม่นยำชุดสั้นๆ ช่วยให้จับสิ่งสำคัญไว้ได้ คือเป้าหมาย ขอบเขต และสัญญาณว่างานเสร็จแล้ว
6. การตั้งโจทย์
โมเดลกำหนดเองไม่ได้ว่า “ดีพอ” หมายถึงอะไร สำหรับคนหนึ่งคือข้อความสั้นๆ สำหรับอีกคนคือการวิเคราะห์ละเอียดพร้อมแหล่งอ้างอิง สำหรับคนที่สามคือไฟล์ที่เสร็จพร้อมใช้และผ่านการตรวจสอบเฉพาะอย่างหนึ่ง
โจทย์ที่ใช้งานได้ต้องแยกหลายเรื่องออกจากกัน คือเป้าหมาย ข้อมูลตั้งต้น ข้อจำกัด รูปแบบคำตอบ เกณฑ์คุณภาพ และข้อห้าม ถ้าลำดับการทำงานสำคัญก็ควรระบุด้วย เช่น ศึกษาเนื้อหาก่อน แล้ววางแผน จากนั้นจึงแก้ไข และตรวจผลที่มองเห็นได้
ความต่างระหว่างคำขอกว้างๆ กับคำขอที่ชัดเจนมีหน้าตาแบบนี้:
ทำให้ดีๆ หน่อยและ:
เขียนบทนำใหม่ให้เหลือ 2–3 ย่อหน้า คงใจความของบทความไว้ ตัดประโยคที่ผู้เขียนพูดกับผู้อ่านออก
ห้ามเพิ่มข้อเท็จจริงที่ไม่ได้รับการยืนยัน และตรวจว่าข้อความสุดท้ายบิลด์ผ่านแบบที่สองเหลือช่องให้ตีความแบบสุ่มน้อยกว่า โมเดลไม่ได้รับแค่หัวข้อ แต่ได้นิยามที่ใช้งานได้จริงว่าผลลัพธ์ที่ดีเป็นอย่างไร
7. โหลดของระบบและพลังคำนวณที่มีให้
คำตอบยังขึ้นกับโครงสร้างพื้นฐานที่บริการทำงานอยู่ด้วย ระบบมีคิว ลิมิต ข้อจำกัดของบริบท ต้นทุนการคำนวณ และการกระจายคำขอภายใน เวลาที่ผลิตภัณฑ์อัปเดตหรือโหลดสูง บริการอาจเปลี่ยนโหมดที่เปิดให้ใช้ เลือกเส้นทางประมวลผลอื่น หรือส่งผลลัพธ์ที่คิดมาตื้นกว่าเดิม
ไม่ใช่ทุกการเปลี่ยนแปลงแบบนี้ที่ผู้ใช้มองเห็น บางครั้งเปลี่ยนหน้าจอหรือโมเดลเริ่มต้น บางครั้งเปลี่ยนแค่พฤติกรรมตอนใกล้ชนลิมิต คำขอเดียวกันในเวลาต่างกันจึงอาจได้คำตอบที่ไม่เหมือนกันเป๊ะ แม้การตั้งค่าที่เห็นจากภายนอกจะเหมือนเดิม
นี่ไม่ใช่คำอธิบายสำหรับทุกความผิดพลาด และไม่ใช่ข้ออ้างให้โทษ “เซิร์ฟเวอร์” ไปหมด โหลดเป็นแค่ตัวแปรเพิ่มอีกตัวที่ต้องคิดถึงเมื่ออยากได้ผลที่ทำซ้ำได้ ในกรณีนั้นให้บันทึกคำขอ โมเดล โหมด บริบท วันที่ และผลลัพธ์ที่ได้เก็บไว้
หาสาเหตุของผลลัพธ์ที่ไม่ดียังไง
คำตอบที่ไม่ดีเพียงครั้งเดียวไม่ได้บอกว่าชั้นไหนเป็นตัวปัญหา การวินิจฉัยต้องเปลี่ยนทีละตัวแปรและล็อกตัวอื่นไว้:
- ผู้ให้บริการ
- โมเดลที่ใช้และเวอร์ชันของมัน
- harness เครื่องมือที่ใช้ได้ และคำแนะนำของระบบ
effortและโหมดthinking- องค์ประกอบของบริบทและความเป็นปัจจุบันของมัน
- ถ้อยคำของโจทย์และเกณฑ์คุณภาพ
- ช่วงเวลา ลิมิต และโหลดของบริการที่อาจเกิดขึ้น
หลังตรวจแบบนี้ “AI ทำออกมาไม่ดี” จะเปลี่ยนจากความรู้สึกรวมๆ เป็นสมมติฐานที่ตรวจสอบได้ และจะเห็นชัดว่าต้องเปลี่ยนอะไร: ตัวโมเดล สภาพแวดล้อมการทำงาน บริบท หรือการตั้งโจทย์
สองชั้นจากรายการนี้มีบทความแยกให้อ่าน คือ prompt engineering ตามแนวทางของ OpenAI และ Anthropic และ context engineering
