Xây sản phẩm AI: từ mô hình ngôn ngữ đến truy xuất và tác tử có giới hạn

Đăng ngày 23/10/2026

Tóm tắt

• Một sản phẩm dùng mô hình ngôn ngữ cần tác vụ, dữ liệu và ranh giới hành động rõ.
• Chỉ dẫn tốt không thay quyền truy cập hay kiểm tra kết quả ở phần mềm.
• RAG đưa tài liệu vào quá trình trả lời; tài liệu tìm đúng chưa bảo đảm câu trả lời đúng.
• Tinh chỉnh mô hình và truy xuất giải quyết những nhu cầu khác nhau, có thể kết hợp.
• Tác tử chỉ đáng thêm khi sự linh hoạt giúp ích đủ để bù chi phí kiểm soát.

Giả định một nhóm xây trợ lý cho bộ phận bảo trì. Người dùng hỏi thiết bị cần kiểm tra lúc nào, tìm hướng dẫn và muốn tạo yêu cầu sửa chữa. Ba việc nghe gần nhau nhưng cần quyền khác nhau. Đọc tài liệu, đề xuất bước làm và ghi một yêu cầu mới không thể dùng chung một nhãn “chatbot trả lời được”. Sản phẩm cần xác định nó được làm đến đâu trước khi chọn công cụ.

Các ví dụ trong bài đều do tác giả dựng để giải thích thiết kế, không phải ca triển khai có kết quả thật. Bài đi từ một tác vụ đến cấu trúc ứng dụng, rồi mới xét truy xuất, tinh chỉnh và tác tử. Đánh giá chất lượng là một phần bắt buộc của vòng xây dựng; việc lập bộ kiểm rủi ro đầy đủ cần thêm phân tích riêng theo lĩnh vực sử dụng.

Bắt đầu bằng một việc có thể xác nhận hoàn thành

Một câu mô tả hữu ích có người sử dụng, đầu vào và kết quả cần nhận. Với trợ lý bảo trì giả định, bản đầu có thể chỉ tìm hướng dẫn từ tài liệu đã duyệt cho đúng loại thiết bị. Kết quả gồm đoạn trả lời cùng tài liệu hỗ trợ; trường hợp thiếu thông tin thì hỏi lại hoặc chuyển người xử lý. Đừng để lời hứa “trợ lý thông minh” thay các điều kiện cụ thể ấy.

Trong cuộc trao đổi về dùng AI ở startup, nhóm thực hành YC nhấn mạnh việc hiểu công việc khách hàng vẫn cần thiết, dù công cụ mô hình đã mở nhiều khả năng.[1] Đây là kinh nghiệm và quan điểm của người tham gia, không phải một thử nghiệm cho thấy cứ dùng mô hình là có lợi. Phần cần kiểm vẫn là người sử dụng có hoàn thành việc tốt hơn trong bối cảnh thật hay không.

Khi giới hạn tác vụ, hãy ghi cả điều bị loại. Trợ lý có thể giúp tìm quy trình nhưng không tự xác nhận máy an toàn. Nó có thể soạn yêu cầu bảo trì nhưng chưa gửi nếu người dùng chưa duyệt. Những ranh giới này giúp thiết kế cách kiểm và cách giải thích cho khách. Chúng cũng ngăn việc bản giới thiệu nhỏ dần biến thành lời hứa tự động hóa toàn bộ công việc.

Một lần quan sát có thể cho thấy khách thiếu thông tin đầu vào chứ không thiếu khả năng diễn đạt. Nếu không biết mã thiết bị, mô hình tạo câu dài hơn cũng không giúp tìm đúng tài liệu. Nhóm nên xây cách hỏi bổ sung hoặc chọn từ danh mục trước. Có những phần làm bằng quy tắc rõ ràng sẽ dễ kiểm hơn việc yêu cầu mô hình đoán.

Tách mô hình khỏi phần ứng dụng chịu trách nhiệm

Mô hình là thành phần tạo hoặc xử lý nội dung. Ứng dụng còn phải nhận diện người dùng, lấy dữ liệu đúng quyền, gọi công cụ, ghi trạng thái và trình bày kết quả. Một lỗi ở bất kỳ đoạn nào cũng có thể khiến câu trả lời cuối không đáng tin. Vì vậy, đừng đánh giá toàn bộ hệ thống chỉ bằng một lần gửi câu hỏi trực tiếp đến mô hình.

Một thiết kế minh họa có thể chia trách nhiệm thành phần tiếp nhận, phần chọn dữ liệu, phần gọi mô hình và phần kiểm hành động. Đây là cách phân rã của tác giả, không phải tiêu chuẩn kiến trúc bắt buộc. Điều quan trọng là mỗi phần biết đầu vào nào được chấp nhận, trả ra điều gì và báo lỗi ra sao. Nhóm có thể thay cách thực hiện mà vẫn kiểm những điều khách phải được bảo đảm.

Nếu người dùng sửa câu hỏi hoặc đổi tài khoản giữa lúc chờ, kết quả cũ phải được gắn đúng người và đúng lượt. Đừng để phản hồi đến muộn hiện vào phiên khác. Tương tự, công việc chạy nền cần có chủ sở hữu rõ. Quyền của nó phải được kiểm khi lấy dữ liệu và khi thực hiện hành động, không chỉ ở thời điểm người dùng mở màn hình.

Nhật ký nên đủ để hiểu đường đi của lỗi nhưng không thu gom bí mật một cách vô hạn. Có thể ghi phiên bản cấu hình, nguồn được dùng, công cụ đã gọi và trạng thái kết thúc theo phạm vi phù hợp. Việc lưu nội dung cụ thể cần có mục đích và kiểm soát truy cập. Một hệ thống dễ tìm lỗi không đồng nghĩa một nơi mọi người đều đọc được dữ liệu khách.

Chỉ dẫn rõ giúp giảm mơ hồ, không tạo quyền mới

Chỉ dẫn cho mô hình nên nêu việc cần làm, thông tin có thể dùng, dạng đầu ra và cách xử lý khi thiếu dữ kiện. Ví dụ giả định: trả lời từ hướng dẫn đã cung cấp; nếu không có bước tương ứng, nói chưa tìm thấy thay vì dựng một quy trình mới. Ví dụ mẫu có thể giúp làm rõ cách trình bày, nhưng phải được kiểm với các trường hợp khác.

Trong trao đổi YC về chỉ dẫn cho tác tử, người tham gia bàn việc viết yêu cầu chi tiết và thử với các trường hợp thất bại.[2] Đó là chia sẻ thực hành, không phải chứng nhận rằng một mẫu chỉ dẫn bảo đảm hoạt động đúng. Nhóm không nên sao một chỉ dẫn được trình diễn rồi coi đã có chất lượng tương đương trong ngành của mình. Dữ liệu, công cụ và quyền khác nhau có thể làm kết quả khác hẳn.

Wei và cộng sự trong nghiên cứu NeurIPS năm 2022 thử việc đưa ví dụ gồm các bước suy luận trung gian. Phần tóm tắt báo cáo cải thiện trên các tác vụ số học, kiến thức thông thường và suy luận ký hiệu ở ba mô hình lớn.[3] Kết quả có bối cảnh mô hình và phép thử cụ thể; nó không chứng minh rằng lời giải thích do mô hình tạo luôn phản ánh đúng cơ chế hay rằng mọi mô hình hiện nay cần cùng cách nhắc.

Nếu cần giải thích cho người dùng, hãy ưu tiên bằng chứng có thể kiểm: tài liệu nào hỗ trợ kết luận, phép tính dùng đầu vào nào, hành động nào đã thành công. Đoạn diễn giải nghe hợp lý không thay những dấu vết ấy. Quyền truy cập cũng phải do ứng dụng thi hành; ghi “không đọc tài liệu người khác” trong chỉ dẫn chưa phải cơ chế bảo vệ dữ liệu.

Truy xuất là một chuỗi quyết định về tài liệu

RAG thường được dùng để nói về việc tìm thông tin bên ngoài rồi cung cấp cho quá trình tạo câu trả lời. Lewis và cộng sự trong công trình được nhận tại NeurIPS năm 2020 nghiên cứu mô hình kết hợp bộ nhớ tham số với chỉ mục Wikipedia và bộ truy xuất, có tinh chỉnh cho các tác vụ tri thức.[4] Kiến trúc gốc ấy không đồng nhất với mọi ứng dụng ghép tài liệu vào lời nhắc hiện nay.

Với nhóm sản phẩm, câu hỏi thực tế đầu tiên là có tài liệu đúng hay chưa. Tài liệu cần nhận diện được phiên bản, phạm vi áp dụng và người được đọc. Cắt tài liệu thành các đoạn không nên làm mất điều kiện quan trọng. Nếu bảng hướng dẫn tách khỏi chú thích về loại máy, kết quả tìm kiếm có thể trông đúng từ khóa nhưng sai ngữ cảnh.

Tiếp theo là kiểm từng bước: câu hỏi được hiểu thế nào, hệ thống tìm được tài liệu gì, chọn đoạn nào và câu trả lời có bám đoạn đó không. Nếu không có tài liệu phù hợp, cần phân biệt “không tìm thấy” với “không được phép xem”. Không nên tiết lộ rằng tài liệu riêng của người khác tồn tại khi trả lời một câu hỏi không có quyền truy cập.

Một đường dẫn nguồn chỉ hữu ích khi thực sự hỗ trợ phát biểu và mở đúng tài liệu. Trợ lý có thể gắn liên kết có thật nhưng nói quá nội dung. Vì vậy, nghiệm thu cần đọc đối chiếu câu với đoạn nguồn. Chưa có cơ sở để hứa loại bỏ hoàn toàn câu trả lời sai chỉ vì hệ thống đã dùng truy xuất. Đây là yêu cầu kiểm thiết kế do tác giả đề xuất, không phải kết quả đo của một sản phẩm cụ thể.

Khi nào mới bàn đến tinh chỉnh

Tinh chỉnh thay đổi mô hình thông qua quá trình huấn luyện thêm trên dữ liệu được chuẩn bị. Truy xuất cung cấp thông tin trong quá trình xử lý yêu cầu. Hai cách có thể cùng xuất hiện; nghiên cứu RAG gốc đã có thành phần tinh chỉnh.[4] Đừng đặt chúng thành cuộc chọn thắng thua tuyệt đối. Cần xác định lỗi đến từ thiếu tri thức, thiếu ví dụ hành vi hay phần ứng dụng thực hiện sai.

Nếu dữ liệu sản phẩm thay đổi thường xuyên, nhóm nên xem cách cập nhật nguồn và kiểm phiên bản trước khi quyết định huấn luyện lại. Nếu muốn đầu ra tuân một dạng công việc ổn định, cần thử chỉ dẫn và ví dụ có kiểm soát rồi đánh giá khoảng thiếu còn lại. Tinh chỉnh có thể là một phương án, nhưng phải có dữ liệu phù hợp, quyền sử dụng và cách đo cải thiện trên tập chưa dùng để điều chỉnh.

Trong cuộc phỏng vấn YC về phương án thay tinh chỉnh, người đồng sáng lập Poetiq trình bày cách hệ thống của công ty mình xây lớp vận hành quanh mô hình.[5] Đây là tuyên bố của bên phát triển sản phẩm, chưa được bài kiểm chứng độc lập. Nó mở ra một hướng so sánh, không chứng minh rằng mọi tinh chỉnh đều lãng phí hay mọi lớp vận hành đều chuyển sang mô hình mới mà không cần sửa.

Một nhóm nên so các phương án trên cùng tác vụ và giới hạn. Ghi công sức chuẩn bị dữ liệu, kiểm thử, duy trì và thay đổi, thay vì chỉ nhìn chất lượng của vài câu trả lời đẹp. Nếu cải thiện chưa ổn định, có thể giữ bản đơn giản hơn. Không nhất thiết cần giải pháp mạnh nhất trên bảng điểm công khai; cần giải pháp đạt điều kiện của công việc mình đã hứa.

Công cụ tạo hành động, nên cần một lớp kiểm khác

Một công cụ cho mô hình có thể đọc lịch, tìm tài liệu hoặc tạo yêu cầu mới. Phần mềm thực thi phải xác thực tham số và quyền người gọi. Mô hình đề xuất một lệnh chưa có nghĩa lệnh được phép chạy. Khi hành động làm thay đổi dữ liệu hay gửi thông tin ra ngoài, cần xác định việc nào tự làm được và việc nào phải có người duyệt.

Giả định trợ lý nhận yêu cầu đặt lịch bảo trì. Ứng dụng cần kiểm thiết bị có thuộc đơn vị của người dùng không, khung giờ có còn hợp lệ không và người dùng đã xác nhận chưa. Khi mạng chậm, thử lại không nên tạo hai yêu cầu. Một thông điệp “đã tạo” chỉ nên xuất hiện sau khi có bằng chứng từ nơi ghi dữ liệu, không dựa vào câu văn mô hình tự viết.

Yao và cộng sự trong ReAct, bản ICLR năm 2023, nghiên cứu đan xen suy luận và hành động để lấy quan sát từ môi trường. Phần tóm tắt mô tả các phép thử hỏi đáp, kiểm chứng thông tin và môi trường tương tác.[6] Thành công ở những phép thử đó không cho phép suy rằng một tác tử có thể tự chịu trách nhiệm cho giao dịch thật. Quyền và giới hạn phải được thiết kế riêng cho ứng dụng.

Có thể bắt đầu bằng công cụ chỉ đọc. Khi đã hiểu các lỗi, thêm hành động hẹp với điều kiện kiểm rõ và đường phục hồi. Danh mục công cụ ít, mô tả dễ hiểu và đầu ra có cấu trúc giúp người xây xác định điều gì đã xảy ra. Thêm nhiều công cụ để bản giới thiệu hấp dẫn có thể làm khó việc biết một quyết định sai bắt đầu từ đâu.

Quy trình cố định thường là điểm xuất phát dễ hiểu

Anthropic trong bài kỹ thuật công bố ngày 19/12/2024 phân biệt luồng có các bước do mã quy định với tác tử để mô hình linh hoạt lựa chọn quá trình và công cụ. Bài khuyên dùng cách đơn giản trước rồi tăng phức tạp khi cần.[7] Đây là kinh nghiệm kỹ thuật của nhà cung cấp; trang hiện còn lưu ý hệ công cụ đã thay đổi từ khi xuất bản, nên không nên đọc nó như danh mục công cụ cố định cho năm 2026.

Nếu nhiệm vụ luôn gồm nhận biểu mẫu, kiểm dữ liệu, tìm quy định rồi soạn bản nháp, nhóm có thể mô tả luồng ấy trực tiếp. Mô hình hỗ trợ phần hiểu nội dung hoặc diễn đạt; không cần giao cả quyền chọn bước tiếp theo. Khi tình huống biến đổi mạnh và cần tìm thông tin qua nhiều bước, tác tử có thể hữu ích hơn, nhưng phải có ngân sách thao tác, điểm dừng và cách chuyển người.

YC cũng có cuộc trao đổi về vai trò lớp vận hành quanh mô hình, gồm ngữ cảnh, công cụ và đánh giá.[8] Bài chỉ dùng ý rằng cần xem cả hệ thống, không mượn các tuyên bố tăng điểm hay khả năng tự cải thiện làm kết quả đã xác nhận. Một vòng lặp tự kiểm vẫn có thể lặp lại cùng một hiểu nhầm nếu không nhận được tín hiệu đúng từ bên ngoài.

Điểm dừng nên được thiết kế như một kết quả bình thường. Hệ thống có thể trả rằng chưa đủ bằng chứng, cần thêm thông tin hoặc đã đạt giới hạn thao tác. Điều đó tốt hơn việc tiếp tục vô hạn rồi đưa ra kết luận để kết thúc. Người dùng cũng cần thấy tác tử đang đọc, đang chuẩn bị hay đã thực hiện; ba trạng thái không thể gộp thành một vòng chờ không giải thích.

AI trong tình huống tiếng Việt cần được kiểm trên công việc thật

FPT mô tả trong tài liệu AI Agents việc chọn nhiệm vụ, xác định vai trò, chuẩn bị thông tin và giới hạn công cụ trước khi tạo trợ lý.[9] Kho PhoGPT do VinAI Research công bố phân biệt mô hình nền với biến thể hội thoại, đồng thời nêu các giới hạn về suy luận, lập trình, toán và khả năng tạo thông tin sai.[10] Đây là hai nguồn Việt Nam trực tiếp từ bên phát triển; chúng không phải so sánh độc lập hay khuyến nghị chọn nhà cung cấp.

Với trợ lý bảo trì giả định, bộ câu hỏi tiếng Việt nên gồm cách viết tắt trong nghề, tên thiết bị gần giống nhau và trường hợp thiếu dấu. Tài liệu cũng có thể chứa bảng, ảnh hoặc bản quét. Nhóm cần biết bước chuyển đổi có làm mất thông tin không trước khi quy lỗi cho mô hình. Một câu hỏi được hiểu đúng nhưng tìm sai phiên bản hướng dẫn vẫn dẫn đến kết quả sai.

Đừng để giao diện tiếng Việt tạo cảm giác sản phẩm đã phù hợp mọi quy trình ở Việt Nam. Người trực vận hành cần xác nhận thuật ngữ, cách hỏi lại và ngưỡng chuyển người. Các hướng dẫn có rủi ro an toàn không nên được biến thành câu trả lời quả quyết nếu thiếu điều kiện áp dụng. Khi cần người có thẩm quyền xem, sản phẩm phải chỉ rõ bước ấy thay vì tự đóng vai người phê duyệt.

Bản đầu có thể giữ tác vụ nhỏ: tìm đoạn hướng dẫn được phép đọc, cho người dùng mở nguồn và gửi đề nghị hỗ trợ khi thiếu thông tin. Sau đó mới xem có nên thêm bước soạn yêu cầu hay đặt lịch. Cách mở rộng này là đề xuất thiết kế, chưa có thử nghiệm chứng minh hiệu quả. Mỗi khả năng mới phải đi cùng việc xem lại quyền, dữ liệu và trường hợp thất bại tương ứng.

Phản hồi chỉ hữu ích khi quay về đúng nguyên nhân

Khi người dùng đánh dấu câu trả lời chưa tốt, nhóm cần phân loại lý do: thiếu nguồn, chọn sai đoạn, hiểu sai câu hỏi, thực hiện công cụ lỗi hay trình bày khó hiểu. Một nút không thích không tự cho biết nên sửa chỉ dẫn hay thay mô hình. Người xem phản hồi cần giữ được liên hệ với cấu hình và dữ liệu đã dùng, trong phạm vi được phép lưu.

Các trường hợp đã sửa nên được giữ thành ví dụ kiểm lại, nhưng phải có phần mới để tránh chỉ tối ưu những lỗi đã biết. Khi thay một thành phần, so cả việc từng làm đúng. Một sửa đổi giúp tìm thông tin tốt hơn có thể làm phản hồi chậm hoặc lấy quá nhiều dữ liệu. Vòng cải tiến cần xem kết quả toàn tác vụ thay vì chỉ đoạn mô hình sinh văn bản.

Nguồn và phương pháp

Bài viết gốc, không phải bản dịch, có AI hỗ trợ; nguồn công khai được mở ngày 24/10/2026. Ba công trình Lewis, Yao và Wei dùng phần tóm tắt, chưa tái lập phép thử hay kiểm chứng toàn văn. Y Combinator cung cấp kinh nghiệm và phỏng vấn, trong đó phát biểu về Poetiq là của bên bán sản phẩm. Anthropic là nguồn kỹ thuật nhà cung cấp; FPT và VinAI là tài liệu chính chủ, chưa được bài chạy thử. Sơ đồ và tình huống là phân tích minh họa của tác giả, chưa kiểm chứng trên sản phẩm vận hành. Không có cơ sở để coi kiến trúc trong bài là bảo đảm an toàn hoặc chất lượng cho một lĩnh vực cụ thể.