Giới thiệu
Bài viết này khởi động một chuỗi chia sẻ về những bài học mà tôi đã rút ra từ vai trò lãnh đạo AI trong một FinTech. Trong vài tháng qua, tôi đã tham gia vào việc phát triển một sản phẩm Xử lý Tài liệu Thông minh (IDP) nhằm xử lý các chứng từ thanh toán. Mục tiêu của chúng tôi là trích xuất thông tin có cấu trúc từ các tệp PDF và hình ảnh một cách đáng tin cậy và có khả năng mở rộng.
Để tăng tốc độ phát triển, chúng tôi đã chọn sử dụng AWS Bedrock Data Automation (BDA). Công cụ này đã mang lại cho chúng tôi những kết quả tốt, nhưng cũng tiết lộ những hạn chế không ngờ tới. Dưới đây là ba thách thức mà chúng tôi đã gặp phải, kèm theo những kết quả tích cực từ BDA và những cạm bẫy mà chúng tôi đã phát hiện trong quá trình sử dụng thực tế.
Tại sao chúng tôi chọn BDA?
BDA là một dịch vụ của AWS được thiết kế để tự động hóa việc trích xuất dữ liệu từ tài liệu và hình ảnh. Một tính năng hữu ích cho trường hợp sử dụng của chúng tôi là khả năng tạo blueprints, các tài liệu mô tả cách dữ liệu nên được trích xuất, chuẩn hóa và định dạng. BDA cung cấp hai lựa chọn để tạo blueprints:
- Thủ công (thông qua JSON Schema): nhà phát triển định nghĩa toàn bộ cấu trúc.
- Tự động (thông qua prompt): chỉ cần viết bằng ngôn ngữ tự nhiên các trường cần trích xuất và cách xử lý chúng.
Lựa chọn thứ hai có vẻ hấp dẫn và dễ dàng. Chúng tôi nhanh chóng có các blueprints hoạt động và kết quả đáng hứa hẹn trong việc trích xuất dữ liệu từ các chứng từ thanh toán. Sự thuận tiện này, cùng với các bản cập nhật thường xuyên trong quá trình phát triển, đã thuyết phục chúng tôi theo đuổi con đường này.
Mọi thứ dường như diễn ra suôn sẻ. Chức năng đã được đưa vào môi trường sản xuất, chúng tôi đang thực hiện các hoạt động trích xuất như mong đợi. Tuy nhiên, vào một thời điểm nào đó, chúng tôi đã phát hiện ra một sự bất thường về chi phí và sau một phân tích kỹ lưỡng về hành vi, chúng tôi đã gặp phải một số vấn đề chưa được phát hiện trong quá trình phát triển.
Cạm bẫy #1 – Blueprints tạo ra bằng prompt luôn là Tài liệu
Một điều mà chúng tôi đã mất thời gian để nhận ra là: tất cả các blueprint được tạo ra bằng prompt đều được xử lý như Tài liệu, ngay cả khi tài liệu gốc cho blueprint đó là hình ảnh. Trong quá trình thử nghiệm và trong thời gian phát triển, đặc điểm này đã không được chú ý và không gây ra bất kỳ tác động nào rõ ràng đến các trích xuất và thử nghiệm của chúng tôi.
Tuy nhiên, đặc điểm này đã ảnh hưởng đến chúng tôi sau đó, nhưng theo cách rất nghiêm trọng: gây ra sự bất thường về chi phí!
Cạm bẫy #2 – Cấu hình sai và tác động tài chính
BDA có tính năng định tuyến theo loại hình, xác định xem một tệp sẽ được xử lý như tài liệu hay hình ảnh. Mặc dù có vẻ chỉ là một cấu hình kỹ thuật, nhưng cấu hình này có tác động trực tiếp đến chi phí của giải pháp, vì AWS tính phí như sau:
- Tài liệu: USD 0,040 mỗi trang.
- Hình ảnh: USD 0,005 mỗi hình.
Vì chúng tôi đã tạo các blueprints qua prompt, tất cả đều được xử lý như Tài liệu. Trong quá trình thử nghiệm, chúng tôi không nhận thấy sự khác biệt, nhưng vào tháng Tám, điều tồi tệ nhất đã xảy ra: gần USD 1.000 chi phí bổ sung trong hóa đơn.
Sau khi điều tra hành vi, chúng tôi đã hiểu lý do: các blueprints được tạo tự động không tuân theo loại hình hình ảnh. Sau khi xác định nguyên nhân, giải pháp là tạo lại chúng một cách thủ công bằng JSON Schema, cấu hình đúng loại Tài liệu hoặc Hình ảnh, cũng như kích hoạt cấu hình định tuyến.
Nhận ra các sai sót và chuẩn bị tốt hơn để tránh những lỗi này là điều giúp chúng tôi trưởng thành. Tôi thừa nhận rằng chúng tôi có thể đã nhanh chóng hơn trong việc xác thực hành vi này và đảm bảo những gì chúng tôi mong đợi, nhưng sự chỉ trích đối với AWS vẫn còn: tài liệu không làm nổi bật một chi tiết quan trọng như vậy. Sự thiếu rõ ràng này có thể gây ra thiệt hại.
Cạm bẫy #3 – Độ trễ trung bình 30 giây
Điểm thứ ba là độ trễ. Mỗi lần xử lý trên BDA mất khoảng 30 giây.
Trong kiến trúc, chúng tôi đã xử lý tốt điều này. Chúng tôi đã triển khai các luồng bất đồng bộ dựa trên sự kiện, cho phép chờ đợi mà không làm tắc nghẽn hệ thống. Tuy nhiên, từ góc độ người dùng, 30 giây được cảm nhận như là sự chậm chạp.
Khách hàng gửi một chứng từ cần phải chờ nửa phút trước khi nhận được phản hồi. Để giảm thiểu, chúng tôi đã điều chỉnh ứng dụng của mình, nhưng việc so sánh với các lựa chọn thay thế là điều không thể tránh khỏi. Trong một số trường hợp, các pipeline với Textract + LLM hoặc OCR + xử lý hậu có thể đạt được độ trễ thấp hơn, với chi phí tương đương.
Những điểm tích cực của BDA
Mặc dù gặp nhiều khó khăn, BDA mang lại nhiều lợi ích rõ ràng:
- Trừu tượng hóa độ phức tạp: chúng tôi không bắt đầu từ con số không trong việc xây dựng IDP.
- Tốc độ ban đầu: chúng tôi nhanh chóng đưa ra một nguyên mẫu vào sản xuất.
- Tiếp cận dễ dàng: các nhóm nhỏ có thể thử nghiệm IDP mà không cần xây dựng toàn bộ cơ sở hạ tầng.
Trong trường hợp của chúng tôi, BDA đã đóng vai trò như một bộ tăng tốc ban đầu. Nếu không có BDA, chúng tôi sẽ mất nhiều thời gian hơn để phát hành phiên bản đầu tiên. Điểm quan trọng là biết khi nào nó có ý nghĩa và khi nào các lựa chọn khác là ưu việt hơn.
Kết luận
Sau ba tháng sử dụng, đây là những bài học chính mà chúng tôi đã rút ra:
- Blueprints tạo ra bằng prompt luôn là Tài liệu.
- Cấu hình sai có thể làm tăng chi phí.
- Độ trễ 30 giây ảnh hưởng đến trải nghiệm người dùng.
Những điểm này không xuất hiện rõ ràng trong tài liệu. Chỉ có thực tiễn mới cho thấy tác động của chúng. Điều này củng cố một bài học quan trọng: lãnh đạo trong AI yêu cầu cả sự nhiệt tình với các giải pháp mới và sự nhạy bén để đánh giá các lựa chọn.
BDA có giá trị, nhưng không phải là giải pháp toàn năng. Biết khi nào nên áp dụng và khi nào nên thay thế là một phần của sự trưởng thành về mặt kỹ thuật.
Trong các bài viết tiếp theo, tôi dự định chia sẻ thêm những kinh nghiệm từ các dự án AI trong lĩnh vực tài chính. Hy vọng rằng những thông tin này sẽ giúp tránh được những cạm bẫy tương tự và truyền cảm hứng cho những quyết định hợp lý hơn.
