Amazon Bedrock เพิ่ม Prompt Shortening ย่อคำสั่งเมื่อคะแนนประเมินไม่ลด

AWS ประกาศวันที่ 20 ตุลาคม 2026 ว่า Advanced Prompt Optimization ใน Amazon Bedrock เพิ่มตัวเลือก prompt shortening สำหรับลดความยาวของ prompt โดยใช้เกณฑ์ประเมินของทีมเองเป็นตัวตัดสิน ความต่างจากการสั่งโมเดลว่า “ช่วยย่อ prompt นี้” คือบริการจะส่ง prompt ที่ปรับแล้วกลับมาเฉพาะเมื่อมันสั้นกว่าต้นฉบับและได้คะแนนประเมินอย่างน้อยเท่าเดิม หากไม่ผ่านสองเงื่อนไขจะส่งต้นฉบับกลับมา กลไกนี้เหมาะกับทีมที่มี prompt ยาวซ้ำทุก request และต้องควบคุมต้นทุนหรือเวลาเริ่มตอบโดยไม่ยอมให้คุณภาพตกตามชุดประเมินที่กำหนด

ทำไมความยาว prompt จึงเป็นต้นทุน

หลายระบบใส่คำอธิบายบทบาท ข้อห้าม ตัวอย่าง และรูปแบบคำตอบไว้ใน system หรือ template เดิมทุกครั้ง เมื่อแอปมีทราฟฟิกสูง token ส่วนนี้สะสมเป็นค่าใช้จ่าย แม้ข้อความที่ผู้ใช้ส่งเข้ามาแต่ละรอบจะสั้น นอกจากนี้ input ที่ยาวอาจเพิ่มเวลาไปถึง token แรก ซึ่งสำคัญกับแชต งานค้นเอกสาร และ API ที่ผู้ใช้รอผลทันที ก่อนหน้านี้ Advanced Prompt Optimization มุ่งเพิ่มคุณภาพ และ prompt ที่ได้อาจยาวกว่าของเดิม ตัวเลือกใหม่จึงเพิ่มเป้าหมายเรื่องขนาดเข้าไปอย่างชัดเจน

ตามประกาศ AWS ตัวเลือกนี้เปิดต่อ prompt template ใน input dataset ของงาน optimization ผลลัพธ์จะแสดง compression ratio และจำนวน token ของ prompt เดิมกับ prompt ที่ปรับแล้ว ทั้งในไฟล์ output และหน้า console ตัวอย่างที่ AWS ให้คือ ratio 0.7 หมายถึง prompt ใหม่ใช้ token น้อยลง 30% ตัวเลขนี้เป็นสัดส่วนของ prompt ที่วัด ไม่ใช่คำรับประกันว่าบิลทั้งหมดของแอปจะลดลง 30% เพราะ request จริงยังมีข้อความผู้ใช้ บริบทที่ดึงมา และ output token ด้วย

การประเมินสำคัญกว่าการบีบข้อความ

เงื่อนไข “คะแนนไม่ต่ำกว่าเดิม” มีความหมายเท่ากับคุณภาพของชุดประเมินที่ทีมเตรียม หากทดสอบด้วยคำถามง่ายเพียงไม่กี่ข้อ optimizer อาจตัดคำสั่งที่จำเป็นสำหรับกรณีขอบออก โดยคะแนนชุดเล็กยังดูดี ทีมควรเลือกตัวอย่างที่ครอบคลุมภาษาไทยและภาษาอื่นที่ใช้จริง เอกสารยาว งานที่ข้อมูลขัดกัน คำขอที่ต้องปฏิเสธ และรูปแบบ output ที่ระบบปลายทางอ่าน ควรเก็บผลของ prompt เก่าไว้เป็น baseline ก่อนเริ่ม ไม่เช่นนั้นจะไม่รู้ว่าคำว่า “เท่าเดิม” เทียบกับอะไร

AWS ระบุว่าฟีเจอร์ทำงานกับวิธีประเมินหลายชนิด เช่น steering criteria, rubric ที่ใช้ LLM-as-a-judge และ custom Lambda evaluator วิธีสุดท้ายเปิดให้ทีมใส่ตัวตรวจของตนเอง เช่น JSON schema, คำตอบที่มีรหัสสินค้าอยู่ในฐานข้อมูล หรือการไม่เปิดเผยข้อมูลต้องห้าม หากใช้ LLM เป็นกรรมการอย่างเดียว ควรสุ่มให้มนุษย์ตรวจตัวอย่างที่ optimizer บอกว่าคะแนนดีขึ้น เพราะกรรมการอาจพลาดเงื่อนไขเฉพาะโดเมน ทีมที่มี workflow หลายขั้นควรวัดผลปลายทางด้วย ไม่ดูแค่ความสวยของคำตอบโมเดลขั้นแรก

ขั้นตอนทดลองที่เสี่ยงต่ำ

เริ่มกับ prompt template ที่เรียกบ่อยและมีขนาดใหญ่หนึ่งตัว เก็บ latency, จำนวน input token, output token และอัตรางานสำเร็จในช่วงก่อนเปลี่ยน จากนั้นเปิด prompt shortening ใน input dataset แล้วรัน optimization job ตามขั้นตอนเดิม อ่านผลลัพธ์ที่ได้ว่ามี prompt ใหม่หรือคืนต้นฉบับ พร้อมตรวจ compression ratio และข้อความที่ถูกตัดจริง หากส่วนที่ตัดเป็นข้อจำกัดด้านความปลอดภัยหรือภาษาที่จำเป็น แม้คะแนนผ่านก็ควรเพิ่มกรณีทดสอบก่อนนำไปใช้

เมื่อนำไป production ให้ใช้ rollout เป็นสัดส่วนเล็กและผูก version ของ prompt กับ log เพื่อย้อนกลับได้ การเปลี่ยน prompt อาจกระทบแอปโดยไม่มีการเปลี่ยนโค้ด จึงควรปฏิบัติเหมือนการ deploy เฝ้าดูอัตราผู้ใช้ต้องถามซ้ำ อัตราคำตอบผิดรูปแบบ และค่าใช้จ่ายต่อผลลัพธ์ที่สำเร็จ ไม่ใช่ต้นทุนต่อ request อย่างเดียว ฟีเจอร์นี้พร้อมใช้ใน AWS Regions ที่มี Advanced Prompt Optimization ตามประกาศ แต่ทีมควรตรวจ Region และค่าใช้จ่ายของบริการจริงก่อนเปิดงานขนาดใหญ่

อ่านประกาศต้นทางวันที่ 20 ตุลาคม 2026: AWS What's New