𝗥𝗔𝗚 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗳𝗼𝗿 𝗦𝗮𝗮𝗦 𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻𝘀 𝗨𝘀𝗶𝗻𝗴 𝗔𝗺𝗮𝘇𝗼𝗻 𝗕𝗲𝗱𝗿𝗼𝗰𝗸
การรันโปรดักชันชุดแรกบน Autowired.ai ของผมมีค่าใช้จ่ายสูงกว่างบประมาณถึง 3 เท่า
ผมส่งข้อความ OCR ทั้งหมดจากเอกสาร 200 ฉบับไปยัง frontier model เพื่อดึงข้อมูลในทุกๆ ฟิลด์ ซึ่งนั่นเป็นความผิดพลาด เพราะผมต้องจ่ายเงินให้กับข้อมูลที่โมเดลไม่ได้จำเป็นต้องใช้
ผมจึงออกแบบสถาปัตยกรรมใหม่และสามารถลดค่าใช้จ่ายลงได้ถึง 40% และนี่คือวิธีที่คุณสามารถทำแบบเดียวกันได้
- เลิกใช้ LLM กับทุกอย่าง
Textract นั้นยอดเยี่ยมมากในการดึงข้อมูลฟิลด์ที่มีโครงสร้างชัดเจน เช่น วันที่และยอดรวม แต่ผมกลับใช้ Bedrock เพื่อทำงานซ้ำในสิ่งที่ Textract ทำเสร็จไปแล้ว
ขั้นตอนการทำงานแบบใหม่แบ่งออกเป็น 3 ระยะ: • ใช้ Textract สำหรับงานส่วนใหญ่ • ส่งเฉพาะฟิลด์ที่ขาดหายไปไปยัง Bedrock เพื่อทำการเติมเต็มข้อมูล (gap-fill) • ใช้ Bedrock สำหรับการตรวจสอบความถูกต้องในขั้นตอนสุดท้าย (verification)
หาก Textract มีความมั่นใจสูง Bedrock ก็จะทำงานน้อยลง ซึ่งช่วยลดจำนวน token ของคุณลงได้ทันที
- ใช้ Prompt Caching
System prompt สำหรับการกำหนดฟิลด์และ schema นั้นเป็นค่าคงที่ และไม่มีการเปลี่ยนแปลงระหว่างเอกสารแต่ละฉบับ
Amazon Bedrock อนุญาตให้คุณทำ cache สำหรับ prompt เหล่านี้ได้ การเรียกใช้งานครั้งแรกในแต่ละ batch จะมีค่าใช้จ่ายเพิ่มขึ้นเล็กน้อย แต่การเรียกใช้งานครั้งต่อๆ ไปในช่วงเวลานั้นจะดึงข้อมูลจาก cache ซึ่งมีราคาเพียง 10% ของราคาปกติ วิธีนี้ช่วยลดต้นทุน input ของผมลงได้ถึง 20%
- กรอง context ของคุณ
อย่าส่งผลลัพธ์ OCR ทั้งหมดไปยัง Bedrock
• สำหรับการเติมเต็มข้อมูล (gap-fill): ส่งเฉพาะบล็อก OCR ที่เกี่ยวข้องกับฟิลด์ที่ขาดหายไปเท่านั้น • สำหรับการตรวจสอบ (verification): ส่งเฉพาะค่าที่ดึงออกมาได้ (extracted values) ไม่ใช่ข้อความ OCR ดิบ (raw OCR)
นอกจากนี้ ผมยังได้ปรับปรุง prompt ให้สะอาดขึ้น การตัดคำสั่งที่ซ้ำซ้อนออกช่วยลดขนาด prompt จาก 2,400 tokens เหลือเพียง 1,100 tokens โดยที่ความแม่นยำไม่ลดลงเลย
- เลือกโมเดลให้เหมาะสมกับงาน
อย่าใช้ Claude Sonnet กับทุกงาน เพราะ Sonnet มีราคาแพงกว่า Haiku ถึง 5 เท่า
ผมได้ทดสอบโมเดลกับงานเฉพาะด้านดังนี้: • การเติมเต็มข้อมูลในฟอร์มที่มีโครงสร้าง (Structured form gap-fill): Haiku มีความแม่นยำเพียง 2% เมื่อเทียบกับ Sonnet ผมจึงเปลี่ยนมาใช้ Haiku • สัญญาที่ไม่มีโครงสร้าง (Unstructured contracts): Haiku มีความแม่นยำน้อยกว่า ผมจึงใช้ Sonnet ต่อไป • การตรวจสอบ (Verification): Haiku ทำงานได้ดี ผมจึงเปลี่ยนมาใช้ Haiku
เลือกโมเดลตามความซับซ้อนของงาน ไม่ใช่ตามความต้องการของทั้งระบบ
- ใช้การทำ caching ในระดับแอปพลิเคชัน (application-layer caching)
ผมได้เพิ่ม cache ใน DynamoDB โดยใช้การทำ hash ของ schema และผลลัพธ์จาก Textract หากคุณรันชุดทดสอบเดิมซ้ำหลายครั้งในขณะที่กำลังปรับจูนโค้ด วิธีนี้จะช่วยลดการเรียกใช้งาน Bedrock ลงได้ถึง 80% ถึง 90%
สรุปสถาปัตยกรรมที่ชนะเลิศ: • Application cache เพื่อข้ามการเรียกใช้ Bedrock เมื่อมีการเรียกซ้ำ • Bedrock prompt cache สำหรับคำสั่งระบบ (system instructions) ที่เป็นแบบคงที่ • Model tiering เพื่อเลือกใช้ Haiku ในกรณีที่ทำได้ • Context filtering เพื่อส่งเฉพาะข้อมูลที่จำเป็นเท่านั้น
วัดจำนวน token ของคุณก่อนที่จะทำการปรับแต่ง (optimize) ข้อมูลจะแสดงให้เห็นว่าคุณกำลังเสียเงินไปกับส่วนไหนโดยไม่จำเป็น
แหล่งที่มา: https://dev.to/yogieee/rag-architecture-for-saas-applications-using-amazon-bedrock-10df
ชุมชนแห่งการเรียนรู้ (ไม่บังคับ): https://t.me/GyaanSetuAi