Prompt Engineering ไม่ใช่แค่ “การพิมพ์คำสั่งให้ AI” แต่คือกระบวนการออกแบบคำสั่งอย่างมีระบบ เพื่อทำให้โมเดลภาษา หรือ LLM สร้างผลลัพธ์ได้ตรง เป๊ะ มีเหตุผล และใช้งานได้จริงมากขึ้น เอกสารย้ำชัดว่าใคร ๆ ก็เขียน Prompt ได้ ไม่จำเป็นต้องเป็นวิศวกร AI แต่การเขียนให้ “ได้ผลดีจริง” ต้องอาศัยการทดลอง ปรับแต่ง และเข้าใจทั้งตัวโมเดล ค่าการตั้งค่า และรูปแบบภาษาที่ใช้ใน Prompt ด้วย
แก่นสำคัญ
เริ่มจากการอธิบายว่า LLM ทำงานแบบ ทำนาย token ถัดไป จากสิ่งที่มันเห็นมาก่อนหน้า ดังนั้นเวลาเราเขียน prompt เรากำลัง “จัดฉาก” ให้โมเดลเดาเส้นทางของคำตอบไปในทิศที่เราต้องการ ถ้า Prompt คลุมเครือ คำตอบก็อาจคลุมเครือ ถ้า Prompt มีบริบทดี โครงชัด เป้าหมายชัด ผลลัพธ์ก็จะดีขึ้นตามไปด้วย นี่คือเหตุผลว่าทำไม Prompt Engineering จึงเป็นเรื่องของ “คุณภาพของอินพุต” มากพอ ๆ กับความสามารถของโมเดลเอง
1) ก่อนเขียน Prompt ต้องเข้าใจว่า “โมเดล + การตั้งค่า” สำคัญพอ ๆ กับตัวคำสั่ง
หลังเลือกโมเดลแล้ว สิ่งที่ต้องปรับต่อคือพารามิเตอร์ของโมเดล เช่น ความยาว output, temperature, top-k, top-p เพราะสิ่งเหล่านี้มีผลโดยตรงต่อพฤติกรรมการตอบของ LLM ไม่ใช่มีแค่คำสั่งอย่างเดียวที่กำหนดคุณภาพผลลัพธ์
Output length หรือจำนวน token สูงสุด มีผลทั้งต่อค่าใช้จ่าย ความเร็ว และความสมบูรณ์ของคำตอบ เอกสารเตือนว่า ถ้าอยากได้คำตอบสั้น อย่าหวังว่าการลด token limit อย่างเดียวจะทำให้คำตอบ “กระชับขึ้นอย่างฉลาด” เพราะจริง ๆ มันแค่บังคับให้โมเดลหยุดเร็วขึ้นเท่านั้น หากอยากให้สั้นจริง ต้องเขียน Prompt กำกับรูปแบบคำตอบให้ชัดด้วย เช่น ขอเป็น 3 บรรทัด หรือ 5 bullet points เท่านั้น
Temperature คือระดับความสุ่มของการเลือกคำ ถ้าต่ำ คำตอบจะนิ่งและคาดเดาได้มาก เหมาะกับงานที่ต้องการความแม่น เช่น สรุปข้อมูล จัดหมวดหมู่ สกัดข้อมูล ถ้าสูงขึ้น คำตอบจะหลากหลายและสร้างสรรค์ขึ้น เหมาะกับงานไอเดีย งานเขียน หรือการระดมความคิด ส่วน top-k / top-p คือกลไกจำกัดชุดคำที่โมเดลมีสิทธิ์เลือกในแต่ละจังหวะ เพื่อควบคุมความสมดุลระหว่างความนิ่งกับความยืดหยุ่นของคำตอบ เอกสารชี้ว่าเวลาคำตอบติดลูป ซ้ำซาก หรือหลุดกรอบ บ่อยครั้งต้องแก้ที่ sampling settings ไม่ใช่แก้แต่ prompt อย่างเดียว
2) เทคนิคพื้นฐาน: Zero-shot คือเริ่มจากการสั่งตรง ๆ แบบไม่ให้ตัวอย่าง
เริ่มจาก General Prompting / Zero-shot ซึ่งเป็นรูปแบบพื้นฐานที่สุด คือบอกงานที่ต้องการให้ชัด โดยไม่ยกตัวอย่างประกอบ เหมาะสำหรับงานง่าย งานตรงไปตรงมา หรืองานที่โมเดลน่าจะเข้าใจรูปแบบอยู่แล้ว เช่น สรุปบทความ จัดประเภทรีวิว หรือแปลภาษา เอกสารอธิบายว่า zero-shot คือจุดเริ่มต้นที่ดี เพราะทำให้เห็นก่อนว่าโมเดล “เข้าใจโจทย์เองได้แค่ไหน” ก่อนจะเพิ่มความซับซ้อนทีหลัง
หลักคิดของ zero-shot คือ “พูดให้ชัดที่สุดเท่าที่จำเป็น” ไม่ต้องยาวเสมอไป แต่ต้องรู้ว่ากำลังขออะไร ใครคือกลุ่มเป้าหมาย และอยากได้ผลลัพธ์หน้าตาแบบไหน ถ้าตอบเพี้ยนหรือไม่เสถียร ค่อยขยับไปใช้ few-shot หรือเทคนิคอื่นแทน
3) One-shot และ Few-shot คือการ “สอนด้วยตัวอย่าง”
One-shot และ Few-shot Prompting ซึ่งใช้ตัวอย่างเพื่อให้โมเดลจับแพตเทิร์นได้ชัดขึ้น เอกสารยกตัวอย่างการแปลงคำสั่งสั่งพิซซ่าเป็น JSON โดยใส่ตัวอย่างออเดอร์กับผลลัพธ์ที่ถูกต้องให้โมเดลดูก่อน แล้วค่อยให้มันทำกับเคสใหม่ ผลคือรูปแบบคำตอบมีความสม่ำเสมอมากขึ้น
“คุณภาพของตัวอย่าง” สำคัญสุด ตัวอย่างต้องเกี่ยวข้องกับงานจริง มีความหลากหลาย และเขียนอย่างระวัง เพราะความผิดเล็ก ๆ ในตัวอย่างอาจทำให้โมเดลเรียนแบบสิ่งผิดนั้นไปด้วย นอกจากนี้ ถ้าอยากให้ระบบแข็งแรงกับข้อมูลจริง ควรใส่ edge cases หรือกรณีพิเศษที่ไม่ปกติลงไปด้วย เพื่อไม่ให้โมเดลพังเมื่อเจออินพุตแปลก ๆ ในภาคใช้งานจริง
4) ต้องแยกให้ออกระหว่าง System, Contextual และ Role Prompting
หนึ่งในส่วนที่มีประโยชน์มากคือการแยก 3 อย่างนี้ออกจากกันให้ชัด เพราะคนจำนวนมากมักใช้ปนกันโดยไม่รู้ตัว ได้แก่
System prompting คือการกำหนดกรอบใหญ่หรือภารกิจหลักของระบบ เช่น ให้ช่วยจัดหมวดหมู่ ให้สรุป หรือให้ตอบในรูปแบบตายตัว
Contextual prompting คือการใส่ข้อมูลพื้นหลังเฉพาะงาน เพื่อให้โมเดลเข้าใจสถานการณ์ปัจจุบัน
Role prompting คือการกำหนดบทบาทหรือบุคลิก เช่น ให้ตอบในมุมมองนักการตลาด อาจารย์ หรือวิศวกร
แม้ทั้งสามแบบจะซ้อนกันได้ แต่แต่ละแบบมีหน้าที่ไม่เหมือนกัน: system ใช้กำหนดภารกิจใหญ่, context เติมข้อมูลเฉพาะหน้า, role กำหนดโทน น้ำเสียง และลักษณะการตอบ
5) System prompting ช่วยควบคุมผลลัพธ์ให้แม่นและอยู่ในรูปแบบที่ต้องการ
ตัวอย่างในเอกสารแสดงให้เห็นว่าแค่เติมคำว่า “Only return the label in uppercase” ก็ทำให้โมเดลตอบสั้นและตรงอย่าง “NEGATIVE” โดยไม่พูดเกินจำเป็น นี่คือพลังของ system prompt ที่ไม่ได้สั่งแค่งาน แต่สั่ง วิธีส่งคำตอบกลับมาด้วย
อีกตัวอย่างหนึ่งคือการบอกให้ตอบเป็น valid JSON พร้อมกำหนด schema คร่าว ๆ ของฟิลด์ที่ต้องมี วิธีนี้มีประโยชน์มากกับงาน extraction หรือการส่งผลลัพธ์เข้า workflow ต่อ เช่น ระบบอัตโนมัติ, API, database หรือ no-code automation เพราะมันลดภาระการแปลงข้อมูลด้วยมือภายหลัง
6) Role prompting ช่วยเปลี่ยน “น้ำเสียง” และ “วิธีคิด” ของคำตอบ
Role prompting ไม่ได้เพิ่มข้อเท็จจริงใหม่ให้โมเดลเสมอไป แต่ช่วยปรับ “มุมมอง” และ “สไตล์การสื่อสาร” ของคำตอบให้เหมาะกับเป้าหมาย เช่น ถ้ากำหนดให้เป็นไกด์ท่องเที่ยวสายฮา คำตอบก็จะออกมามีบุคลิกสนุก มีสีสัน และชวนอ่านมากขึ้น เอกสารใช้ตัวอย่างคำแนะนำเที่ยว Manhattan ในโทนขำ ๆ เพื่อชี้ให้เห็นว่า role ช่วยกำหนด voice ได้ชัดมาก
ประเด็นสำคัญคือ role prompting เหมาะมากเมื่อเราไม่ได้ต้องการแค่ “ข้อมูลถูก” แต่ต้องการให้ “วิธีเล่า” เหมาะกับผู้ฟัง เช่น เขียนขาย, เขียนสอน, เขียนแบบที่ปรึกษา, เขียนในโทนผู้เชี่ยวชาญ หรือเขียนให้เด็กอ่านเข้าใจง่าย
7) Contextual prompting คือสิ่งที่ทำให้คำตอบ “เข้าเรื่อง” มากขึ้น
ตัวอย่าง ถ้าบอกเพิ่มว่า “กำลังเขียนให้บล็อกเกี่ยวกับเกมอาเขตยุค 80s” โมเดลจะเสนอหัวข้อบทความที่ตรงกับโลกของ retro arcade มากขึ้น ไม่ใช่คำตอบกว้าง ๆ เรื่องเกมทั่ว ๆ ไป นี่คือพลังของ contextual prompt ซึ่งช่วยลดความกำกวม และทำให้โมเดลหยิบสิ่งที่เกี่ยวข้องจริง ๆ ออกมาใช้
พูดง่าย ๆ คือ context ทำหน้าที่เหมือน “ฉากหลัง” ให้ AI รู้ว่าโจทย์นี้เกิดขึ้นที่ไหน สำหรับใคร และควรตีความอย่างไร ยิ่งงานเฉพาะทาง เช่น การตลาด การแพทย์ การเงิน กฎหมาย หรือสินค้าเฉพาะกลุ่ม การใส่ context จะยิ่งสำคัญมาก
8) Step-back Prompting: ถอยหลังหนึ่งก้าวเพื่อให้ตอบดีขึ้น
นี่เป็นเทคนิคที่น่าสนใจมาก อธิบายว่าแทนที่จะถามโจทย์เฉพาะเลย บางครั้งควรถามคำถามที่กว้างกว่าและเป็นหลักการก่อน เพื่อให้โมเดล “ระดมความรู้พื้นหลัง” ออกมาก่อน แล้วค่อยใช้คำตอบนั้นไปต่อยอดกับโจทย์จริง
ตัวอย่างที่ใช้คือ แทนที่จะสั่งให้เขียน storyline ของด่านเกมยิงเลย ก็ให้ถามก่อนว่า “มีองค์ประกอบสำคัญอะไรบ้างที่ทำให้ด่านเกมยิงน่าสนใจและท้าทาย” เมื่อโมเดลได้คิดเชิงนามธรรมก่อน คำตอบสุดท้ายมักมีโครงสร้างและคุณภาพดีกว่าเดิม วิธีนี้เหมาะกับงานวางกลยุทธ์ งานครีเอทีฟ งานวิเคราะห์ และงานที่ต้องการ “คิดก่อนทำ” มากกว่าสั่งให้ตอบตรง ๆ ทันที
9) Chain of Thought (CoT): ให้โมเดลคิดเป็นขั้นตอน
ตัวอย่างโจทย์อายุคนสองคนที่ถ้าถามตรง ๆ โมเดลอาจตอบผิด แต่เมื่อเติมคำว่า “Let’s think step by step” โมเดลเริ่มอธิบายลำดับการคิดทีละขั้น จนได้คำตอบที่ถูกต้อง คือ 26 ปีในตัวอย่างนั้น
จุดสำคัญของ CoT คือมันช่วยให้โมเดลไม่รีบเดาคำตอบสุดท้ายเร็วเกินไป แต่สร้างเส้นทางการให้เหตุผลขึ้นมาก่อน เทคนิคนี้เหมาะกับคณิตศาสตร์ ตรรกะ การตัดสินใจหลายชั้น การวิเคราะห์เอกสาร หรือโจทย์ที่ต้องแตกปัญหาเป็นส่วน ๆ เอกสารยังชี้ว่า CoT สามารถยกระดับได้อีกเมื่อรวมกับ one-shot หรือ few-shot โดยให้ตัวอย่างวิธีคิดที่ถูกต้องไปก่อน 1–2 ตัวอย่าง เพื่อให้โมเดลเดินตาม pattern การให้เหตุผลที่เราต้องการ
10) Self-consistency: ให้โมเดลคิดหลายทาง แล้วโหวตคำตอบที่เสถียรที่สุด
CoT แบบธรรมดามักใช้การ decode แบบนิ่ง ๆ เส้นทางเดียว แต่ Self-consistency จะส่ง Prompt เดียวกันหลายครั้งด้วยความสุ่มที่สูงขึ้น เพื่อให้เกิด “หลายเส้นทางการให้เหตุผล” จากนั้นจึงดึงคำตอบสุดท้ายของแต่ละรอบมาเทียบกัน แล้วเลือกคำตอบที่ปรากฏบ่อยที่สุด
แนวคิดนี้เหมือนการให้ทีมงานหลายคนช่วยกันคิด แล้วดูว่าข้อสรุปไหนตรงกันมากที่สุด ข้อดีคือเพิ่มโอกาสได้คำตอบที่แม่นและ coherent ขึ้น แต่ข้อเสียคือ แพงและกินทรัพยากร มากกว่า เพราะต้องรันหลายรอบ เอกสารยอมรับชัดว่ามันมีต้นทุนสูง จึงเหมาะกับโจทย์สำคัญที่ยอมแลกค่าใช้จ่ายเพื่อความมั่นใจได้
11) Tree of Thoughts (ToT): คิดแบบแตกกิ่งหลายทาง
ในสารบัญ ToT ถูกจัดเป็นอีกขั้นของการ reasoning โดยเป็นแนวคิดให้โมเดลสำรวจหลายทางเลือก หลายกิ่งของความคิด แล้วประเมินว่ากิ่งไหนน่าจะนำไปสู่คำตอบที่ดีที่สุด ก่อนเลือกเดินต่อในเส้นนั้น วิธีนี้เหมาะกับโจทย์ที่ไม่ได้มีแค่เส้นทางเดียว เช่น วางแผน แก้ปัญหาซับซ้อน ออกแบบกลยุทธ์ หรือเกมเชิงเหตุผลหลายขั้น แม้ส่วนที่ดึงมาได้จะไม่ได้ลงรายละเอียดทั้งหมด แต่เอกสารจัด ToT ไว้เป็นหนึ่งในเทคนิคสำคัญของการทำ reasoning prompt ขั้นสูง
12) ReAct: ให้โมเดล “คิด” และ “ลงมือทำ” ร่วมกัน
หนึ่งในส่วนที่ก้าวไปไกลกว่าการเขียน prompt แบบธรรมดาคือ ReAct (Reason + Act) ซึ่งเป็นแนวทางที่ให้ LLM ไม่เพียงคิดในภาษา แต่ยังเรียกใช้เครื่องมือภายนอก เช่น search, code interpreter, API หรือ agent tools ระหว่างทางได้ด้วย เอกสารอธิบายว่า ReAct ทำงานแบบวนลูป คิด → วางแผน → ลงมือทำ → สังเกตผล → คิดใหม่ → ทำต่อ จนกว่าจะได้คำตอบ
ตัวอย่างใช้ Python + LangChain + SerpAPI เพื่อให้โมเดลค้นเว็บหลายรอบและหาคำตอบเกี่ยวกับจำนวนลูกของสมาชิกวง Metallica นี่คือภาพของการก้าวจาก “prompt” ไปสู่ “agent behavior” หรือพฤติกรรมแบบผู้ช่วยที่ใช้เครื่องมือภายนอกแก้โจทย์ซับซ้อนได้ เอกสารจึงมอง ReAct ว่าเป็นก้าวแรกของ agent modeling อย่างแท้จริง
13) Automatic Prompt Engineering: ให้ระบบช่วยค้นหาพรอมป์ต์ที่ดีที่สุด
Automatic Prompt Engineering และในส่วนหนึ่งกล่าวถึงการประเมิน candidate prompts ด้วย metric อย่าง BLEU หรือ ROUGE เพื่อช่วยเลือกคำสั่งที่มีประสิทธิภาพกว่า วิธีคิดนี้สำคัญมากในงาน production เพราะแทนที่จะเดาเองทั้งหมด เราสามารถสร้างหลายเวอร์ชันของ Prompt ทดสอบกับชุดข้อมูล แล้ววัดผลอย่างเป็นระบบได้
พูดง่าย ๆ คือ prompt engineering ไม่ควรเป็นศิลปะล้วน ๆ แต่ควรถูกยกระดับให้เป็น กระบวนการทดลองและประเมินผล เหมือนงานวิศวกรรมจริง
14) งานเขียนโค้ดก็เป็นพื้นที่สำคัญของ Prompt Engineering
Code Prompting โดยแสดงตัวอย่างชัดเจน 4 แบบ คือ ให้โมเดลเขียนโค้ด, อธิบายโค้ด, แปลโค้ดข้ามภาษา, และช่วย debug/review โค้ด เอกสารใช้ตัวอย่าง Bash script สำหรับเปลี่ยนชื่อไฟล์ในโฟลเดอร์ แล้วให้โมเดลอธิบาย logic ของมัน แปลงเป็น Python และช่วยหาบั๊กพร้อมเสนอเวอร์ชันปรับปรุงให้
ประเด็นสำคัญที่เอกสารเตือนคือ ถึง AI จะช่วยเขียนโค้ดได้เร็วมาก แต่ผู้ใช้ต้อง อ่าน ทดสอบ และตรวจสอบก่อนใช้งานจริง เสมอ เพราะโค้ดอาจดูถูกต้องแต่ซ่อนบั๊กไว้ หรือไม่ครอบคลุม error handling พอ เอกสารชี้ว่าการ prompt ที่ดีในงานโค้ดควรบอกภาษา เป้าหมาย ข้อจำกัด สภาพแวดล้อม และสิ่งที่ต้องตรวจเป็นพิเศษด้วย
15) Best Practices: หลักปฏิบัติที่ทำให้พรอมป์ต์ดีขึ้นอย่างสม่ำเสมอ
ส่วนที่ใช้ได้จริงมาก เพราะรวบรวมแนวปฏิบัติสำคัญหลายข้อ เช่น
Provide examples — ถ้างานไม่เสถียร ให้ยกตัวอย่างที่ดีเข้าไป
Design with simplicity — อย่าเขียนรกเกินจำเป็น ใช้คำกริยาที่สื่อการกระทำชัด ๆ เช่น Analyze, Classify, Extract, Summarize, Translate, Write เป็นต้น
Be specific about the output — อย่าบอกกว้าง ๆ ว่า “เขียนบทความเรื่องเครื่องเกม” แต่ควรระบุว่าอยากได้กี่ย่อหน้า สไตล์ไหน น้ำเสียงแบบใด และเน้นประเด็นอะไร เพราะความเฉพาะเจาะจงช่วยให้โมเดลโฟกัสและลดความกำกวม
Use instructions over constraints — ให้ความสำคัญกับการบอกเชิงบวกว่าต้องการอะไร มากกว่าการลิสต์ยาว ๆ ว่า “ห้ามทำอะไรบ้าง” เพราะข้อห้ามจำนวนมากอาจขัดกันเอง และทำให้โมเดลเดาไม่ถูกว่าควรทำอะไรแทน มองว่าการสั่งเชิงบวกทำให้ผลลัพธ์ชัดกว่า เป็นธรรมชาติกว่า และปล่อยให้โมเดลสร้างสรรค์ภายในกรอบที่เรากำหนดได้ดีกว่า
Mix up classes in few-shot classification — ถ้าทำงานจัดหมวดหมู่ อย่าเรียงตัวอย่างเป็นแพตเทิร์นเดิมตลอด เช่น POSITIVE ก่อน NEGATIVE เสมอ เพราะโมเดลอาจจำลำดับแทนที่จะเรียนรู้คุณลักษณะของคลาสจริง ๆ แนะนำให้สลับตัวอย่าง และให้เริ่มทดสอบราว ๆ 6 examples เป็นกฎคร่าว ๆ ก่อน
Adapt to model updates — Prompt ที่เคยดี อาจไม่ดีที่สุดเมื่อโมเดลอัปเดตแล้ว เพราะ architecture, training data และความสามารถเปลี่ยนได้ จึงควรลองเวอร์ชันใหม่และปรับ prompt ให้เหมาะกับความสามารถล่าสุดของโมเดลอยู่เสมอ
16) Structured output สำคัญมาก โดยเฉพาะ JSON และ Schema
ความสำคัญกับการให้ผลลัพธ์ออกมาเป็น structured format เช่น JSON หรือ XML โดยเฉพาะงานที่ไม่ใช่งานสร้างสรรค์ เช่น extract, sort, parse, rank, categorize เพราะ structured output ช่วยให้คำตอบมีรูปแบบคงที่ ลด hallucination และเอาไปใช้ต่อในระบบจริงได้ง่ายขึ้น เอกสารสรุปประโยชน์ของ JSON ว่าได้รูปแบบสม่ำเสมอ โฟกัสเฉพาะข้อมูลที่ต้องการ ลดโอกาสมั่ว เห็น data types และนำไป sort/parse ต่อได้ง่าย
แต่ก็เตือนว่าการใช้ JSON มีต้นทุน เพราะกิน token มากกว่า plain text และถ้าคำตอบโดนตัดกลางทางจาก token limit อาจทำให้ JSON พังได้ เอกสารจึงแนะนำแนวคิด JSON Repair และยกตัวอย่างไลบรารีอย่าง json-repair บน PyPI เพื่อช่วยซ่อม JSON ที่ไม่สมบูรณ์จาก LLM output
ยิ่งไปกว่านั้น เอกสารยังพูดถึง JSON Schema สำหรับ “อินพุต” ด้วย ไม่ใช่แค่เอาต์พุต โดยบอกว่าถ้าเราจัดข้อมูลอินพุตให้มี schema ชัดเจน โมเดลจะเข้าใจโครงสร้าง ความสัมพันธ์ระหว่างฟิลด์ และข้อจำกัดของข้อมูลได้ดีขึ้น เช่น ชื่อสินค้า หมวด ราคา คุณสมบัติ วันที่เปิดตัว เป็นต้น วิธีนี้มีประโยชน์มากกับระบบ e-commerce, workflow automation, และการเชื่อม LLM เข้ากับระบบขนาดใหญ่
17) CoT ก็มี best practice ของมันเอง
ถ้าใช้ Chain of Thought ควรแยก “เหตุผล” ออกจาก “คำตอบสุดท้าย” ให้ชัด เพื่อให้ดึง final answer ออกมาใช้งานได้ง่าย และยังแนะนำว่าการใช้ CoT ควรตั้ง temperature = 0 เพราะงาน reasoning มักมีคำตอบที่ถูกต้องเพียงหนึ่งเดียว การเพิ่มความสุ่มมักไม่ช่วย
นี่เป็นหลักสำคัญมากสำหรับคนที่ใช้ AI วิเคราะห์โจทย์เชิงตรรกะหรือสกัดคำตอบเพื่อเอาไปใช้ต่อในระบบอัตโนมัติ
18) Prompt Engineering ต้อง “จดบันทึก”
หนึ่งในข้อแนะนำที่มีมุมวิศวกรรมมากที่สุดคือ ต้อง document prompt attempts เอกสารเสนอ template สำหรับเก็บชื่อ prompt, เป้าหมาย, โมเดล, temperature, token limit, top-k, top-p, ตัว prompt เต็ม และผลลัพธ์ที่ได้ รวมถึงควรบันทึกเวอร์ชัน, feedback, และสถานะว่า OK / NOT OK / SOMETIMES OK ด้วย
เหตุผลคือ output ของโมเดลเปลี่ยนได้จากหลายปัจจัย ทั้งเปลี่ยนโมเดล เปลี่ยน sampling settings หรือแม้แต่เวอร์ชันใหม่ของโมเดลเดิม ดังนั้นถ้าไม่จดไว้ เราจะย้อนกลับมาหาสาเหตุหรือทำซ้ำความสำเร็จเดิมได้ยากมาก เอกสารยังบอกต่อว่าถ้าใช้งานในระบบ RAG ก็ควรเก็บข้อมูลเรื่อง query, chunk settings, chunk output และองค์ประกอบที่มีผลต่อ prompt ด้วย เพราะทั้งหมดนี้ส่งผลต่อคุณภาพคำตอบ
สรุป
Prompt ที่ดี ไม่ได้เกิดจากการเขียนยาว แต่เกิดจากการออกแบบอย่างตั้งใจ
ต้องรู้ว่าจะให้โมเดลทำอะไร
ต้องรู้ว่าควรใส่บริบทหรือไม่
ต้องรู้ว่าเมื่อไรควรใช้ตัวอย่าง
ต้องรู้ว่าเมื่อไรควรให้โมเดลคิดเป็นขั้นตอน
และต้องรู้ว่าควรคุม output ด้วยโครงสร้างแบบใด
นอกจากนี้ ยังขยับมุมมองจาก “พรอมป์ต์เป็นประโยค” ไปสู่ “Prompt เป็นระบบงาน” คือมีทั้ง model settings, evaluation, structured output, schema, code integration, external tools และการ document เวอร์ชันต่าง ๆ ด้วย
ถ้ามองในเชิงปฏิบัติ เอกสารนี้ไม่ได้สอนแค่ “เขียนคำสั่งอย่างไร” แต่สอนวิธีคิดแบบมืออาชีพว่า
จะออกแบบ interaction กับ LLM อย่างไรให้เชื่อถือได้ วัดผลได้ และต่อยอดสู่การใช้งานจริงได้
บทความจาก
