Chiến lược như một tài liệu — Chương bảy

Chương 6 — Chiến lược như một tài liệu, không phải là mã

Chúng ta đến với một hiểu biết sâu sắc mà hơn bất cứ điều gì khác, trong câu chuyện về việc xây dựng RAG từ năm 2023 trở đi, được nhắc đến là "điều tôi ước mình đã hiểu ngay từ ngày đầu tiên".

Các framework truyền thống xử lý chiến lược tìm kiếm như mã Python. Bạn muốn, đối với các danh mục kỹ thuật, tìm kiếm trước theo mã sản phẩm, sau đó theo từ khóa, rồi theo vector ngữ nghĩa, và chỉ ở giai đoạn cuối cùng mới tạo ra câu trả lời? Bạn viết một hàm. Bạn muốn, đối với các album ảnh, hoàn toàn bỏ qua tìm kiếm ngữ nghĩa truyền thống và tin tưởng vào một reranker chuyên dụng cho hình ảnh? Bạn viết một hàm khác. Bạn muốn, đối với các video doanh nghiệp, tách âm thanh khỏi luồng hình ảnh, phiên âm chúng riêng biệt, xử lý chúng như các nguồn riêng biệt và sau đó tái hợp chúng trong câu trả lời cuối cùng? Lại một hàm nữa. Mỗi loại nội dung, mỗi lĩnh vực, mỗi khách hàng cuối cùng đều tạo ra một nhánh mã khác biệt với các nhánh khác, cho đến điểm mà việc thay đổi một chiến lược đòi hỏi một bản phát hành phần mềm, một quy trình xem xét mã, một chu kỳ kiểm thử, một lần triển khai. Thời gian giữa "tôi có một ý tưởng để cải thiện tìm kiếm trên các tài liệu kỹ thuật" và "ý tưởng đó đã sẵn sàng sản xuất" được đo bằng tuần. Với mỗi ý tưởng.

Quan điểm thay thế nghe có vẻ hiển nhiên nhưng lại sâu sắc về mặt hậu quả: chiến lược tìm kiếm không phải là mã. Nó là một tài liệu. Một JSON — một định dạng văn bản có cấu trúc mà bất kỳ biên tập viên nào, với nửa giờ đào tạo, đều có thể đọc được — nói rằng: "trước tiên hãy thử cái này, sau đó cái kia, nếu cái đầu tiên thất bại, hãy chuyển sang cái thứ ba, sắp xếp lại theo cách này, trả lời bằng mô hình này." Tài liệu này tồn tại trong cơ sở dữ liệu, không phải trong kho lưu trữ. Nó được sửa đổi từ giao diện, không phải từ yêu cầu kéo. Nó được phiên bản hóa, sao chép, chuyên biệt hóa theo lĩnh vực. Một chiến lược cho danh mục kỹ thuật, một chiến lược cho album ảnh, một chiến lược cho hướng dẫn cài đặt, một chiến lược cho video, một chiến lược cho âm thanh, một chiến lược cho hợp đồng pháp lý, một chiến lược cho báo cáo tài chính. Tất cả cùng tồn tại trong cùng một hệ thống. Tất cả có thể chỉnh sửa theo thời gian thực.

Những người đã làm việc với phương pháp này – hãy gọi nó là, không cần quá sáng tạo, Meta-RAG – kể về một sự thay đổi tốc độ vượt xa kỹ thuật. Một yêu cầu điển hình từ khách hàng như "thêm một tìm kiếm cụ thể cho các mã sản phẩm chứa các chữ viết tắt như CMP40M hoặc RH1M" không còn là một phiếu phát triển kéo dài hai tuần nữa. Đó là một bước mới được thêm vào một quy trình JSON, được kiểm tra nhanh chóng trên môi trường staging, và được triển khai vào môi trường production trong một buổi chiều. Câu hỏi "điều gì sẽ thay đổi nếu chúng ta sử dụng một reranker khác cho ảnh, trong khi vẫn giữ cái hiện tại cho văn bản?" có thể được trả lời bằng cách sửa đổi một dòng cấu hình. Thử nghiệm không tốn kém, hoàn tác không tốn kém (chỉ cần khôi phục phiên bản trước của tài liệu), và kiến thức tích lũy được – điều gì hoạt động tốt cho một loại nội dung nhất định – trở thành một tài sản được phiên bản hóa và chuyển giao, không phải là kiến thức ẩn của người đã viết nhánh mã cụ thể đó và hiện đang đi nghỉ.

Còn có một hiệu ứng xã hội thú vị xuất hiện trong các tổ chức áp dụng phương pháp này. Với chiến lược như một tài liệu, ranh giới giữa "nhà phát triển" và "người dùng thành thạo" sẽ dịch chuyển. Một thủ thư kỹ thuật số, người lưu trữ doanh nghiệp, chuyên gia về lĩnh vực — trưởng phòng kỹ thuật, người chịu trách nhiệm về tài liệu, người quản lý sản phẩm hiểu rõ nhất những câu hỏi thực sự của khách hàng — có thể đọc một chiến lược, hiểu nó hoạt động như thế nào, đề xuất các thay đổi, đôi khi thậm chí viết chúng trực tiếp. Họ không cần phải đi qua kênh yêu cầu phát triển, không cần phải giải thích cho nhà phát triển những điều mà nhà phát triển không biết (vì không thuộc chuyên môn của họ). RAG ngừng trở thành một sản phẩm bạn tiêu thụ và trở thành một công cụ bạn định hình dựa trên kiến thức tổ chức của mình. Theo kinh nghiệm của những người đã thử, điều này thay đổi tinh thần của dự án trước cả khi các con số chỉ số cải thiện.

Đây không phải là phép màu, và nó có chi phí của nó. Cần một công cụ để thực thi các chiến lược-như-tài liệu này một cách hiệu quả và an toàn. Cần một ngôn ngữ mô tả đủ phong phú để bao phủ các trường hợp thực tế, nhưng cũng đủ đơn giản để không trở thành một Turing-complete khác được ngụy trang. Cần các công cụ kiểm soát phiên bản, kiểm thử và khôi phục. Nhưng tất cả những điều này là vấn đề của người xây dựng công cụ — chỉ một lần, và cho tất cả người dùng. Khách hàng cuối cùng chỉ thấy một điều: khả năng phát triển chiến lược tìm kiếm của họ với tốc độ của suy nghĩ, thay vì tốc độ của chu kỳ phát hành phần mềm. Và đối với những người đang tham gia, đây là một cuộc cách mạng thầm lặng vẫn chưa tìm thấy tên tuổi của nó trên các tạp chí chuyên ngành.

Kết luận — Chương thứ bảy, sau vài tháng

Đầu năm 2026, tổng hợp những bài học từ các chương trước — những bảng biểu bị mất, các reranker nói dối, những ảo giác thừa kế, hóa đơn đám mây tăng nhanh hơn giá trị, các framework hứa hẹn nhưng cứng nhắc — ai đó ở Ý đã bắt đầu xây dựng một máy chủ RAG khác biệt. Được viết bằng Python, được thiết kế để chạy trên phần cứng dễ tiếp cận, có khả năng giao tiếp với các mô hình đám mây khi thuận tiện và với các mô hình cục bộ khi quyền riêng tư yêu cầu hoặc chi phí không hợp lý. Một máy chủ nơi các chiến lược tìm kiếm là tài liệu có thể chỉnh sửa, reranker là một quy trình cục bộ trên GPU, các bảng biểu không bị mất vì chúng được coi là công dân hạng nhất, ảnh không kế thừa đối tượng từ các kho lưu trữ bụi bặm của các thời đại khác, và chi phí cho mỗi truy vấn — cả về tiền bạc và dữ liệu bị rò rỉ cho bên thứ ba — có thể biết và kiểm soát đến từng xu.

Chúng tôi sẽ không nêu tên dự án. Đây không phải là lúc để làm điều đó, và chúng tôi không muốn biến một cuộc điều tra thành một quảng cáo. Nhưng nếu các chương trước đã giúp bạn nhận ra một tình huống bạn đang trải qua – một chatbot doanh nghiệp trả lời tự tin những câu hỏi sai, một dự án RAG không cất cánh trong nhiều tháng, hóa đơn đám mây tăng nhanh hơn giá trị mà nó mang lại, một nghi ngờ ngày càng tăng về việc các tài liệu bí mật của bạn đang được gửi đến những nơi bạn không biết – thì đáng để biết rằng có một con đường khác, đã được ai đó ở Ý đi qua, và vào năm 2026 đã bắt đầu đưa ra những câu trả lời đầu tiên mà mọi người mong đợi vào năm 2023.

Tin tốt là AI doanh nghiệp, cuối cùng, đang thoát khỏi giai đoạn demo. Tin không tốt là nó đang thoát ra ngoài, mang theo tất cả những vết sẹo của hành trình: các framework phình to, sự phụ thuộc vào nhà cung cấp, kiến trúc monolithic, dữ liệu bẩn, lỗi im lặng và một xu hướng nhất định của ngành là bán giải pháp trước khi thậm chí hiểu được vấn đề. Chúng tôi đã kể chúng trong sáu chương. Chương thứ bảy – câu chuyện về những gì xảy ra khi cuối cùng có ai đó làm mọi thứ đúng đắn, với sự kiên nhẫn, bằng tiếng Ý và mã nguồn mở – chúng tôi sẽ viết sớm thôi, với ít thận trọng hơn về tên và nhiều số liệu hơn trên bàn.

Trong khi đó, nếu bạn đã đọc đến đây, bạn đã tự phân tích sâu hơn 90% những người ra quyết định hiện đang ký hợp đồng cho một chatbot doanh nghiệp mà không đặt bất kỳ câu hỏi nào mà bạn đã tự hỏi khi đọc những chương này. Đây là một khởi đầu tốt hơn so với điểm xuất phát của họ. Và trong những tháng tới, sự khác biệt giữa những người đã đặt những câu hỏi này và những người chưa, sẽ trở nên rất rõ ràng trên hóa đơn – và trên câu trả lời mà AI của bạn sẽ đưa ra cho khách hàng của bạn.

Cuộc điều tra này được biên soạn vào tháng 4 năm 2026, dựa trên kinh nghiệm mười tám tháng thiết kế, xây dựng và tối ưu hóa các hệ thống RAG doanh nghiệp từ cuối năm 2024 đến đầu năm 2026.