Ngừng coi LLM là công cụ giải quyết mọi vấn đề: Bài học từ thực tế

Gần đây, tôi đã làm việc trên một tính năng yêu cầu chuyển đổi 100 file PDF về tuân thủ quy định (compliance) khá lộn xộn thành các quy tắc JSON có cấu trúc.

Cách tiếp cận "vét cạn" (brute force) đầu tiên rất rõ ràng: đưa văn bản nguồn cho tác nhân AI (agent), giải thích nhiệm vụ, cung cấp ví dụ và yêu cầu nó tạo ra các quy tắc. Vì đây là cách dễ làm nhất, tôi đã thử nó trước.

Thoạt nhìn, kết quả có vẻ ổn. Đầu ra JSON hợp lệ và khớp với mong đợi. Tuy nhiên, khi tôi lấy mẫu thủ công để kiểm tra độ chính xác, những lỗi tiềm ẩn bắt đầu lộ ra. Một số quy tắc quá rộng, một số khác bị bỏ sót. Một số quy tắc không giữ được sắc thái của văn bản gốc. Tôi đã thử dùng một agent khác để bắt và sửa lỗi, nhưng với khối dữ liệu khổng lồ như vậy, việc xác nhận chắc chắn kết quả là bất khả thi.

Điều gây thất vọng nhất là những lỗi này không rõ ràng. Đây là một cách triển khai quá mong manh để có thể mở rộng quy mô (scale).

Mặc dù không thể chia sẻ chi tiết triển khai cụ thể, nhưng tôi muốn chia sẻ các bài học về kiến trúc mà tôi đã học được và cách tôi cuối cùng đã triển khai nó. Hy vọng những thông tin chi tiết này sẽ hữu ích nếu bạn đang xây dựng các hệ thống AI cần mở rộng, đáng tin cậy và xử lý dữ liệu lộn xộn.

Vấn đề cần giải quyết

100 file PDF tôi làm việc đã được phân tích cú pháp và chia nhỏ (chunk) trước khi đến tay tôi. Nhưng nội dung thô vẫn rất lộn xộn. Có các gạch đầu dòng, bảng biểu, lỗi tạo ra từ OCR (nhận dạng ký tự quang học), các phần đã dịch, tiêu đề bán cấu trúc, chân trang, đầu trang, định dạng không nhất quán và các đặc thù riêng của từng tài liệu.

Tôi chọn sử dụng agent vì việc quyết định điều gì quan trọng cần sự phán xét ngữ nghĩa (semantic judgement). Các tài liệu không tuân theo một khuôn mẫu nhất quán, nên mức độ liên quan không thể được xác định chỉ bằng các quy tắc đơn giản.

Bạn phải hiểu ngữ cảnh xung quanh. Không điều nào trong số này là khó khi thực hiện trên một khối dữ liệu nhỏ. Thách thức là thực hiện việc này một cách đáng tin cậy ở quy mô lớn.

Các quy tắc này sau đó được xử lý bởi một hệ thống hạ lưu khác để được đánh giá một cách xác định (deterministically).

Giải pháp cuối cùng

Sau một vài thử nghiệm, tôi nhận ra sự cải tiến lớn nhất không đến từ việc viết prompt tốt hơn, công cụ mới, máy chủ MCP hay hệ thống agent tinh vi hơn. Nó đến từ việc thay đổi hình thức của vấn đề.

Thay vì cố gắng làm cho agent thông minh hơn, tôi đã làm cho nhiệm vụ của agent nhỏ hơn.

Thay đổi đầu tiên là chuẩn bị dữ liệu nguồn ngay từ đầu. Thay vì yêu cầu agent truy vấn cơ sở dữ liệu, truy xuất bản ghi, quyết định xem nó có đúng đầu vào hay không, rồi thực hiện trích xuất, tôi đã cung cấp cho nó một điểm khởi đầu được kiểm soát tốt hơn.

Trong trường hợp của tôi, điều đó có nghĩa là lưu trữ tạm thời dữ liệu thô liên quan cục bộ.

Điều này có thể không luôn thực tế. Nhưng nguyên tắc cơ bản là giảm thiểu mức độ không chắc chắn trong việc truy xuất mà agent phải xử lý. Nếu nhiệm vụ của agent là suy luận về nội dung, đừng khiến nó cũng phải chịu trách nhiệm figuring out xem liệu nó đã tìm đúng nội dung hay chưa.

Một lựa chọn khác là chuẩn bị truy vấn trước.

Tôi cũng sử dụng một script để loại bỏ siêu dữ liệu và các trường không cần thiết trước khi chuyển nội dung thô cho agent. Ít ngữ cảnh không liên quan hơn có nghĩa là ít xao nhãng hơn, ít cơ hội để agent bám vào các chi tiết sai hơn và nhiệm vụ suy luận tổng thể sạch sẽ hơn.

Nhưng thay đổi quan trọng nhất là đơn vị công việc. Thay vì xử lý mọi thứ cùng một lúc, tôi thực hiện việc này theo lặp đi lặp lại và xử lý một tài liệu tại một thời điểm.

Điều đó làm cho mỗi công việc nhỏ hơn, dễ kiểm tra hơn, dễ thử lại hơn và dễ kiểm toán hơn. Tôi đã khởi chạy năm sub-agent để xử lý các tài liệu song song, với mỗi agent ghi lại tiến trình của mình vào một tệp.

Nếu một tài liệu thất bại, tôi có thể thử lại chỉ tài liệu đó. Nếu một đầu ra có vấn đề về định dạng, tôi có thể sửa trường hợp cụ thể đó mà không cần chạy lại toàn bộ lô. Nếu quy trình dừng ở giữa, tiến trình được lưu trong bộ nhớ đệm có nghĩa là nó có thể tiếp tục từ điểm kiểm tra thành công cuối cùng.

Đây cũng là nơi sự phân chia trách nhiệm trở nên rõ ràng hơn.

Agent xử lý công việc ngữ nghĩa: hiểu nội dung, xác định các phần liên quan và viết đầu ra JSON.

Mã nguồn bao quanh xử lý các phần cơ học: song song hóa công việc, thực thi lược đồ (schema), tạo ID, ghi tệp, lưu tiến trình, xác thực tham chiếu và kiểm tra xem đầu ra có thể truy ngược lại nguồn gốc hay không.

Tôi cũng có một bộ điều phối (orchestrator) giám sát tiến trình của script.

Làm cho đầu ra có thể kiểm toán được

Một quyết định thiết kế hữu ích là thêm ID tham chiếu vào mọi quy tắc được tạo ra. Điều này có nghĩa là mỗi mục đầu ra trỏ ngược lại một nguồn cụ thể.

Điều này làm cho đầu ra dễ kiểm toán hơn. Thay vì hỏi "Quy tắc được tạo ra này có trông đúng không?", tôi có thể đặt các câu hỏi chính xác hơn như: khối nguồn được tham chiếu có tồn tại không? Văn bản nguồn được trích dẫn có thực sự nằm trong khối đó không?

Tôi cũng có thể yêu cầu một agent khác chạy kiểm toán chọn lọc trên các tài liệu lớn và phức tạp hơn để đảm bảo các sắc thái quan trọng được giữ lại.

Ngoài ra, tôi đã thực hiện phiên bản nhẹ của các bài đánh giá (evals). Tôi đã chạy một lô nhỏ các tài liệu thô quy trình qua quy trình làm việc và xem xét thủ công kết quả về độ bao phủ và độ chính xác. Một tập dữ liệu vàng (golden dataset) đầy đủ không thực tế cho phạm vi nhiệm vụ này, nhưng tôi vẫn cần một cách để tự chứng minh rằng quy trình làm việc đang hoạt động.

Mục tiêu của tôi không phải là xây dựng một điểm chuẩn hoàn hảo mà là làm cho hệ thống đủ có thể kiểm toán để tôi có thể kiểm tra các đầu ra, bắt lỗi thất bại và lặp lại hướng tới mức độ chính xác cao hơn.

Nếu bạn có ý tưởng về cách tôi có thể làm tốt hơn, hãy cho tôi biết!

Bài học lớn nhất của tôi

Mô hình đã hiệu quả là ngừng coi LLM là toàn bộ hệ thống.

Hệ thống trở nên đáng tin cậy hơn không phải vì agent trở nên hoàn hảo, mà vì quy trình làm việc giúp đầu ra của nó dễ dàng theo dõi, xác thực và phục hồi hơn.

Tình cờ, tôi đang xây dựng điều này ngay trước khi tham dự hội nghị AI Engineer Singapore lần đầu, được tổ chức từ ngày 15-17 tháng 5 năm 2026.

Vào ngày cuối cùng, JJ Geewax, Giám đốc AI Ứng dụng tại Google DeepMind, đã chia sẻ một cách nhìn (framing) đã nắm bắt được những gì tôi đã học được theo cách khó khăn: chúng ta cần ngừng sử dụng LLM như những người giải quyết vấn đề khổng lồ.

Điều đó đã cộng hưởng với tôi vì đó là một cái bẫy rất dễ mắc phải. Rất dễ dàng chỉ cần đưa cho mô hình dữ liệu, lược đồ, quy tắc kinh doanh, các trường hợp ngoại lệ và trách nhiệm tự xác minh chính nó. Sau đó cảm thấy thất vọng khi kết quả không nhất quán.

Nhưng đối với các hệ thống sản xuất đáng tin cậy, mô hình tốt hơn thường là lai (hybrid). Hãy để agent xử lý các phần yêu cầu phán xét ngữ nghĩa, và để mã nguồn xử lý các phần yêu cầu cấu trúc, xác thực và kiểm soát.

Tôi sẽ chia sẻ thêm nhiều suy ngẫm từ AI Engineer Singapore và các hội thảo mà tôi đã tham dự. Đoạn video trên YouTube về bài phát biểu của JJ ở đây.

Đó là tất cả những gì tôi muốn chia sẻ. Hy vọng bài viết này hữu ích và hẹn gặp lại bạn trong bài viết tiếp theo 🙂