Những bảng biểu không tồn tại

Chương 2 — Những bảng biểu không tồn tại

Một kỹ thuật viên từ một công ty cơ khí ở Đông Bắc Ý đã kể cho chúng tôi điều này trong khi thưởng thức một tách espresso, với sự điềm tĩnh đặc trưng của người Veneto báo hiệu một thảm họa: "Chatbot của chúng tôi biết mọi thứ về động cơ. Ngoại trừ dữ liệu của động cơ." Sau đó, anh ấy giải thích. Trợ lý AI nội bộ của họ có thể mô tả các dòng sản phẩm, ngữ cảnh sử dụng, lịch sử thương hiệu, lợi thế cạnh tranh. Thật tuyệt vời về mặt tường thuật. Nhưng khi một khách hàng hỏi mô-men xoắn định mức của kiểu CMP50L — tức là dữ liệu kỹ thuật mà mọi người mở danh mục để xem, con số để mua một động cơ — chatbot trả lời một cách mơ hồ, đôi khi hợp lý, đôi khi không. Năm tháng phát triển, giám đốc điều hành ngày càng bối rối, và không ai biết tại sao.

Chẩn đoán đến một cách tình cờ, gần như vì chán nản, khi kiểm tra thủ công cơ sở dữ liệu sau một cuộc họp bất phân thắng bại. Danh mục PDF chứa 342 bảng kỹ thuật. Trong cơ sở dữ liệu, con số này là không. Không phải một vài bảng: không có bảng nào. Mã trích xuất bảng từ PDF lưu dữ liệu vào các trường có tên columns và data, trong khi mã lập chỉ mục sau đó mong đợi các trường có tên headers và rows. Một "từ đồng nghĩa" không được tôn trọng. Một quy ước nội bộ bị bỏ qua trong quá trình tái cấu trúc bị lãng quên. Kết quả, trong năm tháng im lặng: toàn bộ trí thông minh số của danh mục — các cặp, lũy thừa, đường kính, trọng lượng, mã đặt hàng, điện áp cung cấp — đã chảy ra khỏi vòi mà không bao giờ được đổ vào cốc. Ba trăm bốn mươi hai bảng, bị mất từng cái một trong sự im lặng nghi lễ.

Đây là kiểu lỗi không gây ra tiếng động. Nó không gây ra ngoại lệ, không làm sập hệ thống, không xuất hiện trong bất kỳ nhật ký nào. Đơn giản, một phần của thế giới ngừng tồn tại đối với hệ thống của bạn, và không ai nhận thấy cho đến khi một người dùng — thường là một người dùng tức giận — đặt đủ câu hỏi dai dẳng để lộ ra hố sâu. Và nó là biểu tượng của một vấn đề lớn hơn nhiều so với tên trường: các framework RAG chung được tối ưu hóa cho văn bản thông thường — bài viết, trang web, đoạn văn tường thuật — và coi các bảng như công dân hạng hai, khi chúng được xử lý. Nhưng các tài liệu doanh nghiệp Ý thường là bảng. Danh mục kỹ thuật, bảng giá, thông số kỹ thuật sản phẩm, phiếu an toàn dữ liệu, thông báo đặt hàng: phần có giá trị, đối với những người tham khảo các tài liệu này, là phần dạng bảng. Phần bị hỏng đầu tiên và không ai nhận thấy.

Bài học không phải là "hãy cẩn thận với tên trường". Nó phức tạp hơn: trong một RAG nghiêm túc, mọi loại nội dung — bảng biểu, hình ảnh, mã số, tiêu đề đoạn văn, chú thích — đều cần được xử lý chuyên biệt, thiết kế, kiểm tra. Và bài kiểm tra hoạt động không phải là "chatbot trả lời các câu hỏi hiển nhiên" — ngay cả các hệ thống bị lỗi cũng trả lời được những câu hỏi đó, vì có đủ dữ liệu trôi nổi để xây dựng một điều gì đó hợp lý. Bài kiểm tra thực sự là "chatbot trả lời các câu hỏi buộc nó phải chạm vào mọi phần của quy trình". Các câu hỏi cụ thể, số liệu, có thể kiểm chứng. Các câu hỏi mà có một câu trả lời đúng duy nhất, và nếu hệ thống sai, bạn sẽ biết ngay lập tức.

Nếu bạn không thực hiện bài kiểm tra này, bạn sẽ không biết liệu RAG của mình có hoạt động hay không. Bạn chỉ biết rằng nó không phàn nàn. Và "không phàn nàn" là một tiêu chí chất lượng rất thấp đối với một hệ thống mà mọi người sẽ sử dụng để đưa ra quyết định.