VCL ในคลิป RELAI: เปลี่ยน log ของ AI Agent เป็นชุดทดสอบซ้ำ

ที่มา: คลิป AI Engineer โดย Soheil Feizi จาก RELAI และบทความ VideoToBlog วันที่ 2026-07-04 (วันที่แสดงในบทความต้นทาง ไม่ใช่วันที่อัปโหลดวิดีโอที่ตรวจยืนยันแล้ว) กรอบ VCL การสาธิต support agent และผลคะแนนเป็นสิ่งที่ผู้บรรยายนำเสนอ ยังไม่ได้ทดสอบซ้ำหรือยืนยันผลกับระบบ production ของผู้อ่าน คำว่าตรวจสอบได้หมายถึงการวัดกับชุดทดสอบและ evaluator ที่กำหนด ไม่ใช่การพิสูจน์ว่าไม่มี regression ในทุกสถานการณ์ การใช้ log จริงต้องได้รับอนุญาต ลดหรือปกปิดข้อมูลส่วนบุคคล และจำกัดสิทธิ์ของเครื่องมือจำลอง ก่อนปรับระบบที่กระทบลูกค้าหรือเงินจริงควรมีผู้รับผิดชอบอนุมัติและแผนย้อนกลับ ส่วนตัวอย่างธุรกิจไทยคงจากต้นฉบับ · วิดีโอต้นทาง

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

คลิปจากช่อง AI Engineer ที่นำเสนอโดย Soheil Feizi จาก RELAI วางกรอบเรื่องนี้ได้คมมาก เขาไม่ได้พูดแค่ว่า AI ต้องเรียนรู้ต่อเนื่อง แต่ชี้ให้เห็นว่าการเรียนรู้แบบที่ใช้งานได้จริงต้อง “พิสูจน์ได้” ว่าดีขึ้นจริง และไม่ทำให้ความสามารถเดิมถอยหลัง ประเด็นนี้สำคัญกับเจ้าของธุรกิจไทยมาก เพราะในโลกจริงเราไม่ได้มี benchmark สวยๆ รออยู่เสมอ เรามีแต่ log งานจริง เสียงบ่นจากลูกค้า และข้อผิดพลาดที่เกิดกลาง production

แก่นของแนวคิดนี้คือ verifiable continual learning หรือการทำให้ AI agent เรียนรู้จากความล้มเหลวอย่างต่อเนื่องแบบตรวจสอบได้ บทความนี้จะสรุปแนวคิดทั้งหมด พร้อมวิเคราะห์ว่าถ้าเอามาใช้กับธุรกิจไทย เราควรคิดและลงมืออย่างไร

สารบัญ

• Step 1: เข้าใจก่อนว่า Continual Learning สำหรับ AI Agent คืออะไร
• Step 2: แยกให้ออกว่าโจทย์ใหญ่มี 2 เรื่อง คือ feedback และการลงมือแก้
• Step 3: รู้แหล่งที่มาของ feedback และอย่าหลงคิดว่า log คือคำตอบสุดท้าย
• Step 4: เปลี่ยน log กับ feedback ให้กลายเป็น learning environment ที่ทดสอบซ้ำได้
• Step 5: เลือกชั้นที่จะแก้ให้ถูก ไม่ใช่รีบไป fine-tune model
• Step 6: ใช้กรอบ Verifiable Continual Learning เพื่อให้การแก้พิสูจน์ได้
• Step 7: จำ 4 หลักการของ VCL ให้ขึ้นใจ
• Step 8: ดูตัวอย่างการทำงานจริงของลูปเรียนรู้แบบตรวจสอบได้
• Step 9: แปลทั้งหมดนี้เป็นบทเรียนสำหรับธุรกิจไทย
• Step 10: Actionable Insights
• Step 11: Troubleshooting
• Step 12: การต่อยอด
• Step 13: สรุป Checklist ทั้งหมด

Step 1: เข้าใจก่อนว่า Continual Learning สำหรับ AI Agent คืออะไร

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

Feizi อธิบายว่า agent สามารถถูกปรับปรุงได้หลายชั้น ไม่ได้มีแค่การจูน model อย่างเดียว ซึ่งเป็นจุดที่หลายทีมเข้าใจผิดกันบ่อย เวลา AI ตอบพลาด เรามักรีบสรุปว่าต้องเปลี่ยน model หรือ fine-tune ใหม่ ทั้งที่สาเหตุจริงอาจอยู่ใน prompt, workflow, tool integration หรือ memory ก็ได้

ในภาพรวม agent มี 3 ชั้นหลักที่ต้องมองพร้อมกัน

• Model layer คือความสามารถของ model เอง
• Harness layer คือสิ่งรอบ model เช่น prompt, tools, code, workflow และ skill
• Memory layer คือความจำทั้งระยะสั้นและระยะยาว

สำหรับธุรกิจ นี่แปลว่าการทำ AI ให้ดีขึ้นไม่จำเป็นต้องเริ่มจากทางที่แพงที่สุดเสมอไป หลายครั้งการแก้ workflow หรือเพิ่มกติกาใน memory อาจได้ผลกว่าการไปแตะ model ตรงๆ

Step 2: แยกให้ออกว่าโจทย์ใหญ่มี 2 เรื่อง คือ feedback และการลงมือแก้

การพัฒนา agent แบบเรียนรู้ต่อเนื่องมีโจทย์ใหญ่อยู่ 2 ข้อ

1. เราจะรู้ได้อย่างไรว่า agent ทำดีหรือแย่
2. เมื่อรู้แล้ว เราควรแก้ที่ชั้นไหน และแก้อย่างไร

สองคำถามนี้ฟังดูธรรมดา แต่ในของจริงยากมาก เพราะในระบบ production เรามักไม่มีคำตอบตรงๆ เช่น คะแนนสอบหรือ label พร้อมใช้ สิ่งที่มีจริงคือ session log, ข้อร้องเรียน, escalation, งานที่ค้าง, งานที่ต้องให้คนมาแก้ต่อ หรือ conversion ที่ไม่เกิด

มุมที่น่าสนใจคือ Feizi ไม่มอง feedback เป็นแค่คะแนน pass หรือ fail แต่รวมถึงคำอธิบายว่าควรทำอะไรแทนด้วย เพราะถ้าเรารู้แค่ว่าพลาด แต่ไม่รู้ว่าควรแก้อย่างไร ระบบเรียนรู้ต่อก็จะตันเร็วมาก

Step 3: รู้แหล่งที่มาของ feedback และอย่าหลงคิดว่า log คือคำตอบสุดท้าย

ในช่วงพัฒนา ระบบอาจมี benchmark กับ evaluator ชัดเจนอยู่แล้ว แบบนี้เป็นเคสง่าย เรารันโจทย์เดิม วัดคะแนน แล้วเทียบก่อนและหลังการปรับปรุงได้เลย

แต่พอขึ้น production ทุกอย่างเปลี่ยนไป เราไม่ได้มี benchmark สำเร็จรูป เรามีเพียง log ที่บอกว่าเกิดอะไรขึ้นใน session นั้น และหลายครั้งก็ไม่มี feedback แบบ explicit ว่าตรงไหนผิด

แหล่ง feedback จึงมักมาจาก 2 ทาง

• อัตโนมัติ ใช้ model อื่น, LLM, หรือ code มาช่วยวิเคราะห์ log
• ผู้เชี่ยวชาญมนุษย์ ให้คนที่เข้าใจงานจริงมาตรวจบางเคสแล้วอธิบายสิ่งที่ควรเกิดขึ้น

แนวทางแรก scale ได้ดี เหมาะกับงานปริมาณมาก แนวทางหลังให้คุณภาพสูงและสะท้อนกติกาทางธุรกิจได้ชัดกว่า ในมุมธุรกิจไทย ทางที่เวิร์กมักไม่ใช่เลือกอย่างใดอย่างหนึ่ง แต่ใช้ทั้งคู่ร่วมกัน เช่น ให้ AI ช่วยคัด session ที่น่าสงสัยก่อน แล้วให้หัวหน้าทีมหรือผู้เชี่ยวชาญมาตรวจเฉพาะเคสสำคัญ

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

Step 4: เปลี่ยน log กับ feedback ให้กลายเป็น learning environment ที่ทดสอบซ้ำได้

นี่คือหัวใจสำคัญที่สุดของทั้งคลิป Feizi ย้ำชัดว่า production logs ไม่ใช่ learning environments การมี log พร้อม feedback ยังไม่พอ เพราะมันยัง “ทดสอบซ้ำไม่ได้”

ถ้าจะให้ agent เรียนรู้ได้จริง เราต้องยกระดับสิ่งที่เกิดขึ้นครั้งเดียว ให้กลายเป็น environment ที่รันใหม่ได้ซ้ำๆ พร้อมตัววัดความสำเร็จที่ชัดเจน

learning environment ที่ดีควรมีองค์ประกอบหลักดังนี้

• สถานการณ์ที่สกัดมาจากเคสจริง
• ผู้ใช้จำลองหรือ persona ที่ใกล้เคียงของจริง
• tool จริงหรือ mocked tool ตามความเหมาะสม
• evaluator ที่นิยามว่าอะไรคือความสำเร็จ

มุมนี้สำคัญมากกับธุรกิจ เพราะมันเปลี่ยนการแก้ AI จากงานเดาสุ่ม เป็นงานที่ตรวจสอบได้ ตัวอย่างเช่น ถ้า AI support เจอเคสลูกค้าหัวร้อนบ่อย เราไม่ควรแค่บอกทีมว่า “ให้ตอบนุ่มขึ้น” แต่ควรสร้าง environment ที่จำลองลูกค้าแบบนี้ขึ้นมา แล้วกำหนดตัววัด เช่น

• ยังคงรักษานโยบายบริษัทถูกต้องไหม
• ไม่ยั่วยุสถานการณ์ให้แย่ลงไหม
• รู้จังหวะ escalate ไปหาคนเมื่อควรไหม
• ยังปิดเคสได้ในกรอบที่ยอมรับได้ไหม

แนวคิดนี้สอดคล้องกับแนวทางการประเมินระบบ AI ที่หลายองค์กรเริ่มให้ความสำคัญ เช่นแนวทางด้าน evaluation และ monitoring ของ Anthropic และงานประเมิน LLM application ของ OpenAI

Step 5: เลือกชั้นที่จะแก้ให้ถูก ไม่ใช่รีบไป fine-tune model

เมื่อมี feedback และมี environment ที่ทดสอบซ้ำได้แล้ว คำถามต่อไปคือจะแก้อะไร Feizi แบ่งทางเลือกไว้ 3 ชั้น และนี่คือส่วนที่คนทำธุรกิจควรจำให้แม่น เพราะมันเกี่ยวกับต้นทุนและความเร็วโดยตรง

1) Model layer

นี่คือการเปลี่ยนน้ำหนักของ model เช่น supervised fine-tuning, RL post-training หรือ LoRA ข้อดีคือแตะความสามารถแกนกลางของระบบได้ แต่ข้อเสียคือแพง ใช้ compute สูง และมักต้องมี benchmark กับ evaluator ที่ชัดมากก่อนจะทำได้อย่างปลอดภัย

สำหรับธุรกิจส่วนใหญ่ นี่ไม่ใช่จุดเริ่มต้นที่ดีเสมอไป โดยเฉพาะถ้ายังไม่เข้าใจ root cause จริงๆ

2) Harness layer

ชั้นนี้ครอบคลุม prompt, skill, tool, code และ workflow รอบ model เป็นชั้นที่ยืดหยุ่นมากและมักให้ผลเร็ว เช่น

• ปรับ prompt ให้ไม่สรุปเร็วเกินไป
• เพิ่มขั้นตอนตรวจ policy ก่อนคืนเงิน
• เพิ่มเงื่อนไขบังคับ escalate ก่อนทำ action เสี่ยง
• เปลี่ยนวิธีเรียก tool ให้ข้อมูลครบขึ้น

ในมุมปฏิบัติจริง ชั้นนี้มักเป็นพื้นที่ที่ธุรกิจได้ผลเร็วที่สุด เพราะแตะงานจริงได้โดยไม่ต้องรื้อ model ใหญ่

3) Memory layer

ชั้นนี้คือการเก็บ facts, correction หรือ distilled skill เพื่อไม่ให้ agent ต้องเรียนรู้ใหม่ทุกครั้ง ข้อดีคือถูกและเร็วมาก เช่น เขียนไว้เลยว่า policy ล่าสุดของสินค้า A คืออะไร หรือกรณีแบบไหนต้องส่งต่อให้คน

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

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

Step 6: ใช้กรอบ Verifiable Continual Learning เพื่อให้การแก้พิสูจน์ได้

Feizi เสนอกรอบที่เรียกว่า Verifiable Continual Learning หรือ VCL โดยนิยามง่ายๆ ว่าเป็นการทำให้ agent เรียนรู้จากประสบการณ์ของตัวเอง โดยทุกการแก้ต้องพิสูจน์ได้ว่า

• ช่วยให้ดีขึ้นจริง
• ไม่ทำลายสิ่งที่เคยทำได้ดีอยู่แล้ว

VCL มี 3 ขั้นตอนหลัก

1. Executable test เปลี่ยน failure ให้กลายเป็นโจทย์ที่รันซ้ำได้
2. Measured delta วัดก่อนและหลังการแก้แบบชัดเจน
3. Regression check ตรวจว่าของเดิมที่เคยผ่านยังผ่านอยู่

ถ้ามองแบบธุรกิจ นี่คือการเอาหลัก QA และ change management มาใส่ในโลก AI อย่างจริงจัง แทนที่จะอัปเดต prompt แล้วหวังว่าทุกอย่างจะดีขึ้นเอง

Step 7: จำ 4 หลักการของ VCL ให้ขึ้นใจ

Feizi สรุปหลักการของระบบ continual learning ที่ใช้งานได้จริงไว้ 4 ข้อ ซึ่งถือว่าเป็น checklist ทางความคิดที่ดีมาก

Replayable

ความล้มเหลวต้องถูกแปลงเป็น test ที่รันใหม่ได้ ไม่อย่างนั้นเราไม่มีทางรู้ว่าแก้แล้วหายจริงหรือแค่บังเอิญดีขึ้น

Holistic

หนึ่ง failure อาจมีหลายสาเหตุ เช่น memory เก่า, prompt ไม่ชัด, tool normalize ข้อมูลไม่ดี, workflow ขาดขั้นตอนอนุมัติ หรือ model reasoning ไม่พอ จึงต้องวิเคราะห์ทั้งระบบ ไม่ใช่โทษ model อย่างเดียว

Lifelong

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

Efficient

ลูปการเรียนรู้นี้ต้องรันได้บ่อย ถ้าการแก้แต่ละครั้งช้าและแพงเกินไป สุดท้ายทีมจะเลิกใช้เอง เพราะตามของจริงไม่ทัน

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

Step 8: ดูตัวอย่างการทำงานจริงของลูปเรียนรู้แบบตรวจสอบได้

ในตัวอย่างของ RELAI มีการสร้าง benchmark ของ support agent แบบสมมติที่มีนโยบายชัดเจน มี evaluator ที่ deterministic และมี regression trap เพื่อจับอาการ overfit กับการแก้เคสล่าสุด

จากนั้นมีการสร้าง learning environment จากคำสั่งง่ายๆ เช่น ให้ลองทดสอบจุดอ่อนเมื่อเจอผู้ใช้ที่หยาบคายและเป็นปฏิปักษ์ ระบบจะสร้าง persona, intent, tool setup และ evaluator ให้พร้อม

ต้นฉบับรายงานคะแนนก่อนและหลังเรียก optimize ประมาณ 78 และ 97 เปอร์เซ็นต์ พร้อมกล่าวถึงการดีขึ้นเฉลี่ยราว 10 เปอร์เซ็นต์ แต่ไม่ได้แจกแจงว่าตัวเลขเฉลี่ยใช้ฐานหรือเกณฑ์เดียวกัน จึงไม่ควรอ่านว่า 78 ไป 97 เท่ากับเพิ่ม 10 เปอร์เซ็นต์ ตัวเลขทั้งหมดเป็นผลเดโมของต้นทาง

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

อีกตัวอย่างที่น่าสนใจคือเมื่อ agent อยู่ใน production แล้ว ระบบสามารถรับ log จริงกับ feedback จากพฤติกรรมที่ไม่พึงประสงค์ แล้วแปลงเป็น learning environment เพื่อแก้ต่อได้โดยไม่ทำลาย performance เดิม

Step 9: แปลทั้งหมดนี้เป็นบทเรียนสำหรับธุรกิจไทย

ถ้าเอาแนวคิดนี้มาใช้กับธุรกิจไทย หน้าตาจะไม่ใช่การสร้าง AI อัจฉริยะในวันเดียว แต่คือการตั้งระบบให้ AI ดีขึ้นทีละรอบแบบควบคุมได้

ตัวอย่างการใช้งานที่เห็นภาพ

• แอดมินตอบแชตขาย แก้เคสตอบเร็วแต่ขายไม่ปิด โดยสร้าง environment สำหรับลูกค้าลังเลหรือกดราคา
• Customer support แก้เคสคืนเงินผิด policy โดยให้ evaluator ตรวจทั้งความถูกต้องและโทนการสื่อสาร
• HR หรือ IT helpdesk ภายใน แก้เคสตอบถูกบางส่วนแต่ไม่ส่งต่อ ticket เมื่อควรส่ง
• ทีม operation แก้เคส AI ตีความ SOP เก่าหลังมีการอัปเดตนโยบายใหม่

จุดที่เราเห็นด้วยมากคือ การเรียนรู้ต่อเนื่องของ agent ไม่จำเป็นต้องเริ่มที่ fine-tuning เสมอไป แต่จุดที่ควรระวังคือแนวคิดนี้ยังต้องมีวินัยด้าน evaluation สูงพอสมควร ถ้าองค์กรยังไม่เก็บ log ดีพอ ไม่มีเจ้าของ metric ชัด หรือ feedback จากคนหน้างานไม่เป็นระบบ ต่อให้มีเครื่องมือดี ก็อาจไปได้ไม่สุด

Step 10: Actionable Insights

• เริ่มจากการเก็บ failure ที่กระทบธุรกิจจริง 5 ถึง 10 เคสก่อน อย่าเริ่มจากการอยากทำระบบใหญ่ทันที
• แยก metric ออกเป็น 2 ชั้นเสมอ คือผลลัพธ์ทางธุรกิจ และคุณภาพพฤติกรรมของ agent
• ก่อนคิดเรื่อง fine-tune ให้ตรวจ prompt, tool, workflow และ memory ก่อนทุกครั้ง
• สร้าง regression test สำหรับเคสที่สำคัญต่อรายได้หรือความเสี่ยง เช่น คืนเงิน, อนุมัติ, escalation
• ให้คนหน้างานมีบทบาทใน feedback loop เพราะความรู้ domain อยู่ตรงนั้น ไม่ได้อยู่ที่ model อย่างเดียว

Step 11: Troubleshooting

ปัญหา: แก้ prompt แล้วเคสล่าสุดดีขึ้น แต่เคสเก่าพัง
สาเหตุ: ไม่มี regression check ก่อนปล่อยใช้
วิธีแก้: รวบรวมเคสสำคัญเดิมเป็นชุดทดสอบถาวร แล้วบังคับรันทุกครั้งก่อนอัปเดต

ปัญหา: ทีมรู้ว่า AI ตอบไม่ดี แต่บอกไม่ได้ว่าผิดตรงไหน
สาเหตุ: feedback กว้างเกินไป เช่น บอกแค่ว่า “ตอบไม่โอเค”
วิธีแก้: ทำ feedback template ให้ชัด เช่น ผิด policy, โทนไม่เหมาะ, ไม่ escalate, ใช้ข้อมูลเก่า

ปัญหา: พยายามแก้ด้วย model ใหม่ตลอด แต่ผลไม่เสถียร
สาเหตุ: root cause อยู่ที่ harness หรือ memory มากกว่า model
วิธีแก้: ทำ root cause analysis ก่อนทุกครั้ง แล้วเลือกการเปลี่ยนแปลงที่เล็กที่สุดก่อน

ปัญหา: มี log เยอะมาก แต่เอามาใช้เรียนรู้ไม่ได้
สาเหตุ: log ยังไม่ถูกแปลงเป็นสถานการณ์ที่รันทดสอบซ้ำได้
วิธีแก้: สกัดเคสตัวแทน สร้าง persona, tool state และ success criteria ให้ครบ

ปัญหา: AI จำ correction ใหม่ แต่ยังทำผิดซ้ำในบางสถานการณ์
สาเหตุ: memory ถูกเขียนเพิ่ม แต่ไม่มีตัวพิสูจน์ว่าครอบคลุม pattern ใกล้เคียง
วิธีแก้: ขยาย environment ให้มี variation ของเคสเดิม แล้ววัดผลใหม่

Step 12: การต่อยอด

• ทำ dashboard แยก failure ตามมูลค่าทางธุรกิจ เพื่อให้ทีมรู้ว่าควร optimize อะไรก่อน
• เชื่อม feedback จากหัวหน้าทีม support หรือ sales เข้าเป็น structured signal แทนการคอมเมนต์ลอยๆ
• สร้างคลัง reusable learning environments สำหรับเคสซ้ำๆ เช่น ลูกค้าโกรธ, ขอส่วนลด, ขอ exception, ขอคืนเงิน

Step 13: สรุป Checklist ทั้งหมด

• ☐ ระบุให้ชัดว่า agent ที่ใช้อยู่มีปัญหาอะไรในงานจริง
• ☐ เก็บ log และ feedback จากเคสที่มีผลต่อธุรกิจ
• ☐ แปลงเคสจริงให้เป็น replayable learning environment
• ☐ กำหนด evaluator หรือเกณฑ์ความสำเร็จให้ชัด
• ☐ วิเคราะห์ root cause ว่าอยู่ที่ model, harness หรือ memory
• ☐ เลือกการเปลี่ยนแปลงที่เล็กที่สุดแต่คงผลได้ยาว
• ☐ วัดผลก่อนและหลังการปรับปรุงทุกครั้ง
• ☐ รัน regression test กับเคสสำคัญเดิมเสมอ
• ☐ ทำลูปนี้ซ้ำอย่างต่อเนื่อง ไม่ใช่แก้แบบครั้งต่อครั้ง
• ☐ ให้คนหน้างานมีส่วนร่วมใน feedback loop

ข้อสรุปที่ชัดที่สุดจากคลิปนี้คือ Continual Learning for AI Agents ไม่ใช่เรื่องของ model อย่างเดียว และไม่ใช่การทำให้ AI “จำ” เก่งขึ้นเฉยๆ แต่คือการสร้างระบบเรียนรู้ที่พิสูจน์ได้ว่าแก้แล้วดีขึ้นจริงโดยไม่พังของเดิม

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