ผมเห็นบิลมูลค่า $200 ปรากฏขึ้นบนบัญชี AWS ในชั่วข้ามคืน
ไม่ใช่เพราะระบบล่ม
เอเยนต์ตัวหนึ่งทำงานวน loop เป็นเวลาหกชั่วโมงโดยไม่มีเงื่อนไขหยุด เรียกใช้ OpenAI API ทุกครั้งที่วนซ้ำ
แดชบอร์ด monitoring ทุกตัวรายงานว่าทุกอย่างปกติ
ไม่มีใครสังเกตจนกระทั่งใบแจ้งหนี้มาถึงในตอนเช้า
นั่นคือสิ่งที่เกิดขึ้นเมื่อคุณสร้างระบบ AI โดยไม่เข้าใจว่ามันทำงานจริงๆ อย่างไร
คนส่วนใหญ่เรียนรู้วิศวกรรม AI แบบย้อนกลับ
ติดตั้ง library ทำตาม tutorial เรียกใช้ API ได้อะไรบางอย่างที่ทำงานได้ รู้สึกเหมือนกำลังพัฒนา
แล้วจู่ๆ บางอย่างก็พังในแบบที่ไม่มีเหตุผล
พวกเขาเปลี่ยนตัวเลขแบบสุ่มจนกว่ามันจะหยุด
นั่นไม่ใช่วิศวกรรม นั่นคือความหวังที่มาพร้อมกับคีย์บอร์ด
นี่คือ 6 แนวคิดที่จะแก้ปัญหานี้
ประโยคเดียวที่อธิบายทุกอย่าง
ระบบ AI ทุกระบบ ไม่ว่าจะซับซ้อนแค่ไหน ก็เป็นเพียงแค่:
ความจำ (RAG) + การคิด (LLM + โทเคน) + การกระทำ (เอเยนต์) + การวัดผล (Evals)
…ประกอบขึ้นผ่าน วิศวกรรมบริบท (Context Engineering)
นั่นคือทั้งวงการ
ทุกอย่างด้านล่างนี้เป็นเพียงการแกะว่าส่วนแต่ละส่วนหมายถึงอะไรจริงๆ
1. โทเคนและหน้าต่างบริบท (Context Window)
LLM ไม่ได้อ่านคำ พวกมันอ่านชิ้นส่วนที่เรียกว่าโทเคน
"engineering" → 1 โทเคน
"unbelievable" → 2 โทเคน ช่องว่างและเครื่องหมายวรรคตอนก็นับด้วย
ทุกโมเดลมีหน้าต่างบริบท — ขีดจำกัดตายตัวของโทเคนที่สามารถเก็บได้ในครั้งเดียว
→ Claude: 200,000 โทเคน
→ GPT-5: 400,000 โทเคน
ลองนึกภาพว่ามันคือไวท์บอร์ดในห้องประชุม
โมเดลจะทำงานกับสิ่งที่อยู่บนบอร์ดในขณะนั้นเท่านั้น
เมื่อบอร์ดเต็ม โน้ตเก่าจะถูกลบเพื่อให้มีที่ว่าง
โมเดลไม่ได้สูญเสียความสามารถในการคิด
แต่มันสูญเสียการเข้าถึงข้อมูลก่อนหน้านี้
ทำไมสิ่งนี้ถึงทำให้ระบบ production พัง:
→ โทเคนมีค่าใช้จ่าย — ทุกการเรียก API จะคิดเงินตามจำนวนโทเคน input และ output
→ ประวัติแชทยาวๆ จะทำให้หน้าต่างเต็มเร็ว
→ เมื่อบริบทเต็ม คำสั่งก่อนหน้านี้จะถูกทิ้งอย่างเงียบๆ
→ สิ่งที่จะเข้าไปในบริบทคือการตัดสินใจทางวิศวกรรม ไม่ใช่ค่าเริ่มต้น
ความล้มเหลวที่พิสูจน์สิ่งนี้:
ทีมหนึ่งสร้างเอเยนต์ support ลูกค้าที่ใช้ประวัติแชททั้ง 12 เดือนเป็นบริบททุกครั้งที่มีการร้องขอ
ทำงานได้ดีเยี่ยมในการทดสอบที่มี 5 การโต้ตอบ
ใน production หลังจาก 50 การโต้ตอบ เอเยนต์เริ่มไม่สนใจ system prompt ของตัวเอง
คำสั่งยังอยู่ตรงนั้น
แต่มันถูกฝังอยู่ใต้โทเคน 80,000 ตัวของประวัติการสนทนา
โมเดลหยุดให้ความสนใจกับมันอย่างมีประสิทธิภาพ
วิธีแก้ไขไม่ใช่การใช้โมเดลที่ดีกว่า
แต่คือการสรุปประวัติเก่าเพื่อให้หน้าต่างยังคงโฟกัสได้
ความจริงที่อึดอัด:
"ความล้มเหลวของ prompt engineering" ส่วนใหญ่จริงๆ แล้วคือความล้มเหลวของโทเคนและหน้าต่างบริบทที่ปลอมตัวมา
วิศวกรโทษ prompt ทั้งที่ปัญหาจริงคือคำสั่งสำคัญอยู่บรรทัดที่ 3 ของบริบทที่มี 500 บรรทัด และโมเดลหยุดให้น้ำหนักกับมัน
2. เอมเบดดิงและการค้นหาเชิงเวกเตอร์ (Vector Search)
เอมเบดดิงเปลี่ยนความหมายให้เป็นตัวเลข ดังนั้น "ความคล้ายคลึง" จึงสามารถคำนวณทางคณิตศาสตร์ได้
ปัญหาที่มันแก้:
คุณมีเอกสาร 50,000 ชิ้น ผู้ใช้ถามคำถาม คุณต้องหา 3 ชิ้นที่เกี่ยวข้องมากที่สุด — โดยไม่ต้องอ่านทั้งหมด 50,000 ชิ้นทุกครั้ง
การค้นหาด้วยคำสำคัญ (keyword search) ล้มเหลวในกรณีนี้
ถ้าเอกสารพูดว่า "automobile" และผู้ใช้ถามเกี่ยวกับ "cars" การค้นหาด้วยคำสำคัญจะพลาด
ไม่ใช่เพราะคำตอบไม่มี แต่เพราะคำไม่ตรงกัน
เอมเบดดิงแก้ปัญหานี้ด้วยวิธีที่ต่างออกไป
โมเดลเอมเบดดิงแปลงข้อความเป็นเวกเตอร์ — รายการตัวเลขที่แสดงความหมายในพื้นที่ทางคณิตศาสตร์
ข้อความที่มีความหมายคล้ายกัน → เวกเตอร์ที่มีตัวเลขใกล้เคียงกัน
"car" และ "automobile" → อยู่ใกล้กัน
"car" และ "photosynthesis" → อยู่ห่างกันมาก
การค้นหาเชิงเวกเตอร์ทำงานอย่างไรจริงๆ:
- ทุกเอกสารถูกแปลงเป็นเวกเตอร์และจัดเก็บ
- คำถามของผู้ใช้ก็กลายเป็นเวกเตอร์เช่นกัน
- ระบบหาเวกเตอร์ที่เก็บไว้ซึ่งใกล้กับเวกเตอร์ของคำถามมากที่สุด
- นั่นคือเอกสารที่เกี่ยวข้องมากที่สุดของคุณ
นี่ไม่ใช่เรื่องมหัศจรรย์โดยประมาณ มันคือเรขาคณิต
ความคล้ายคลึงคือคุณสมบัติทางคณิตศาสตร์จริงๆ ที่คุณสามารถคำนวณได้
สิ่งนี้ปรากฏใน production ที่ไหน:
→ การค้นหาเชิงความหมายในระบบเอกสารใดๆ
→ การหาผลิตภัณฑ์ บทความ โปรไฟล์ผู้ใช้ที่คล้ายกัน
→ ขั้นตอนการดึงข้อมูลใน RAG (แนวคิดถัดไป)
→ ความจำใน AI เอเยนต์
3. RAG (Retrieval-Augmented Generation)
แทนที่จะฝึกโมเดลด้วยข้อมูลของคุณ คุณดึงข้อมูลที่เกี่ยวข้องในเวลาที่สอบถามและป้อนให้โมเดลเป็นบริบท
ปัญหาที่ RAG แก้:
LLM รู้มาก แต่พวกมันไม่รู้ข้อมูลของคุณ
เอกสารภายในบริษัทของคุณ ฐานข้อมูลผลิตภัณฑ์ของคุณ ประวัติการ support ลูกค้าของคุณ
ไม่มีสิ่งเหล่านั้นในชุดฝึกสอน
มีสองทางเลือก: ฝึกโมเดลด้วยข้อมูลของคุณ (แพง ช้า และล้าสมัยทันที) หรือให้ข้อมูลของคุณกับโมเดลในเวลาที่มันต้องการพอดี
RAG คือทางเลือกที่สอง ทำอย่างเป็นระบบ
ไปป์ไลน์ 3 ขั้นตอน:
→ ดึงข้อมูล (RETRIEVE):
คำถามกลายเป็นเวกเตอร์ → ฐานข้อมูลเวกเตอร์หาเอกสารที่เก็บไว้ซึ่งคล้ายกันมากที่สุด → ดึงข้อมูล 3-5 ชิ้นที่ดีที่สุด
→ เพิ่มข้อมูล (AUGMENT):
เอกสารที่ถูกดึงมาถูกเพิ่มเข้าไปในบริบทของโมเดล → prompt กลายเป็น "ใช้บริบทนี้ ตอบคำถามนี้"
→ สร้างคำตอบ (GENERATE):
โมเดลตอบโดยอิงจากข้อมูลจริงของคุณ — ไม่ใช่การสร้างข้อมูลเท็จ (hallucination)
จุดที่ RAG ล้มเหลว:
→ การดึงข้อมูลไม่ดี = คำตอบไม่ดี โมเดลทำงานได้เฉพาะกับสิ่งที่ได้รับมาเท่านั้น
→ การแบ่ง chunk ที่ไม่ดีทำให้คำตอบแยกจากบริบท
→ โมเดลยังสามารถสร้างข้อมูลเท็จได้ถ้าการดึงข้อมูลไม่พบสิ่งที่มีประโยชน์
ความล้มเหลวของ RAG ในโลกจริง:
ทีมหนึ่งสร้างผู้ช่วยความรู้ภายในสำหรับคู่มือทางเทคนิค 500 หน้า
ทำงานได้สมบูรณ์แบบใน demo ใน production คำตอบกลับคลุมเครือและบางครั้งก็ผิด
ปัญหาคือขนาด chunk
พวกเขาแบ่งคู่มือเป็น chunk ขนาด 1,000 โทเคนโดยนับจำนวนตัวอักษรแบบดิบๆ
ตารางถูกแบ่งกลางแถว คำแนะนำทีละขั้นตอนถูกแบ่งกลางขั้นตอน
การดึงข้อมูลกำลังหาพื้นที่กว้างๆ ที่ถูกต้อง — แต่พลาดคำตอบจริง
การลดขนาด chunk ลงครึ่งหนึ่งและเพิ่มพื้นที่ซ้อนทับกันแก้ไขปัญหาได้ 80% ในชั่วข้ามคืน
ความเห็นที่หนักแน่น:
RAG ถูกประเมินค่าสูงเกินไปเมื่อการดึงข้อมูลของคุณไม่ดี
LLM ไม่สามารถแก้ไขการดึงข้อมูลที่ไม่ดีได้ มันทำได้แค่สร้างข้อมูลเท็จรอบๆ
ถ้าคุณเห็นคำตอบที่ผิด ให้หยุดปรับ prompt
เริ่มวัดความแม่นยำในการดึงข้อมูลของคุณ
นั่นคือที่ที่คำตอบอยู่
4. วงรอบของเอเยนต์ (Agentic Loop)
เอเยนต์ทำงานโดยการเลือกการกระทำซ้ำๆ ดำเนินการ สังเกตผลลัพธ์ และตัดสินใจว่าจะทำอะไรต่อไป — จนกว่างานจะเสร็จ
การเรียก LLM ทั่วไปคือการไม่คงสถานะ (stateless) คุณถาม มันตอบ จบ
เอเยนต์คือการคงสถานะ (stateful) มันกระทำ สังเกต ตัดสินใจ ทำซ้ำ
วงรอบในภาษาที่เข้าใจง่าย:
- รับเป้าหมาย
- ตัดสินใจเลือกการกระทำถัดไป
- ดำเนินการ — ค้นหา เขียนโค้ด อ่านไฟล์
- สังเกตผลลัพธ์
- ตัดสินใจเลือกการกระทำถัดไปจากสิ่งที่เรียนรู้
- ทำซ้ำจนกว่าเป้าหมายจะเสร็จสมบูรณ์
- ส่งคืนคำตอบสุดท้าย
เครื่องมือ (tools) คือสิ่งที่ทำให้เอเยนต์มีพลัง
ถ้าไม่มีเครื่องมือ LLM จะตอบได้แค่ข้อความ
เมื่อมีเครื่องมือ มันสามารถค้นหาเว็บ อ่านไฟล์ เขียนโค้ด เรียก API เรียกใช้การกระทำใดๆ ที่คุณกำหนด
สามสิ่งที่มือใหม่มักทำผิด:
→ เอเยนต์ที่ไม่มีเงื่อนไขหยุดจะทำงานตลอดไป คุณต้องกำหนดว่าเมื่อไหร่ควรหยุด — ขีดจำกัดขั้นตอน ขีดจำกัดเวลา หรือเงื่อนไขความสำเร็จ
→ เครื่องมือมากกว่า ≠ ประสิทธิภาพดีกว่า เครื่องมือมากเกินไปทำให้โมเดลสับสนว่าจะใช้อันไหน
→ ข้อผิดพลาดของเครื่องมือต้องจัดการอย่างชัดเจน ความล้มเหลวเงียบๆ จะทำให้เอเยนต์สร้างผลลัพธ์ที่ไร้สาระอย่างมั่นใจ
ความล้มเหลวมูลค่า $200 ในชั่วข้ามคืน อย่างละเอียด:
เอเยนต์ไม่มีจำนวนขั้นตอนสูงสุด เป้าหมายของมันคือค้นคว้าหัวข้อและสรุปผล
เครื่องมือค้นหาเว็บตัวหนึ่งส่งคืนผลลัพธ์ว่างเปล่า
เอเยนต์ไม่รู้วิธีหยุด
มันค้นหาต่อไป ลองใหม่ สรุปผลระหว่างทาง — แต่ละอันกระตุ้นให้เกิดการค้นหาอีกครั้ง
หกชั่วโมงต่อมา: การเรียก LLM 847 ครั้ง ใช้โทเคน 2.1 ล้านตัว สรุปผลที่ดูเหมือนมีเหตุผลแต่วงกลมซ้ำไปมา ใบเรียกเก็บเงิน $200
วิธีแก้ไขคือสามบรรทัด: ตัวนับขั้นตอนสูงสุด ตัวจัดการที่ชัดเจนสำหรับผลลัพธ์ว่างเปล่า และเส้นทาง escalation เมื่อความมั่นใจต่ำ
เอเยนต์ตัวเดียวกันตอนนี้ทำงานเสร็จภายในเฉลี่ยต่ำกว่า 12 การเรียก
ความเห็นที่คุณควรได้ยิน:
เอเยนต์ส่วนใหญ่ล้มเหลวไม่ใช่เพราะโมเดลไม่ดี — แต่เพราะวิศวกรปฏิบัติต่อวงรอบเหมือนมันจัดการตัวเองได้
มันไม่ใช่
ราวกั้น (guardrails) เงื่อนไขหยุด ตัวจัดการข้อผิดพลาด — สร้างไว้ตั้งแต่เริ่มต้น ไม่ใช่เพิ่มทีหลังหลังจากเหตุการณ์แรก
5. การประเมินผล (Evals)
Evals คือวิธีที่คุณรู้ว่าระบบ AI ของคุณทำงานได้จริงหรือไม่ — และการเปลี่ยนแปลงทำให้ดีขึ้นหรือแย่ลง
นี่คือแนวคิดที่ tutorial ส่วนใหญ่ข้ามไปเพราะมันดูไม่น่าสนใจ
มันยังเป็นสิ่งที่แยกวิศวกรที่สร้าง demo ออกจากวิศวกรที่สร้างระบบ production
ปัญหาที่เกิดขึ้นถ้าไม่มี evals:
คุณเปลี่ยน prompt ปรับปรุงตรรกะการดึงข้อมูล สลับไปใช้โมเดลที่ใหม่กว่า
มันดีขึ้นไหม?
คุณไม่รู้ คุณอาจตรวจสอบตัวอย่างสองสามตัวอย่างด้วยตัวเอง — แต่นั่นคือความรู้สึก ไม่ใช่หลักฐาน
Evals จริงๆ แล้วมีลักษณะอย่างไร:
→ ชุดข้อมูลทองคำ (golden dataset): 25-50 input จริงพร้อม output ที่ถูกต้องที่รู้จัก ครอบคลุมกรณีการใช้งานหลักบวกกับกรณีขอบที่ยุ่งยาก 5 กรณี
→ ตัวชี้วัดแบบ binary เมื่อเป็นไปได้:
— ระบบ RAG ดึงเอกสารที่ถูกต้องได้หรือไม่? ใช่/ไม่ใช่
— เอเยนต์ทำงานเสร็จโดยไม่มีข้อผิดพลาดหรือไม่? ใช่/ไม่ใช่
— คำตอบมีข้อมูลที่ต้องการหรือไม่? ใช่/ไม่ใช่
→ คะแนนรวมที่ติดตามเมื่อเวลาผ่านไป:
— ความแม่นยำในการดึงข้อมูล: 89% → เปลี่ยนแปลง → 84% พบการถดถอย
— อัตราการทำงานเสร็จ: 76% → เวอร์ชันเอเยนต์ใหม่ → 81% ยืนยันการปรับปรุง
วงจรการประเมิน:
ปรับใช้ → วัดด้วย evals → หาความล้มเหลว → เพิ่มความล้มเหลวในชุดข้อมูลทองคำ → แก้ไข → เรียก evals อีกครั้ง → เปรียบเทียบคะแนน → ปล่อยก็ต่อเมื่อตัวเลขดีขึ้น
ความจริงที่ตรงไปตรงมา:
"ความ有帮助: 3.7/5" ไม่ได้บอกอะไรที่นำไปปฏิบัติได้
"ดึงเอกสารที่ถูกต้อง: 84% ของเวลา" บอกคุณได้อย่างแม่นยำว่าปัญหาอยู่ที่ไหน และการแก้ไขปรับปรุงดีขึ้นแค่ไหน
ระบบ AI ที่ไม่มี evals ไม่ใช่ผลิตภัณฑ์
มันคือ demo ที่คุณไม่สามารถเปลี่ยนแปลงได้อย่างมั่นใจ
6. วิศวกรรมบริบท (Context Engineering)
ศาสตร์แห่งการตัดสินใจอย่างแม่นยำว่าข้อมูลอะไรจะเข้าไปในหน้าต่างบริบทของโมเดล โครงสร้างของมันเป็นอย่างไร และอะไรที่จะถูกตัดทิ้ง
นี่คือความคิดเห็นที่ทำให้คนไม่สบายใจ:
วิศวกรรมบริบทสำคัญกว่าวิศวกรรม prompt
prompt ธรรมดาในบริบทที่จัดสรรมาอย่างดี ทำงานได้ดีกว่า prompt ที่ยอดเยี่ยมที่ฝังอยู่ในสัญญาณรบกวน — ทุกครั้ง
ทีมส่วนใหญ่ใช้ความพยายามในการปรับแต่ง 80% ไปกับ prompt และแทบไม่สนใจบริบทเลย
ผลลัพธ์สะท้อนสิ่งนั้น
วิธีการแบบ naive ล้มเหลว:
รวมทุกอย่าง ประวัติทั้งหมด เอกสารที่ดึงมาทั้งหมด คำอธิบายเครื่องมือทุกอย่าง system prompt ข้อความผู้ใช้ ทั้งหมด
สิ่งนี้ล้มเหลวด้วยเหตุผลที่สอดคล้องกัน: โมเดลสับสนว่าอะไรสำคัญที่สุด
มีเอฟเฟกต์ที่ได้รับการบันทึกไว้เรียกว่า "lost in the middle" — ข้อมูลที่ถูกฝังลึกในบริบทยาวๆ มีโอกาสน้อยที่จะถูกใช้
วิศวกรรมบริบทจริงๆ แล้วเกี่ยวข้องกับอะไร:
→ การคัดเลือก: เอกสาร ข้อเท็จจริง หรือประวัติใดที่การตัดสินใจนี้ต้องการโดยเฉพาะ?
→ การบีบอัด: ส่วนเก่าของการสนทนาสามารถสรุปเพื่อประหยัดโทเคนได้หรือไม่?
→ การจัดลำดับ: คำสั่งสำคัญควรอยู่ที่จุดเริ่มต้นและจุดสิ้นสุด — ไม่ใช่ตรงกลาง
→ การตัดแต่ง: อะไรที่สามารถเอาออกได้โดยไม่กระทบต่อคุณภาพของ output?
→ โครงสร้าง: หัวข้อ ตัวคั่น ส่วนที่มีป้ายกำกับ ส่งผลต่อความน่าเชื่อถือที่โมเดลใช้ข้อมูล
ตัวอย่างที่ใช้งานได้จริง:
เอเยนต์ทำงานมา 45 นาที มันสะสมประวัติการสนทนา 80,000 โทเคน หน้าต่างของมันคือ 128,000
คุณไม่ต้องการสูญเสียเป้าหมายและข้อจำกัดเดิม แม้ว่าประวัติจะเต็มหน้าต่าง
วิศวกรรมบริบท: บีบอัด output ของเครื่องมือเก่า สรุปการใช้เหตุผลก่อนหน้านี้ ทำให้คำจำกัดความของงานเด่นชัดตลอดเซสชัน
Prompt engineering คือการเขียนคำสั่งที่ดี
วิศวกรรมบริบทคือการสร้างสภาพแวดล้อมที่คำสั่งเหล่านั้นถูกปฏิบัติตามจริงๆ
6 แนวคิดเหล่านี้รวมกันเป็นระบบเดียวอย่างไร
ความจำ → RAG + เอมเบดดิง (สิ่งที่ระบบรู้)
การคิด → LLM + โทเคน + หน้าต่างบริบท (วิธีการใช้เหตุผลกับสิ่งที่รู้)
การกระทำ → วงรอบเอเยนต์ + เครื่องมือ (สิ่งที่มันทำได้ในโลก)
การวัดผล → Evals (วิธีที่คุณรู้ว่ามันทำงาน)
ตัวเชื่อม → วิศวกรรมบริบท (สิ่งที่ตัดสินใจว่าอะไรไหลระหว่างทุกอย่างข้างต้น)
แชทบอทธรรมดาเป็นแค่การคิด
เอเยนต์ support ลูกค้าคือความจำ + การคิด + การกระทำ
ระบบ production ที่เชื่อถือได้เพิ่มการวัดผล
ความซับซ้อนอยู่ที่ว่าชิ้นส่วนต่างๆ เชื่อมต่อกันได้ดีแค่ไหน
การไหลสำหรับคำขอเดียว:
คำถามผู้ใช้
→ วิศวกรรมบริบทตัดสินใจว่าจะรวมอะไร
→ เอมเบดดิงดึงความจำที่เกี่ยวข้อง (RAG)
→ โทเคนกำหนดว่ามีพื้นที่ในหน้าต่างแค่ไหน
→ LLM ใช้เหตุผลเหนือบริบทที่ประกอบขึ้น
→ วงรอบเอเยนต์ตัดสินใจว่าต้องการข้อมูลเพิ่มหรือไม่
→ Evals วัดว่า output ถูกต้องจริงหรือไม่
จะเริ่มต้นที่ไหน
คุณไม่จำเป็นต้องเชี่ยวชาญทั้งหกในครั้งเดียว
→ เริ่มต้นด้วยโทเคนและหน้าต่างบริบท — มันส่งผลต่อทุกอย่างที่คุณสร้าง → เพิ่มเอมเบดดิงเมื่อคุณต้องการการค้นหาเชิงความหมายหรือความจำ
→ เรียนรู้ RAG เมื่อคุณต้องการยึดโมเดลกับข้อมูลของคุณเอง
→ เรียนรู้วงรอบเอเยนต์เมื่อคุณต้องการระบบอัตโนมัติ
→ เพิ่ม evals ก่อนที่คุณจะส่งอะไรขึ้น production
→ ใช้วิศวกรรมบริบทเมื่อทุกอย่างอื่นเริ่มเป็นธรรมชาติ
ลำดับนั้นไม่ได้ถูกกำหนดขึ้นโดยพลการ
แต่ละแนวคิดทำให้แนวคิดถัดไปเรียนรู้ได้ง่ายขึ้น
ข้อสรุปสุดท้ายที่ตรงไปตรงมา
ทีมส่วนใหญ่ที่ประสบปัญหา AI ใน production ไม่ได้ประสบปัญหาเพราะโมเดลผิดหรือ library ผิด
พวกเขาประสบปัญหาเพราะพวกเขาข้ามหนึ่งในหกแนวคิดนี้ไป
เอเยนต์วน loop ตลอดไปเพราะไม่มีใครคิดถึงเงื่อนไขหยุด
คำตอบของ RAG ผิดเพราะไม่มีใครวัดการดึงข้อมูล
prompt หยุดทำงานในเซสชันยาวเพราะไม่มีใครเข้าใจว่าหน้าต่างบริบทเต็มขึ้นมาอย่างไร
สิ่งเหล่านี้ไม่ใช่ปัญหาที่ซับซ้อน
มันเป็นปัญหาพื้นฐาน ที่ถูกแต่งเติมด้วยศัพท์เทคนิค
เครื่องมือเปลี่ยนทุกหกเดือน
หกแนวคิดนี้คือวิธีการทำงานของเครื่องมือ
เรียนรู้แนวคิด แล้วคุณจะไม่มีวันสับสนกับเครื่องมือใหม่อีกเลย
ที่สำคัญกว่า — คุณจะไม่มีวันเสีย $200 ดูเอเยนต์วน loop ผ่านทั้งคืน โดยสงสัยว่ามีอะไรผิดพลาด
ถ้าสิ่งนี้มีประโยชน์:
→ แชร์ต่อเพื่อส่งต่อให้กับวิศวกร AI ทุกคนที่คุณรู้จัก
→ ติดตาม @sairahul1 สำหรับระบบและการแจกแจงแบบนี้เพิ่มเติม
→ บุ๊กมาร์กไว้ — คุณจะกลับมาอ้างอิงมันในครั้งหน้าที่มีอะไรพังใน production
ผมเขียนเกี่ยวกับ AI การสร้างผลิตภัณฑ์ และระบบที่ทำงานในขณะที่คุณหลับ
