Giới thiệu
Bài viết này bắt đầu một chuỗi các bài viết mà tôi chia sẻ những bài học đã rút ra từ vai trò lãnh đạo AI tại một FinTech. Trong vài tháng qua, tôi đã tham gia xây dựng một sản phẩm Xử lý Tài liệu Thông minh (IDP) tập trung vào việc xử lý biên lai 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ừ PDF và hình ảnh một cách đáng tin cậy và quy mô.
Để tăng tốc độ phát triển, chúng tôi đã dựa vào Tự động hóa Dữ liệu AWS Bedrock (BDA). Công cụ này đã mang lại một số kết quả tốt, nhưng cũng tiết lộ những hạn chế không ngờ. Dưới đây, tôi sẽ chia sẻ ba thách thức mà chúng tôi đã gặp phải—không bỏ qua những điều tích cực: thừa nhận những điểm mạnh của BDA trong khi chỉ ra những cạm bẫy mà chúng tôi đã gặp phải trong thực tế.
Tại sao chúng tôi chọn BDA
BDA là một dịch vụ 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 chính cho trường hợp sử dụng của chúng tôi là khả năng tạo ra các blueprint (kế hoạch), các đối tượng xác định 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 phương pháp để tạo blueprint:
- Thủ công (thông qua JSON Schema): lập trình viên xác định rõ cấu trúc.
- Tự động (thông qua prompt): mô 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.
Tùy chọn thứ hai dường như khó có thể cưỡng lại. Hầu như ngay lập tức, chúng tôi đã có các blueprint hoạt động với các đầu ra hứa hẹn cho việc trích xuất biên lai thanh toán. Sự thuận tiện đó—kết hợp với các bản cập nhật thường xuyên mà AWS phát hành trong quá trình phát triển—đã thuyết phục chúng tôi đi theo con đường này.
Mọi thứ dường như ổn vào đầu. Chức năng đã hoạt động trong sản xuất và việc trích xuất dữ liệu diễn ra như mong đợi. Nhưng cuối cùng, chúng tôi đã gặp phải một bất thường về chi phí, và sau khi phân tích sâu hơn về hành vi của hệ thống, chúng tôi đã phát hiện ra những vấn đề đã bị bỏ qua trong quá trình phát triển.
Cạm bẫy #1 – Blueprint được tạo qua Prompt luôn là loại Tài liệu
Một điều mà chúng tôi mất một thời gian để nhận ra: mọi blueprint được tạo qua prompt đều được phân loại là Tài liệu, ngay cả khi nội dung cơ bản thực sự là một hình ảnh. Trong quá trình thử nghiệm và phát triển, đặc điểm này đã không được chú ý vì nó không có vẻ ảnh hưởng đến độ chính xác của việc trích xuất dữ liệu.
Tuy nhiên, sau đó, nó đã quay lại cắn chúng tôi—lần này dưới dạng một bất thường về chi phí.
Cạm bẫy #2 – Định dạng sai và Tác động tài chính
BDA có một tính năng gọi là modality routing, xác định xem một tệp có được xử lý như một tài liệu hay hình ảnh. Mặc dù có vẻ như là một chi tiết kỹ thuật nhỏ, nhưng cài đặt này ảnh hưởng trực tiếp đến chi phí:
- Tài liệu: 0.040 USD mỗi trang
- Hình ảnh: 0.005 USD mỗi hình ảnh
Vì tất cả các blueprint của chúng tôi đều được tạo ra qua prompt, mọi thứ đều được xử lý như Tài liệu. Trong các thử nghiệm đầu tiên, chúng tôi không nhận thấy sự khác biệt. Nhưng đến tháng Tám, thực tế đã đến: gần 1.000 USD trong các khoản phí bất ngờ.
Sau khi điều tra, chúng tôi hiểu lý do: các blueprint tự động không tuân theo định dạng hình ảnh. Giải pháp là tạo lại chúng một cách thủ công bằng cách sử dụng JSON Schema, cấu hình đúng giữa Tài liệu và Hình ảnh, và kích hoạt routing.
Tôi sẽ nhận phần trách nhiệm này: chúng tôi có thể đã xác thực hành vi này sớm hơn. Nhưng phê bình về AWS vẫn là—tài liệu không làm nổi bật rõ ràng hạn chế này. Sự thiếu rõ ràng đó có thể dẫn đến những sai lầm tốn kém.
Cạm bẫy #3 – Độ trễ trung bình 30 giây
Vấn đề thứ ba là độ trễ. Mỗi quy trình BDA mất khoảng 30 giây trung bình.
Từ góc độ kiến trúc, điều này là có thể quản lý. Chúng tôi đã xây dựng hệ thống xung quanh các luồng sự kiện bất đồng bộ, vì vậy backend có thể xử lý độ trễ. Nhưng từ góc độ người dùng, 30 giây cảm thấy thật chậm chạp.
Khi một khách hàng tải lên một biên lai, việc phải chờ nửa phút để nhận kết quả làm giảm trải nghiệm. Để giải quyết điều này, chúng tôi đã điều chỉnh ứng dụng, nhưng tự nhiên chúng tôi cũng so sánh các lựa chọn thay thế. Trong một số trường hợp, các pipeline sử dụng Textract + LLMs hoặc OCR + xử lý hậu đã cung cấp kết quả tương tự với độ trễ thấp hơn và chi phí tương đương.
Những điểm tích cực của BDA
Mặc dù có những thách thức này, BDA vẫn mang lại những lợi ích thực sự:
- Giảm bớt độ phức tạp: chúng tôi không cần phải xây dựng một pipeline IDP từ đầu.
- Giao hàng nhanh chóng: chúng tôi đã nhanh chóng triển khai một nguyên mẫu hoạt động.
- Rào cản gia nhập thấp: các nhóm nhỏ có thể thử nghiệm với IDP mà không cần đầu tư hạ tầng nặng nề.
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ó nó, việc ra mắt phiên bản đầu tiên sẽ mất nhiều thời gian hơn. Bài học chính là biết khi nào nên dựa vào nó và khi nào các phương pháp thay thế có thể hiệu quả hơn.
Kết luận
Sau ba tháng với AWS Bedrock Data Automation, đây là những điểm rút ra chính của chúng tôi:
- Blueprint được tạo qua prompt luôn là loại Tài liệu.
- Cài đặt modality không chính xác có thể dẫn đến vượt chi phí lớn.
- Độ trễ 30 giây làm hại trải nghiệm người dùng.
Những vấn đề này không được nêu rõ trong tài liệu. Chỉ có sử dụng thực tế mới phơi bày chúng. Đối với tôi, điều này nhấn mạnh một bài học quan trọng: lãnh đạo AI không chỉ yêu thích các giải pháp mới mà còn cần tư duy phản biện để đánh giá các đánh đổi.
BDA có giá trị, nhưng nó không phải là giải pháp phổ quát. Biết khi nào nên áp dụng nó—và khi nào nên thay thế nó—là một phần của sự trưởng thành kỹ thuật.
Trong các bài viết sắp tới, tôi dự định chia sẻ thêm 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 hiểu biết này sẽ giúp người khác tránh được những cạm bẫy tương tự và đưa ra quyết định thông minh hơn.
