Kiến trúc RAG cho các ứng dụng SaaS sử dụng Amazon Bedrock
Đợt chạy production đầu tiên trên Autowired.ai của tôi tốn gấp 3 lần ngân sách dự kiến.
Tôi đã gửi toàn bộ văn bản OCR từ 200 tài liệu đến một mô hình tiên tiến (frontier model) cho từng trường dữ liệu một. Đó là một sai lầm. Tôi đã phải trả tiền cho những dữ liệu mà mô hình không hề cần đến.
Tôi đã thiết kế lại kiến trúc và cắt giảm được 40% chi phí. Dưới đây là cách bạn có thể làm điều tương tự.
- Ngừng sử dụng LLM cho mọi thứ
Textract cực kỳ xuất sắc trong việc trích xuất các trường có cấu trúc như ngày tháng và tổng số. Tôi đã từng dùng Bedrock để làm lại những việc mà Textract đã hoàn thành xong.
Quy trình mới sử dụng ba giai đoạn: • Sử dụng Textract cho phần lớn công việc. • Chỉ gửi các trường còn thiếu đến Bedrock để thực hiện lệnh điền khuyết (gap-fill). • Sử dụng Bedrock cho lệnh xác minh cuối cùng.
Nếu Textract có độ tin cậy cao, Bedrock sẽ phải làm ít việc hơn. Điều này giúp giảm ngay lập tức số lượng token của bạn.
- Sử dụng Prompt Caching
Các system prompt cho định nghĩa trường và schema là cố định. Chúng không thay đổi giữa các tài liệu.
Amazon Bedrock cho phép bạn lưu bộ nhớ đệm (cache) các prompt này. Lần gọi đầu tiên trong một batch sẽ phải trả thêm một khoản phí nhỏ. Mọi lần gọi tiếp theo trong khoảng thời gian đó sẽ truy cập cache với mức giá chỉ bằng 10% so với bình thường. Điều này đã giúp tôi giảm 20% chi phí đầu vào.
- Lọc ngữ cảnh (context) của bạn
Đừng gửi toàn bộ phản hồi OCR đến Bedrock.
• Đối với việc điền khuyết (gap-fill): Chỉ gửi các khối OCR cụ thể liên quan đến các trường còn thiếu. • Đối với việc xác minh: Chỉ gửi các giá trị đã trích xuất, không phải OCR thô.
Tôi cũng đã tối ưu hóa các prompt của mình. Việc loại bỏ các hướng dẫn thừa thãi đã giúp giảm kích thước prompt từ 2.400 token xuống còn 1.100 token mà không làm giảm độ chính xác.
- Chọn mô hình phù hợp với tác vụ
Đừng dùng Claude Sonnet cho mọi tác vụ. Sonnet đắt gấp 5 lần so với Haiku.
Tôi đã thử nghiệm chúng trên các tác vụ cụ thể: • Điền khuyết biểu mẫu có cấu trúc: Haiku chỉ đạt 2% độ chính xác so với Sonnet. Tôi đã chuyển sang dùng Haiku. • Hợp đồng không cấu trúc: Haiku kém chính xác hơn. Tôi giữ lại Sonnet. • Xác minh: Haiku hoạt động tốt. Tôi đã chuyển sang dùng Haiku.
Hãy chọn mô hình dựa trên độ phức tạp của tác vụ, chứ không phải dựa trên toàn bộ hệ thống.
- Triển khai caching ở tầng ứng dụng
Tôi đã thêm một bộ nhớ đệm (cache) trong DynamoDB bằng cách sử dụng mã hash của schema và đầu ra từ Textract. Nếu bạn chạy cùng một bộ dữ liệu kiểm thử nhiều lần trong khi tinh chỉnh mã nguồn, việc này sẽ loại bỏ được 80% đến 90% các lệnh gọi đến Bedrock.
Tóm tắt kiến trúc chiến thắng: • Application cache để bỏ qua Bedrock khi có các yêu cầu lặp lại. • Bedrock prompt cache cho các chỉ dẫn hệ thống tĩnh. • Phân tầng mô hình (Model tiering) để sử dụng Haiku bất cứ khi nào có thể. • Lọc ngữ cảnh (Context filtering) để chỉ gửi những dữ liệu cần thiết.
Hãy đo lường lượng token của bạn trước khi tối ưu hóa. Dữ liệu sẽ cho bạn thấy bạn đang lãng phí tiền ở đâu.
Nguồn: https://dev.to/yogieee/rag-architecture-for-saas-applications-using-amazon-bedrock-10df
Cộng đồng học tập (tùy chọn): https://t.me/GyaanSetuAi