AWS เพิ่ม RAG แบบครั้งเดียวและโหมดดึงข้อมูลอย่างเดียวใน Bedrock

Amazon Web Services ประกาศเมื่อวันที่ 9 พฤศจิกายน 2026 ว่า Amazon Bedrock Managed Knowledge Base รองรับการสร้างเนื้อหาเสริมด้วยการดึงข้อมูล (RAG) แบบครั้งเดียว และคำขอที่ส่งคืนเฉพาะข้อความตอนผ่าน AgenticRetrieveStream. ช่วงค่าที่ขยายเป็น 0–5 สำหรับ maxAgentIteration ช่วยให้แอปพลิเคชันเลือกได้ว่าจะดึงแหล่งข้อมูล สร้างคำตอบจากการค้นหาเพียงครั้งเดียว หรือใช้การดึงข้อมูลแบบเอเจนต์หลายขั้นตอนที่บริการมีอยู่เดิม

การอัปเดตนี้นำรูปแบบ RAG พื้นฐาน ซึ่งดึงข้อมูลหนึ่งครั้งแล้วสร้างคำตอบตามมา มาไว้ใน API แบบสตรีมเดียวกับที่ใช้ค้นหาข้อมูลซับซ้อน RAG แบบครั้งเดียวใช้การเรียกโมเดลพื้นฐานหนึ่งครั้งเพื่อสร้างคำตอบ ส่วนคำขอที่ดึงข้อมูลอย่างเดียวจะไม่เรียกใช้โมเดลเลย AWS ระบุว่าการทำงานแบบครั้งเดียวอาจลดเวลาแฝงและการใช้งานโมเดลเมื่อเทียบกับการดึงข้อมูลแบบเอเจนต์ แต่ประกาศนี้ไม่ได้ให้ผลเปรียบเทียบเวลาแฝงหรือต้นทุนที่วัดได้

พารามิเตอร์เดียวใช้เลือกโหมดการดึงข้อมูล

ค่า 0 จะส่งคืนข้อความตอนที่ตรงกันโดยไม่สร้างคำตอบ ส่วนค่า 1 จะดึงข้อมูลหนึ่งครั้งและสร้างคำตอบโดยใช้ generateResponse=true; ส่วนค่า 2 ถึง 5 จะคงการทำงานแบบเอเจนต์ที่มีอยู่เดิมไว้ ทุกโหมดรองรับฐานความรู้หลายฐาน ดังนั้นคำว่า “ครั้งเดียว” ในที่นี้หมายถึงการดึงข้อมูลหนึ่งครั้ง ไม่ได้จำกัดให้ใช้ฐานความรู้ได้เพียงฐานเดียว

การวนรอบหนึ่งครั้งหมายถึงการเรียกโมเดลพื้นฐานหนึ่งครั้ง เมื่อเปิดใช้การสร้างคำตอบ การกำหนดขีดจำกัดไว้ที่ n จะกันการเรียกครั้งสุดท้ายไว้สำหรับสร้างคำตอบ และอนุญาตให้มีรอบ n ลบ 1 รอบสำหรับวางแผน แต่ละรอบวางแผนจะจับคู่การเรียบเรียงคำค้นใหม่กับการดึงข้อมูลหนึ่งครั้ง ส่วนการดึงข้อมูลเชิงคาดการณ์เบื้องต้นจะทำก่อนการวางแผน และไม่นับรวมในขีดจำกัด

เมื่อกำหนดค่าเป็น 0 ต้องปิดการสร้างคำตอบ หากเปิดใช้ ระบบจะแสดงข้อผิดพลาด 4xx เพราะการสร้างคำตอบจำเป็นต้องเรียกใช้โมเดล เมื่อกำหนดค่าเป็น 1 สตรีมจะส่งผลการดึงข้อมูลหนึ่งครั้งและคำตอบที่อ้างอิงข้อมูลหนึ่งคำตอบ โดยไม่มีเหตุการณ์ที่แสดงร่องรอยการวางแผน คำขอเดิมที่ใช้ค่า 2 ถึง 5 จะไม่เปลี่ยนแปลง

การทำงานของสตรีมและข้อจำกัดในการใช้งาน

เอกสารอ้างอิง API ของ AgenticRetrieveStreamระบุว่า messages, retrieversและ agenticRetrieveConfiguration เป็นข้อมูลนำเข้าที่จำเป็นสำหรับคำขอ ขณะที่ generateResponse เป็นข้อมูลที่ไม่บังคับ ระบบจะส่งส่วนคำตอบที่สร้างขึ้นก็ต่อเมื่อเปิดใช้การสร้างคำตอบเท่านั้น ผลลัพธ์สุดท้ายอาจประกอบด้วยรายการที่ดึงมา คำตอบที่สังเคราะห์ขึ้น และการอ้างอิงที่เชื่อมโยงข้อความบางช่วงในคำตอบกับผลลัพธ์ที่ใช้สนับสนุน

การทำงานแบบดึงข้อมูลอย่างเดียวเทียบเท่ากับการเรียกใช้ Retrieve โดยตรง แต่รูปแบบการตอบกลับแตกต่างกัน โดยข้อความตอนจะปรากฏในเหตุการณ์ result ของสตรีม โดยไม่มี score หรือ location ฟิลด์ แอปพลิเคชันที่ใช้ AgenticRetrieveStream อยู่แล้วจึงสามารถรับ Retrieveรูปแบบการทำงานได้ด้วยการเปลี่ยนพารามิเตอร์ แทนการผสานรวม API แยกต่างหาก

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

ทีมพัฒนาแอปพลิเคชันเลือกและทดสอบโหมดการทำงาน

AWS ยกตัวอย่างการตั้งค่าด้วยผู้ช่วยตอบคำถามเกี่ยวกับนโยบายภายในของธนาคารสมมติ ไม่ใช่การใช้งานจริงของลูกค้า คำถามเกี่ยวกับเอกสารสำหรับผู้ประกอบการรายเดียวใช้ maxAgentIteration=1ส่วนคำถามเปรียบเทียบข้อกำหนดสำหรับผู้ประกอบการรายเดียวกับบริษัทจำกัด (LLC) ซึ่งตรวจสอบกฎสำหรับเจ้าของที่ไม่มีถิ่นที่อยู่ด้วย จะใช้ค่า 4 ซึ่งอนุญาตให้มีรอบวางแผนได้สูงสุดสามรอบ ส่วนคำขอให้ตรวจสอบถ้อยคำในนโยบายจะใช้ค่า 0 และส่งคืนข้อความต้นฉบับโดยไม่มีบทสรุป

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

สำหรับการนำไปใช้งาน AWS แนะนำให้เปรียบเทียบ RAG แบบครั้งเดียวกับการตั้งค่าแบบเอเจนต์ที่มีอยู่เดิมบนฐานความรู้เดียวกัน โดยใช้คำถามที่เป็นตัวแทนและคำตอบที่คาดหวัง การประเมินควรวัดเวลาแฝงและต้นทุนต่อคำขอ ตรวจสอบความถูกต้องและหลักฐานสนับสนุนในข้อความตอนที่ดึงมา และรวมคำถามที่ต้องใช้ข้อมูลจากหลายเอกสาร รวมถึงคำถามที่ตอบไม่ได้ ผลการประเมินดังกล่าวช่วยเลือกขีดจำกัดจำนวนรอบที่ต่ำที่สุดซึ่งยังตอบสนองข้อกำหนดด้านคุณภาพของแต่ละเวิร์กโฟลว์ได้

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