1. Phân tích công việc trước khi xây chatbot

Kỹ thuật Chatbot · Bài 1 trong 9 bài · Nguồn được đối chiếu ngày 7 tháng 10 năm 2026. Thiết kế và giả định đề xuất được phân biệt với kết quả triển khai đã đo.

Chatbot hữu ích khi hoàn thành được một công việc cụ thể: giải thích sản phẩm, trả lời câu hỏi có tài liệu, so sánh chỉ số kinh doanh hoặc chuẩn bị hành động để người dùng duyệt. “Dùng model mạnh nhất” chưa phải yêu cầu sản phẩm. Cách mô tả đó chưa xác định thành công, chi phí và mức sai sót có thể chấp nhận.

Series này xây dựng một sản phẩm tham chiếu: trợ lý kinh doanh song ngữ, trả lời từ tài liệu được phép truy cập, phân tích dữ liệu bán hàng giả lập và đề xuất hành động mà không tự thực thi. Mục tiêu là giảm phụ thuộc khi vận hành và kiểm soát chất lượng. Khả năng ngang model hàng đầu trong mọi cuộc hội thoại nằm ngoài mục tiêu này.

Lập danh mục công việc thực tế

Thu thập yêu cầu trong quy trình mục tiêu với sự đồng ý phù hợp và loại bỏ thông tin nhạy cảm. Phỏng vấn cả người dùng lẫn người đang xử lý câu hỏi của họ. Với mỗi yêu cầu, ghi kết quả mong muốn, bằng chứng cần có, quyền truy cập, tần suất, thời gian chờ chấp nhận được và hậu quả nếu trả lời sai. Yêu cầu mơ hồ cần được giữ là mơ hồ, thay vì gán một nhãn chắc chắn thiếu căn cứ.

Ví dụ, “Doanh số tháng trước thế nào?” cần làm rõ doanh thu gộp hay thuần, múi giờ nào, đơn hoàn tất hay đơn được tạo, và đơn vị kinh doanh nào. “Tóm tắt chính sách hoàn tiền” cần nguồn có phiên bản. “Hoàn tiền đơn này” cần danh tính, công cụ được cấp quyền và quyết định thực thi riêng.

Công việc	Bằng chứng	Điều kiện hoàn thành
Trả lời từ tài liệu	Tài liệu hiện hành, được phép truy cập	Câu trả lời có căn cứ và liên kết nguồn
Phân tích kinh doanh	Chỉ số đã duyệt và bản chụp dữ liệu	Kết quả, bộ lọc và độ mới chính xác
Chuẩn bị hành động	Bản ghi và quyền đã xác thực	Đề xuất có thể duyệt; không thực thi ngoài ý muốn
Yêu cầu chưa rõ	Phạm vi còn thiếu	Câu hỏi làm rõ có ích

Tách quyết định, câu trả lời và hành động

Router chọn tác vụ. Model sinh nội dung viết câu trả lời hoặc đề xuất kế hoạch có cấu trúc. Mã ứng dụng kiểm tra quyền và chạy công cụ. Các vai trò này có thể dùng chung hạ tầng, nhưng trách nhiệm cần rõ ràng.

Jev phù hợp với vai trò ra quyết định: giao diện chính thức cung cấp lựa chọn có kiểu dữ liệu, điểm số và quyết định có/không. Jev không sinh câu trả lời hội thoại. Vì vậy, classifier tương tự Jev thay thế được một số lần gọi routing, không thay thế toàn bộ chatbot. Tài liệu model của TypeSafe AI.

Dùng quy tắc xác định cho điều kiện chính xác như xác thực, quyền sở hữu tài khoản, giới hạn số và phê duyệt hành động không thể đảo ngược. Model có thể nhận diện ý định nhưng không được cấp quyền. Điểm model thấp cũng chưa thể được hiểu là xác suất thất bại đã hiệu chuẩn nếu chưa kiểm chứng.

Viết cam kết chất lượng

Xác định tiêu chí chấp nhận trước khi so sánh model. Mục tiêu minh họa cho sản phẩm tham chiếu: ít nhất 95% kết quả chỉ số chính xác, ít nhất 90% câu trả lời tài liệu có bằng chứng hỗ trợ, không ghi nhận lộ dữ liệu giữa các tenant trong bộ test phát hành, và p95 thời gian hoàn tất câu trả lời dưới năm giây ở mức đồng thời được nêu rõ. Đây là ngưỡng đề xuất, chưa phải kết quả đo hay bảo đảm.

Tách kết quả theo ngôn ngữ và tác vụ. Điểm tổng có thể che giấu chất lượng tiếng Việt yếu hoặc lỗi trong quy trình rủi ro cao. Ghi rõ khi nào hệ thống nên từ chối kết luận. Chatbot hỏi một câu đúng trọng tâm có thể hữu ích hơn chatbot trả lời trôi chảy nhưng dùng sai chỉ số.

Giảm phụ thuộc theo đúng thứ tự

Bắt đầu bằng một giao diện model trả lời, một chiến lược retrieval và danh mục công cụ có kiểu dữ liệu nhỏ. Thiết lập baseline bằng model mạnh, rồi thử model nhỏ hơn trên cùng công việc. Chỉ thêm classifier riêng khi routing cải thiện chi phí hoặc độ tin cậy qua đo lường. Reranking, OCR, vision hay model chuyên biệt chỉ nên bổ sung cho khoảng thiếu đã xác định.

“Một model” có thể là một backbone sinh nội dung, trong khi encoder nhẹ xử lý retrieval. Điều này không bắt buộc đưa mọi tác vụ xác định qua backbone. Ngược lại, dùng adapter riêng cho từng client vẫn tăng công việc train, quản lý phiên bản và bộ nhớ, dù dùng chung trọng số gốc.

Xác định bản phát hành đầu tiên

Bản nhỏ nhất có ích gồm câu trả lời có nguồn, hai hoặc ba chỉ số kinh doanh được duyệt, hỏi làm rõ, trạng thái lỗi dễ hiểu và phản hồi người dùng. Hoãn ghi dữ liệu tự động, SQL tùy ý và chợ connector đến khi có bằng chứng về nhu cầu. Đo công việc hoàn thành thay vì số tin nhắn.

Cho người dùng thực hiện tình huống cụ thể: chọn workspace, hỏi doanh thu tháng, sửa một giả định, kiểm tra kết quả và xuất dữ liệu. Quan sát chỗ họ mất niềm tin hoặc phải làm lại. Những vấn đề này tạo backlog tốt hơn một danh sách tính năng AI chung chung.

Thử nghiệm hiện tại chứng minh điều gì?

Private Decision Lab đã minh họa routing song ngữ trên LXC dùng CPU. Encoder được giữ nguyên và các classifier head đã train trả về mẫu cố định hoặc đề xuất mô phỏng. Demo chưa sinh nội dung tự do, chưa kết nối cơ sở dữ liệu kinh doanh thật và không có công cụ thực thi hành động.

Case study triển khai bằng tiếng Anh trình bày bộ test nhỏ do cùng một tác giả viết và các lỗi đã quan sát. Đây là bằng chứng về tính khả thi, chưa chứng minh chất lượng production hay tương đương Jev. Các bài tiếp theo mô tả cách phát triển từ điểm khởi đầu đó bằng đo lường.

Thực hành: chuyển yêu cầu mơ hồ thành quyết định sản phẩm

Gọi sản phẩm tham chiếu giả định là Commerce Assist. Khách hàng đầu tiên là quản lý vận hành kiểm tra doanh thu tháng và giải thích thay đổi chính sách. Dataset dùng dữ liệu giả lập, USD và kỳ lịch theo UTC. Các ràng buộc này loại việc đổi tiền tệ và lịch kinh doanh mơ hồ khỏi thử nghiệm đầu. Client thật phải duyệt định nghĩa riêng của mình.

Bắt đầu bằng “Tháng trước tình hình của mình thế nào?”. Có ít nhất bốn quyết định ẩn: “mình” là đơn vị nào, đo chỉ số gì, tháng nào và cần so sánh ra sao. Workspace đã xác thực xác định tenant. Cấu hình báo cáo workspace có thể xác định chỉ số; nếu chưa có, hỏi người dùng. Tính ngày tương đối từ thời điểm request và múi giờ báo cáo, rồi hiển thị kỳ chính xác. Không cho model đoán tenant từ hội thoại.

Nhóm yêu cầu	Luồng ưu tiên	Lý do	Khi nào chuyển xử lý
“Mở trang sản phẩm”	Template điều hướng đã kiểm tra	Không cần sinh giải thích	Điểm đến chưa rõ
“Doanh thu thuần tháng 9/2026”	Plan chỉ số có cấu trúc + tool	Database quyết định giá trị	Thiếu định nghĩa chỉ số hoặc lịch báo cáo
“Chính sách hoàn tiền đổi gì?”	Retrieval phiên bản được phép + trả lời	Cần bằng chứng từ hai phiên bản	Thiếu phiên bản cần so sánh
“Vì sao doanh thu giảm?”	Tool so sánh + giải thích có giới hạn	Xác định thay đổi, chưa chứng minh nguyên nhân	Chiều phân tích cần thiết chưa hỗ trợ
“Hoàn tiền tất cả đơn đó”	Chuẩn bị đề xuất đúng phạm vi	Tác động tài chính cần quyền riêng	Release chưa cho ghi dữ liệu

Định lượng hậu quả trả lời sai

Không dùng cùng thước đo thành công cho điều hướng và quyết định tài chính. Điều hướng sai có thể mất vài giây. Bịa doanh thu có thể làm sai báo cáo quản lý. Lộ dữ liệu giữa tenant không thể bù bằng điểm trung bình tốt hơn. Áp dụng ngưỡng rủi ro trước khi tính lợi ích có trọng số.

Với workload minh họa 1.000 câu hỏi mỗi tháng, giả sử 600 câu về chỉ số thường lệ, 250 câu chính sách, 100 câu chưa rõ và 50 yêu cầu hành động. Nếu hệ thống trả lời cả 100 câu chưa rõ thay vì hỏi lại, completion rate cao có thể chỉ phản ánh sự tự tin quá mức. Tách bộ đếm hoàn thành đúng, làm rõ hữu ích, từ chối phù hợp và hoàn thành sai. Câu làm rõ không phải câu trả lời số thành công, nhưng cũng không tự động là thất bại.

Worksheet phát hành cần trả lời: ai duyệt danh mục chỉ số; ai chịu trách nhiệm độ mới tài liệu; yêu cầu nào bị chặn; thiếu nguồn thì làm gì; ai điều tra câu trả lời bị tranh chấp? Đây là quyết định ownership sản phẩm. Tech lead triển khai giới hạn, nhưng không tự định nghĩa doanh thu thay bộ phận tài chính.

Chọn lát cắt đầu tiên bằng trade-off rõ ràng

Chấm tác vụ theo tần suất, giá trị kinh doanh, bằng chứng sẵn có và hậu quả lỗi. Doanh thu thuần tháng có query rõ và nhu cầu lặp nên phù hợp bắt đầu. Khuyến nghị chiến lược mở có ít ground truth khách quan hơn nên không phù hợp làm acceptance test đầu. Thực thi hoàn tiền tạo vấn đề bảo mật, đối soát mới; giữ ngoài release chỉ đọc.

Deliverable đầu là một tình huống xuyên suốt: xác định workspace, chỉ số và kỳ, query đúng phạm vi, hiển thị bằng chứng và cho export được phép. Hoàn tất luồng trước khi thêm nhiều connector. Test với người không biết schema. Nếu họ không phân biệt số liệu tháng Chín với 30 ngày gần nhất, hợp đồng sản phẩm còn thiếu.

Đầu ra áp dụng vào project

Tạo phạm vi một trang, năm tình huống đại diện cho mỗi nhóm yêu cầu, định nghĩa chỉ số đã duyệt, rubric chấp nhận câu trả lời và danh sách capability bị chặn. Gán owner cho từng artifact. Với mỗi đề xuất tính năng, xác định tình huống được cải thiện và metric chứng minh cải thiện.

Bài tập hoàn thành là viết lại “xây chatbot AI cho sales” thành: “Người vận hành đã xác thực có thể hỏi doanh thu thuần theo tháng lịch, xem định nghĩa và kỳ thực tế, chỉ xuất kết quả tổng hợp được phép; thiếu phạm vi thì hỏi rõ, thiếu dữ liệu thì báo không khả dụng.” Yêu cầu này triển khai, test và so sánh kích thước model được.

Từ bài viết đến thử nghiệm chạy được

Benchmark và training là thử nghiệm trên dữ liệu giả lập do tác giả xây dựng, có các template tương quan. Không chứng minh tương đương model lớn hoặc chất lượng trên dữ liệu khách hàng. Model sinh plan được đo offline; demo công khai dùng baseline có kiểm soát. Benchmark: đã hoàn thành bốn candidate. LoRA: completed, 64/64 bước.

Lộ trình và kết quả thực nghiệm · Thử demo với dữ liệu giả lập · Tải code minh họa

Bài học từ triển khai này

Ví dụ chạy được chỉ nhận doanh thu thuần USD và kỳ tháng rõ ràng. Câu hỏi thiếu thời gian phải được làm rõ; profit, lọc khách hàng và thao tác ghi dữ liệu bị từ chối. Đây là hợp đồng sản phẩm có thể kiểm thử, không phải chatbot hiểu mọi câu hỏi.