ขีดความสามารถแกนหลักใหม่ของ AI ไม่ใช่พรอมป์ต์ แต่คือ "Context Engineering"

 (philschmid.de)
48 คะแนน โดย GN⁺ 2025-07-01 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • การถกเถียงกำลังขยับจาก "prompt engineering" ไปสู่ "context engineering" ที่ก้าวไปอีกขั้น
  • คอนเท็กซ์ไม่ได้หมายถึงเพียงประโยคพรอมป์ต์ แต่คือข้อมูลทั้งหมดที่ LLM มองเห็นได้ก่อนสร้างคำตอบ (คำสั่ง, ประวัติการสนทนา, หน่วยความจำระยะยาว, ข้อมูลภายนอก, เครื่องมือที่ใช้ได้ ฯลฯ)
  • ความสำเร็จและความล้มเหลวของเอเจนต์ในตอนนี้ ขึ้นอยู่กับคุณภาพของคอนเท็กซ์มากกว่าความสามารถของโมเดล
  • เอเจนต์ที่ล้ำหน้ากว่าเดิม สามารถผสานบริบทหลากหลาย เช่น ปฏิทินของผู้ใช้ อีเมลเก่า รายชื่อติดต่อ เพื่อสร้างคำตอบที่ใกล้เคียงการแก้ปัญหาในโลกจริงมากขึ้น
  • context engineering คือ การออกแบบระบบแบบไดนามิกที่ปรับตามสถานการณ์ ซึ่งเป็นกระบวนการจัดส่งข้อมูลและเครื่องมือที่ถูกต้องให้ LLM ในจังหวะเวลาที่เหมาะสม

Context Engineering คืออะไร

  • ช่วงหลังมานี้ ในวงการ AI คำว่า "context engineering" กำลังแพร่หลายอย่างรวดเร็ว
  • หาก "prompt engineering" แบบเดิมมุ่งเน้นการออกแบบคำถามหรือคำสั่งเดี่ยว ๆ context engineering คือแนวทางที่กว้างกว่าและทรงพลังกว่า
  • Tobi Lutke ให้นิยามสิ่งนี้ว่าเป็น "ศิลปะของการจัดเตรียมคอนเท็กซ์ทั้งหมดเพื่อให้ LLM แก้งานได้อย่างน่าเชื่อถือ"

องค์ประกอบหลักของคอนเท็กซ์

  • การที่ระบบเอเจนต์จะทำงานได้สำเร็จหรือไม่ ขึ้นอยู่มากกับว่า มีข้อมูลอะไรถูกรวมอยู่ใน working memory
  • ความล้มเหลวของเอเจนต์ส่วนใหญ่ไม่ได้เกิดจากตัวโมเดล แต่เกิดจาก การขาดคอนเท็กซ์ที่เหมาะสม

ส่วนประกอบของคอนเท็กซ์

  • system prompt/คำสั่ง: คำสั่งพื้นฐาน ตัวอย่าง และกฎต่าง ๆ ที่กำหนดพฤติกรรมของโมเดล
  • user prompt: คำขอหรือคำถามล่าสุดจากผู้ใช้
  • สถานะ/ประวัติการสนทนา: ลำดับการสนทนาและข้อมูลบริบทจนถึงปัจจุบัน
  • หน่วยความจำระยะยาว: บทสนทนาก่อนหน้าที่ผ่านมาหลายขั้นตอน ความชอบของผู้ใช้ สรุปโปรเจกต์ในอดีต และชุดข้อมูลที่ฝึกให้โมเดลจดจำระยะยาว
  • RAG (การเสริมด้วยการค้นคืนข้อมูล): ข้อมูลล่าสุดและเกี่ยวข้องสูงที่ดึงมาจากเอกสารภายนอก ฐานข้อมูล API เป็นต้น
  • เครื่องมือที่ใช้งานได้: นิยามของฟังก์ชันหรือเครื่องมือในตัวที่โมเดลสามารถเรียกใช้ได้ (เช่น check_inventory, send_email)
  • structured output: การกำหนดรูปแบบคำตอบที่โมเดลต้องปฏิบัติตาม (เช่น JSON)

ทำไมคอนเท็กซ์จึงสำคัญ

  • ปัจจัยที่ทำให้สร้าง AI agent ที่มีประสิทธิภาพจริง ได้ ไม่ใช่โค้ดที่ซับซ้อนหรือคุณภาพของโมเดล แต่คือ การให้คอนเท็กซ์ที่เหมาะสมได้มากแค่ไหน
  • เอเจนต์แบบง่ายสำหรับ "เดโม" จะรับเพียงคำขอของผู้ใช้แล้วให้คำตอบพื้นฐาน ขณะที่เอเจนต์ที่ "เหมือนมีเวทมนตร์" จะพิจารณาคอนเท็กซ์ที่หลากหลาย จึงสร้างคำตอบที่มีประโยชน์และเป็นมนุษย์มากกว่าอย่างชัดเจน
  • เปรียบเทียบ
    • เอเจนต์คุณภาพต่ำ (สำหรับเดโม): ดูแค่คำของ่าย ๆ แล้วสร้างคำตอบแบบตายตัว เช่น อีเมลถามว่า "พรุ่งนี้สะดวกไหม" ก็จะตอบเชิงกลไกว่า "พรุ่งนี้ได้ครับ/ค่ะ สะดวกกี่โมง"
    • เอเจนต์คุณภาพสูง (เหมือนมีเวทมนตร์): สามารถใช้ทั้งปฏิทินของตนเอง ประวัติอีเมลก่อนหน้า ข้อมูลตัวตนของอีกฝ่าย ตัวเลือกในการเรียกใช้เครื่องมือที่จำเป็น ฯลฯ เพื่อสร้างคำตอบที่เป็นธรรมชาติและเหมาะกับสถานการณ์ เช่น "พรุ่งนี้ตารางเต็มแล้ว แต่เช้าวันพฤหัสว่าง ผม/ฉันส่งคำเชิญนัดหมายไปให้แล้ว ถ้าสะดวกช่วยแจ้งได้เลย"
  • ดังนั้นสิ่งสำคัญไม่ใช่ อัลกอริทึม หรือโมเดล แต่คือการจัดเตรียมคอนเท็กซ์ที่ถูกต้องให้เหมาะกับงาน
  • ความล้มเหลวของ AI agent ส่วนใหญ่จึงไม่ได้เกิดจากโมเดล แต่เป็นผลจาก ความล้มเหลวในการออกแบบคอนเท็กซ์

วิวัฒนาการจาก prompt engineering สู่ context engineering

  • หาก prompt engineering มุ่งเน้นการปรับแต่งคำสั่งข้อความเพียงบรรทัดเดียว context engineering จะครอบคลุมข้อมูล เครื่องมือ และการออกแบบเชิงโครงสร้างที่กว้างขวางกว่ามาก
  • context engineering คือ "ทักษะเชิงวิชาชีพด้านการออกแบบและสร้างระบบ ที่จัดส่งข้อมูลและเครื่องมือที่จำเป็นให้ LLM อย่างเป็นระบบ ในรูปแบบและจังหวะเวลาที่ถูกต้อง เพื่อให้ทำภารกิจสำเร็จได้"

ลักษณะเด่นของ context engineering

  • การออกแบบระบบทั้งชุด: คอนเท็กซ์ไม่ใช่แค่เทมเพลตพรอมป์ต์ แต่เป็นผลลัพธ์ของทั้งระบบที่ทำงานก่อนการเรียกใช้ LLM
  • การสร้างแบบไดนามิก: เลือกและประมวลผลข้อมูลหลากหลายแบบเรียลไทม์ตามงาน เช่น ปฏิทิน/อีเมล/การค้นหาเว็บ
  • การส่งมอบข้อมูลและเครื่องมือให้ถูกที่ถูกเวลา: หลักการ "Garbage In, Garbage Out" ทำให้การหลีกเลี่ยงข้อมูลที่ไม่จำเป็นหรือข้อมูลที่ตกหล่นเป็นเรื่องสำคัญ
  • ความชัดเจนของรูปแบบมีความสำคัญ: เวลาป้อนข้อมูลไม่ควรเรียงอย่างกระจัดกระจาย แต่ควรสรุปและจัดโครงสร้าง รวมถึงต้องอธิบายวิธีใช้เครื่องมือให้ชัดเจน

บทสรุป

  • แก่นแท้ของการพัฒนา AI agent ที่ทรงพลังและเชื่อถือได้ ไม่ใช่ "พรอมป์ต์มหัศจรรย์" หรือโมเดลรุ่นล่าสุด แต่คือ context engineering (การออกแบบและส่งมอบคอนเท็กซ์)
  • สิ่งนี้ไม่ใช่แค่ปัญหาเชิงเทคนิคเท่านั้น แต่ยังต้องอาศัย ความสามารถในการออกแบบระบบแบบรอบด้าน ให้สอดคล้องกับความต้องการและเป้าหมายทางธุรกิจ เช่น การกำหนดข้อมูล เครื่องมือ และ structured output ที่เหมาะสม
  • หัวใจสำคัญคือ การให้ข้อมูลที่เหมาะสม ในรูปแบบที่ถูกต้อง และในเวลาที่แม่นยำ เพื่อให้ LLM ทำภารกิจให้สำเร็จ

เอกสารอ้างอิง

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
kimjoin2 2025-07-07

รู้สึกเหมือนแค่เปลี่ยนชื่อเท่านั้นนะ
 
GN⁺ 2025-07-01
ความเห็นจาก Hacker News

  • ช่วงนี้ฉันเพิ่งเขียนบล็อกเกี่ยวกับหัวข้อนี้ไป ลองดูได้ที่ บทความของฉัน - Context Engineering
    ฉันคิดว่าบทความของ Drew Breunig อธิบายเรื่องนี้ไว้ได้ยอดเยี่ยมมาก
    จังหวะเวลามันบังเอิญไปตรงกับช่วงที่มีมีมคำว่า “context engineering” พอดี แต่จริง ๆ แล้วงานนี้ไม่ได้เกี่ยวกับมีมนั้น
    ในบทความ How Long Contexts Fail - ทำไมคอนเท็กซ์ยาว ๆ ถึงล้มเหลว มีการอธิบายหลายแง่มุมว่าคอนเท็กซ์ที่ยาวเกินไปก่อปัญหาอย่างไร และสิ่งที่เรียกว่า “context rot” เกิดขึ้นได้อย่างไร
    ส่วนบทความ How to Fix Your Context - วิธีแก้คอนเท็กซ์ของคุณ ได้ตั้งชื่อเทคนิคต่าง ๆ สำหรับแก้ปัญหาไว้ เช่น Tool Loadout, Context Quarantine, Context Pruning, Context Summarization และ Context Offloading

    • ฉันคิดว่าโพสต์ของ Drew Breunig ควรค่าแก่การอ่านมาก
      เรื่องนี้สำคัญมากไม่ใช่แค่กับการสร้างเอเจนต์ของตัวเอง แต่ยังรวมถึงตอนใช้งาน agent coding ในตอนนี้ด้วย
      ข้อจำกัดและรูปแบบพฤติกรรมเหล่านี้น่าจะยังคงอยู่ไปอีกพักใหญ่

    • อยากเห็นว่าใครจะเป็นคนแรกที่พัฒนา Logic Core สำหรับทำงานของ context engineer แบบอัตโนมัติ

    • ฉันคิดว่านี่ก็เป็น “ทักษะแบบอยู่ได้แค่เดือนเดียว” เหมือนกัน
      สุดท้ายก็คงหายไปเหมือนกระแสอื่น ๆ อีกมากมาย

    • ประเด็นเหล่านี้ในวงการวิจัย LLM ถือเป็นผลพวงจาก LLM รุ่นปัจจุบัน
      ตอนนี้ก็มีงานวิจัยเรื่องการใช้เครื่องมือนับล้านตัวพร้อมกันและการใช้ long context ที่เสถียรอยู่แล้ว
      ในอนาคต นอกจากกรณีพิเศษที่ต้องเชื่อมกับผู้ให้บริการอื่น ๆ ก็น่าจะมีสถานการณ์ส่วนใหญ่ที่เอเจนต์ตัวเดียวก็เพียงพอ
      คนที่ออกแบบระบบเอเจนต์แห่งอนาคตโดยยึดกับ LLM รุ่นปัจจุบัน มีโอกาสลงเอยแบบเดียวกับ LangChain
      เหมือนกับที่ LangChain ซึ่งทำมาสำหรับ GPT-3 กลายเป็นของล้าสมัยทันทีเมื่อ GPT-3.5 มา

  • สำหรับคนที่เคยใช้ LLM หรือรู้ว่า LLM ทำงานอย่างไร เรื่องนี้ค่อนข้างชัดเจนอยู่แล้ว
    “ทักษะ” อย่าง prompt engineering เองก็ดูชัดว่าเป็นแค่แกนชั่วคราวและอยู่ได้ไม่นาน
    โดยพื้นฐานแล้วมันคือการป้อนอินพุตให้ LLM (คอนเท็กซ์) และรับการกระทำกลับมา (เอาต์พุต) ซึ่งต้องอาศัยงานด้าน pipeline จำนวนมาก

  • ฉันเห็นด้วยกับข้อสรุปที่ว่า “การสร้าง AI agent ที่ทรงพลังและเชื่อถือได้กำลังห่างออกจากการตามหาพรอมป์ตวิเศษหรือการอัปเดตโมเดล”
    การโฟกัสที่ “context engineering ซึ่งคือการส่งมอบข้อมูลและเครื่องมือที่เหมาะสม ในรูปแบบที่เหมาะสม และในเวลาที่เหมาะสม” นั้นถูกต้อง
    แต่ถ้า “รูปแบบที่เหมาะสม” กับ “เวลาที่เหมาะสม” ยังไม่มีนิยามที่แท้จริง แบบนี้มันก็ยังเป็นการไล่ตาม “ทางออกวิเศษ” อยู่ไม่ใช่หรือ
    ถ้า “ข้อมูลที่เหมาะสม” หมายถึง “ข้อมูลที่ทำให้ LLM ตอบได้แม่นพอ” ฉันก็มองว่าโดยแก่นแล้วมันไม่ได้ต่างจาก prompt engineering
    สำหรับเครื่องจักรที่ไม่เป็นดีเทอร์มินิสติกแบบนี้ ดูเหมือนว่าจะมีฮิวริสติกที่เชื่อถือได้ไม่มากไปกว่า “ลองพรอมป์ตดูแล้วค่อยดูผลลัพธ์”

    • สุดท้ายก็ยังเป็นความคิดเชิงเวทมนตร์แบบไม่รู้จบ
      ต่อให้ตอนนี้เปลี่ยนชื่อจาก “prompt engineering” เป็น “context engineering” มันก็ยังคือการลองขยับแต่งนั่นนี่ในพื้นที่ที่ไม่แน่นอน เพื่อหาอะไรบางอย่างที่ใช้ได้ผลอยู่ดี

    • โดยแก่นแล้วมันคือ overfitting
      prompt engineering ก็เป็นแบบนั้นแหละ

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

    • ในกรอบทฤษฎีล่าสุด กระบวนการนี้ถูกแบ่งเป็นสองช่วงคือ exploratory และ discovery
      ช่วง exploratory ให้นึกว่าเป็นอุปกรณ์พ่นสารลอยฟุ้ง
      ปล่อยสารบ่งชี้ที่สังเกตได้ง่ายเข้าไปอย่างรวดเร็ว (ปกติจะเปรียบกับอุจจาระ)
      จากนั้นช่วง discovery ก็คือการวิเคราะห์รูปแบบการกระจายของมัน
      ถ้าจะสรุปสองช่วงนี้แบบสั้น ๆ ก็คือ “ลองมั่ว ๆ ไปก่อน” แล้วค่อย “ดูผล”

    • ตอนนี้พอทุกคนเริ่มตระหนักว่า “prompt engineering” ไม่ใช่ทักษะวิเศษอะไร ก็รู้สึกเหมือนวงการ AI เลื่อนเส้นชัยไปเรื่อย ๆ

  • ทักษะใหม่สุดท้ายก็คือ “การเขียนโปรแกรม”
    เป็นทักษะเดิมนั่นแหละ
    ถ้าอยากเข้าใจเรื่องพวกนี้ก็ต้องลงมือเขียนโปรแกรมเอง
    เขียนโปรแกรมเพื่อฝึก LLM, รัน inference และวิเคราะห์พฤติกรรมของมัน แล้วจะเข้าใจมากขึ้นเรื่อย ๆ
    ตอนแรกฉันเองก็มีทั้งทฤษฎีและผลลัพธ์ที่คาดไว้ แต่พอได้ลองฝึก LLM หลายแบบจริง ๆ ก็ได้ผลลัพธ์และความมั่นใจที่ต่างออกไปโดยสิ้นเชิง
    การลงมือสร้างเครื่องมือจริงเป็นสิ่งที่ทำให้เกิดความแตกต่างอย่างเด็ดขาด
    ฉันเองมีประสบการณ์ด้านการเขียนโปรแกรมแมชชีนเลิร์นนิงระดับกลางเท่านั้น แต่คิดว่าการเคยสร้างคอมไพเลอร์ระดับกลางด้วยตัวเองคือกุญแจสำคัญของการได้ผลลัพธ์ที่ดีในระบบซับซ้อน
    คิดว่า Karpathy รู้เรื่องนี้ได้อย่างไรล่ะ
    คำตอบอยู่ใน บล็อกของ Karpathy

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

  • การถกเถียงนี้เริ่มให้ความรู้สึกคล้ายฟอรัมเกมอย่าง WoW มากขึ้นเรื่อย ๆ ที่เหล่าเกมเมอร์ลองยุทธวิธีต่าง ๆ แล้วถกกันด้วยภาษากลุ่มประหลาด ๆ
    สิ่งที่เรียกว่ายุทธวิธีนั้นแทบทั้งหมดก็หาได้จากการลองผิดลองถูก และคุยกันด้วยภาษาที่เข้าใจกันเองเฉพาะในกลุ่ม
    การเขียนโปรแกรมเองก็กำลังปรับตัวเข้าสู่ยุคของ gamification มากขึ้น
    พวก power user กำลังขายกลยุทธ์ปลอม ๆ ให้ทั้งมือใหม่และผู้บริหารที่มีนิสัยแบบเกมเมอร์มากเกินไป

    • ฉันเองก็มีมุมมองคล้ายกัน
      เอาจริง ๆ ในกระแส enterprise software ก่อนหน้านี้ก็มีอะไรแบบนี้วนซ้ำอยู่แล้ว
      ครั้งนี้แค่ต่างตรงที่กระแส “ขับเคลื่อนโดย power user” รุกล้ำลึกเข้ามาถึงพื้นที่อิทธิพล/การควบคุม/เวิร์กโฟลว์ของนักพัฒนา ซึ่งก็คือคนสร้างของ
      ความรู้สึกที่นักพัฒนาหลายคนมีในตอนนี้ คงไม่ต่างจากที่คนสาย QA, SRE, CS เคยรู้สึกตอนถูกบังคับใช้เครื่องมือหรือแนวปฏิบัติเพราะมีคนบอกว่า “นี่แหละอนาคต!”

  • สรุปคือ:
    “การสร้าง AI agent ที่ทรงพลังและเชื่อถือได้ ไม่ได้อยู่ที่พรอมป์ตวิเศษหรือการอัปเดตโมเดล แต่อยู่ที่ context engineering ซึ่งคือการให้ข้อมูลและเครื่องมือที่ถูกต้อง ในรูปแบบและเวลาที่เหมาะสมสำหรับการใช้งานทางธุรกิจ”
    อันที่จริงนี่ก็เป็นหลักการเดียวกับมนุษย์เหมือนกัน
    ถ้าให้ข้อมูลที่ถูกต้องในเวลาที่เหมาะสม มนุษย์ก็แก้ปัญหาได้ดีขึ้น

    • ฉันไม่ชอบกระแสเปรียบเทียบแมชชีนเลิร์นนิงกับมนุษย์แบบผิวเผินนี้
      มันไม่มีอินไซต์ และแทบไม่ถูกต้องด้วย

    • ท้ายที่สุดแล้วก็คือการหาปุ่มเป้าหมายในสภาพแวดล้อมแล้วกดมันให้ได้อย่างมีประสิทธิภาพ
      ไม่ได้ต่างจากวิศวกรรมซอฟต์แวร์แบบเดิมมากนัก
      แค่ผลลัพธ์ไม่เป็นดีเทอร์มินิสติกมากกว่า

    • ฉันขอให้ทีม UX และ product อธิบายเรื่องอย่าง “mockup, requirements, acceptance criteria, sample input/output และเหตุผลว่าทำไมฟีเจอร์นี้ถึงสำคัญ” อยู่ตลอด
      ถ้ายังสแกนสมองเพื่อดึงสิ่งที่ต้องการออกมาไม่ได้ การอธิบายสิ่งที่ต้องการให้ชัดเจนก็ยังจำเป็นอย่างยิ่งในโลกจริง
      นี่ไม่ใช่เรื่องที่ควรพึ่งแค่ ‘ความรู้สึก’

    • สิ่งสำคัญไม่ใช่คอนเท็กซ์ที่มากขึ้น แต่เป็นคอนเท็กซ์ที่ดีกว่า
      (ตัวอย่างคลาสสิก: X-Y problem)

  • ต่อให้ให้คอนเท็กซ์ที่ยอดเยี่ยมมากกับ LLM รุ่นล่าสุด มันก็ยังล้มเหลวได้อยู่ดี
    บริษัทของเราขุดลึกเรื่องนี้มานานเกิน 2 ปีแล้ว
    ฉันประหลาดใจกับความเชื่อแบบไม่ลืมหูลืมตาที่ว่าคอนเท็กซ์คือคำตอบ

    • พอถึงจุดหนึ่ง ฉันคิดว่าทำงานเองโดยไม่ใช้ AI ยังจะเร็วกว่า
      อย่างน้อยมันก็ยังทิ้งบทเรียนที่มีประโยชน์ไว้ให้ มากกว่าการเสียเวลาหลายชั่วโมงไปกับการสร้างคอนเท็กซ์ให้ LLM

    • อยากรู้ตัวอย่างที่ LLM ล้มเหลวทั้งที่ให้คอนเท็กซ์เพียงพอแล้ว
      ถ้ามีตัวอย่างที่ชัดเจนก็อยากให้แชร์

  • การตามหาพรอมป์ตวิเศษไม่เคยเป็น “prompt engineering” จริง ๆ ตั้งแต่แรก
    โดยแก่นแท้มันคือ “context engineering” มาโดยตลอด
    มีผู้เชี่ยวชาญ AI แบบอ้างตัวเองจำนวนมากที่เอาเรื่องนี้ไปขายในชื่อ prompt engineering แต่จริง ๆ แล้วพวกเขาไม่ได้เข้าใจแก่นแท้ของมันดีนัก
    RAG (retrieval-augmented generation) ไม่ใช่แนวคิดที่เพิ่งโผล่มาในปีนี้
    เครื่องมือที่ห่อความซับซ้อนขององค์ความรู้ต่าง ๆ อย่าง embeddings, vector DB, graph DB ก็กำลังแพร่หลายมากขึ้นเรื่อย ๆ
    แพลตฟอร์มขนาดใหญ่เองก็ปรับปรุงเครื่องมือที่เกี่ยวข้องเพื่อเปิดระบบนิเวศให้กว้างขึ้น

  • รู้สึกเหมือนชอบสร้างคำใหม่แล้วเปลี่ยนชื่อให้กับปัญหาเดิม ๆ อยู่ตลอด
    สุดท้ายก็เป็นการตีกลองหน้ากองไฟแล้วร่ายคาถาแบบพิธีหมอผีซ้ำไปซ้ำมา

    • ตอนที่ฉันลองทำอะไรแบบนี้ครั้งแรก ก็เคยอธิบายให้เพื่อนฟังคล้าย ๆ กัน
      มันเหมือนการอัญเชิญปีศาจ ต้องท่องคาถาให้ถูกคำถูกจังหวะแล้วหวังว่ามันจะเชื่อฟังคำสั่งของเรา
      ในใจฉันเองก็ขัดแย้งระหว่างความเป็นวิศวกรที่ต้องการความน่าเชื่อถือ การทำซ้ำได้ และ test coverage ที่แน่นหนา กับความซับซ้อนที่ควบคุมไม่ได้ของสิ่งนี้
      ฉันนับถือคนที่กล้าเดโมระบบแบบนี้ในสเกลใหญ่จริง ๆ
      มันทำให้นึกถึงสมัยเดโมงานวิจัยช่องโหว่ความปลอดภัย
      ต่อให้เตรียมมาดีแค่ไหน ผลลัพธ์ก็พร้อมจะเพี้ยนหน้างานได้เสมอ จนเคยเหงื่อตกกลางการนำเสนอ

  • มุมมองนี้คล้ายกับประสบการณ์ของฉันมาก
    เวลาใส่คอนเท็กซ์ให้ LLM ฉันมักถามตัวเองว่า “ถ้ามีข้อมูลแค่นี้ มนุษย์จะแก้ปัญหาได้ไหม?”
    ตอนที่เคยทำผลิตภัณฑ์ text2SQL ถ้าโมเดลล้มเหลว นักวิเคราะห์ข้อมูลจริงก็มักตอบประมาณว่า “อ้อ ตารางนั้นเป็นของเก่า ตอนนี้ใช้ตารางนี้นะ”
    ท้ายที่สุดก็คือ ถ้า LLM ขาดคอนเท็กซ์ที่ ‘นักวิเคราะห์มนุษย์’ ต้องใช้ มันก็ย่อมพลาด
    สิ่งหนึ่งที่ขาดหายไปจากหัวข้อนี้คือ “การประเมินผล (evaluations)”
    ทุกวันนี้ฉันยังแปลกใจเวลายังเห็นโปรเจกต์ AI ที่ไม่มีการประเมินผล หรือทำแบบขอไปที
    การประเมินผลสำคัญยิ่งกว่าการทดสอบในวิศวกรรมแบบดั้งเดิมเสียอีก
    ชุดประเมินไม่จำเป็นต้องใหญ่ แค่ครอบคลุมโดเมนปัญหาได้ดีก็พอ
    ถ้าไม่มี มันก็เป็นแค่ “การเดา”
    และฉันเองก็มักถามตัวเองบ่อย ๆ ว่า “ด้วยข้อมูลนี้ มนุษย์จะแก้ได้ไหม?”
    ฉันเองก็เคยคาดหวังให้ LLM แก้ปัญหาที่มนุษย์ยังแก้ไม่ได้

    • กฎคลาสสิกของการเขียนโปรแกรมคอมพิวเตอร์คือ
      “ถ้าคุณบอกว่าจะทำให้โปรแกรมเมอร์เขียนโค้ดเป็นภาษาอังกฤษได้ สุดท้ายคุณจะพบว่าโปรแกรมเมอร์ส่วนใหญ่เขียนภาษาอังกฤษกันไม่ค่อยได้ด้วยซ้ำ”
      แม้จะฟังดูเป็นมุก แต่ก็จริงอยู่พอสมควร
      ภาษาธรรมชาติส่วนใหญ่ไม่ได้ชัดเจนขนาดนั้น
      ถ้าคุณอธิบายสิ่งที่ต้องการเป็นภาษาอังกฤษได้อย่างแม่นยำมากจริง ๆ ก็อาจเขียนมันเป็นภาษาที่เครื่องตีความได้ไปเลยตั้งแต่แรกก็ได้

    • ถ้าถามคำถามแบบใช่/ไม่ใช่
      มันมีโอกาส 50% ที่จะตอบเท็จ
      มันเป็นลักษณะของมัน

    • ก่อนที่โมเดลจะเริ่มทำงานจริง ฉันมักให้มันถามคำถามพวกนี้ก่อน
      เช่น ถ้ามีจุดไม่แน่ใจให้ถามกลับ และให้ขอตัวอย่าง code pattern ที่ใช้งานอยู่แล้ว
      เพื่อให้มันอิงจาก template ที่มีใช้อยู่จริงเป็นตัวอย่าง

    • คนที่แค่คอสเพลย์เป็น data scientist ไม่ต้องการ evaluations
      เพราะฉะนั้นนอกจากผลิตภัณฑ์ที่ทำเงินจริง ๆ แล้ว ก็แทบไม่มีการประเมินผลกันเลย
      เพราะถ้าพูดว่า “จักรพรรดิเปลือย” มันจะไม่ทำเงิน
      แต่ถ้าเป็นงานที่ต้องใช้จริงในภาคปฏิบัติ การประเมินผลเป็นสิ่งที่ต้องมีแน่นอน