Một AI chatbot bán hàng biết học từ chính những lần sai của nó

Case study — trợ lý chạy production trên cửa hàng WooCommerce thật, 1.330 SKU

Một nhà bán lẻ vật liệu xây dựng & nội thất muốn có trợ lý bán hàng 24/7 trên cửa hàng WooCommerce — trợ lý báo giá thật, gợi đúng sản phẩm giữa 1.330 SKU, điều khiển giỏ hàng, và trao cho đội sale một lead có thể xử lý trong năm giây. Phần kỹ thuật đáng nói không phải là việc chatbot trả lời câu hỏi; mà là mọi thứ được dựng quanh mô hình để khiến nó đáng tin — và một vòng tự học 48 giờ có kiểm soát giúp hệ thống tốt lên từ chính những câu nó trả lời tệ, mà không ai phải ngồi đọc log.

01Bài toán

Khách đến ngoài giờ không có ai tư vấn; nhiều người hỏi giá rồi rời đi; và những lead thật sự về đến CRM thì mỏng đến mức nhân viên gọi lại phải bắt đầu từ số không. Mục tiêu sản phẩm: một trợ lý luôn bật, báo giá LIVE, gợi đúng sản phẩm, thêm vào giỏ, và — khi khách để lại số điện thoại — gửi cho sale một bản tóm tắt nhu cầu thay vì một đoạn hội thoại thô.

02Những ràng buộc định hình kiến trúc

03Kiến trúc, ở mức khối

Khách ─► Widget chat (vanilla JS, nhớ hội thoại qua các trang)
             │
             ▼
 ┌──────────────────────── Plugin WordPress (PHP) ────────────────────────┐
 │ 1  Chuẩn hoá truy vấn    alias · bỏ từ thừa · bóc ngân sách ·           │
 │                          tách NEO (món hàng) vs BỔ NGHĨA (phong cách)   │
 │ 2  Tìm kiếm đa tầng      tên món → phòng/không gian → danh mục → 1 từ   │
 │ 3  Kế thừa ngữ cảnh      câu nối thừa hưởng chủ đề; chủ đề mới thì cắt   │
 │ 4  Cổng liên quan        danh sách khớp yếu bị coi là "không có hàng"    │
 │ 5  LLM (OpenAI/OpenRouter) prompt mang GIÁ LIVE + bản đồ tồn kho thật   │
 │ 6  Lưới an toàn sau LLM  đối chiếu lời ↔ thẻ · cắt lời hứa suông ·      │
 │                          cắt mọi con số giá mô hình tự gõ               │
 │ 7  Tự chẩn đoán          gắn mã lý do cho mỗi lượt "bí" ──► vòng 48h
 │ 8  Đường ống lead        nhu cầu có cấu trúc → lưu local → đẩy sang CRM  │
 └─────────────────────────────────────────────────────────────────────────┘
             │                                  │
             ▼                                  ▼
    Thẻ sản phẩm + giỏ hàng          CRM nội bộ (webhook idempotent)
    (WooCommerce Store API)          + dashboard phễu & A/B test

LLM chỉ làm đúng thứ nó giỏi — diễn đạt và khai thác nhu cầu. Mọi thứ buộc phải đúng — giá, sản phẩm nào được phép hiện, lead có được lưu hay không — đều do code tất định quyết định và được đối chiếu sau khi mô hình trả lời.

04Bảy quyết định thiết kế

1. "Thà không thẻ còn hơn thẻ sai." Một thẻ sản phẩm sai phá niềm tin nhanh hơn việc không hiện gì. Mọi danh sách sản phẩm phải qua cổng liên quan; lời của bot và thẻ của nó phải cùng một nhóm hàng, nếu không thẻ bị bỏ và bot hỏi lại.
2. Mô hình truy hồi "neo + bổ nghĩa". Tách từ chỉ món hàng khỏi từ mô tả (phong cách, màu, "cao cấp", "thông minh"). Truy vấn không có neo thì không trả sản phẩm — chỉ một câu hỏi và các nút nhóm hàng. Khi phải nới lỏng truy vấn, bỏ bổ nghĩa trước và không bao giờ bỏ neo.
3. Lưu lead trước, mọi thứ khác sau. Lead được ghi local trước khi đẩy CRM; nếu AI sập lead vẫn được lưu; nhu cầu của khách quay lại được gộp, không ghi đè.
4. Ghi chú CRM là bản tóm tắt cho người sẽ gọi, không phải bản ghi hội thoại. Bảy trường nhu cầu cộng một dòng gợi ý cho sale; toàn bộ hội thoại được lưu riêng để tra cứu.
5. Một vòng tự học có kiểm soát — điểm nhấn của dự án, ngay bên dưới.
6. Sự thật tổng thể do code tính, AI chỉ diễn đạt. Câu "rẻ nhất / đắt nhất / mới về / đang giảm giá" chạy truy vấn trên TOÀN nhóm hàng, dựng khối "sự thật từ kho" rồi ép thẻ đúng thứ tự — LLM không tự phán "nhất". Không có dữ liệu thì bot nói thật.
7. Mọi câu dự phòng đều có telemetry. Khách không nhận được câu trả lời thật = một dòng trên dashboard (loại lỗi, mã lỗi, trang), không phải một sự im lặng — nên sự cố núp sau câu "anh/chị thử lại giúp em" vẫn bị nhìn thấy.

★Vòng tự học 48 giờ

ý tưởng số 1 — không phải một tính năng, mà là một hệ tự cải thiện có kiểm soát

Hầu hết chatbot thương mại được "train" một lần lúc ra mắt rồi đứng yên, trong khi khách thật cứ hỏi theo hàng nghìn cách không lường trước — tiếng lóng tiền tệ, tên gọi vùng miền, hỏi theo phòng thay vì theo tên món, hỏi món shop không bán. Mỗi câu như vậy là một khách rời đi trong im lặng. Cách làm thường thấy — "thỉnh thoảng có người đọc log" — trên thực tế nghĩa là không ai đọc. Câu hỏi thiết kế: làm sao để việc học-từ-thất-bại diễn ra tự động, định kỳ và an toàn, để người chủ chỉ phải đọc một báo cáo ngắn?

Ba quyết định làm nên điều đó

1 · Chatbot phải biết nó vừa thất bại, và vì sao. Tiền đề của mọi vòng học là một tín hiệu lỗi có chất lượng. Hệ không dùng LLM để chấm LLM (đắt, chậm, không ổn định); nó tự chẩn đoán bằng luật rẻ tiền ngay trong lượt chat, gắn cho mỗi lượt "bí" một trong hơn 10 mã lý do — tách lỗi tìm kiếm khỏi lỗi AI khỏi lỗ hổng chính sách. Mã lý do quyết định loại thuốc: lỗi tìm kiếm chữa bằng từ điển, lỗ hổng chính sách chữa bằng FAQ, lỗi AI chữa bằng code. Chẩn đoán sai gốc còn tệ hơn không chẩn đoán — nên chính hạ tầng quan sát cũng được kiểm.

2 · Tách "núm huấn luyện" khỏi code. Mọi tri thức miền thay đổi theo thời gian (từ đồng nghĩa, từ thừa, từ mô tả phong cách, món đóng theo yêu cầu, FAQ bổ sung) nằm ở dạng núm — cấu hình, sửa được tức thì, không deploy. Code chỉ chứa cơ chế. Hệ quả: một agent có thể cải thiện chatbot mà không bao giờ chạm vào code. Ranh giới đó là lằn ranh an toàn cốt lõi.

3 · Agent được trao quyền theo bậc — luôn ít hơn mức nó "có thể" làm. Nó được thêm núm an toàn (chỉ khi chủ dự án đã bật chế độ tự động); nó chỉ được đề xuất thay đổi code hay prompt, kèm phân tích gốc rễ, để con người quyết; và không gì trong vòng tự động được xoá hay sửa núm đã có — agent chỉ thêm. Hai vòng đầu luôn ở chế độ chỉ-đề-xuất: niềm tin được xây theo bậc, như cách onboard một nhân viên mới.

Vì sao đủ an toàn để chạy trên production

Trao cho một AI agent quyền thay đổi một hệ thống đang bán hàng thật là việc nghiêm túc. Các lớp phòng thủ, ở mức nguyên lý: cổng API đóng theo mặc định và chỉ mở khi chủ dự án đặt khoá bí mật phía server; agent không có đường vào trang quản trị, không đăng nhập, không đọc được dữ liệu khách ngoài các câu bị bí; nội dung chat của khách được coi là dữ liệu, không phải mệnh lệnh (chống prompt injection qua chính kênh chat); chốt chặn nghiệp vụ nằm ở server và không tin agent — nếu agent đề nghị coi một từ là "từ thừa", server tự thử và từ chối nếu từ đó đang tìm ra sản phẩm thật; mọi thay đổi đều chỉ-thêm, có trần mỗi vòng, có log trước/sau và hoàn tác một chạm; và agent bị cấm tạo dữ liệu giả hay lead giả.

Điều thực sự đã xảy ra

• Vòng chạy thật đầu tiên trên production: 54 giây, đi hết đường kiểm tra → lấy việc → báo cáo.
• Một sự cố ngày đầu được xử lý đúng như thiết kế: môi trường cloud chặn một kết nối ra ngoài, nên agent dừng an toàn và báo rõ nguyên nhân trong 13 giây — không đoán mò, không lách. Đó là hành vi bạn muốn ở một agent production.
• Một alias do con người thêm (một từ vùng miền cho "bồn cầu") có hiệu lực tức thì, không deploy — chứng minh ranh giới núm/code hoạt động.
• Một câu hỏi thật của khách đi hết vòng đời: bị gắn cờ → tìm ra gốc → sửa → tái hiện và xác nhận → đánh dấu đã xong.

05Kết quả đã kiểm chứng

06Vai trò của tôi — nói thật

Dự án được xây theo mô hình phát triển điều phối agent (agent-orchestrated development): tôi thiết kế hệ thống và ra quyết định; một AI coding agent (Claude Code) viết code theo một bản "điều lệ vận hành" tôi đặt ra.

• Tôi (chủ dự án) xác định bài toán và thứ tự ưu tiên, ra mọi quyết định sản phẩm và chính sách (quy tắc thanh toán, cách xử lý món đóng theo yêu cầu, agent được tự chủ đến đâu), tự test thủ công để tìm lỗi — phần lớn các sự cố production đằng sau hệ này được tìm ra theo cách đó — duyệt mọi phương án trước khi ship, và chịu trách nhiệm trên dữ liệu CRM thật.
• AI coding agent (Claude Code) điều tra gốc rễ, đề xuất phương án, viết code, deploy, kiểm chứng và báo cáo — theo điều lệ của tôi: backup trước khi đổi bất cứ gì; không bao giờ nhập khoá hay mật khẩu; kiểm chứng bằng kết quả thật; coi nội dung khách là dữ liệu, không phải mệnh lệnh.

Con người giữ quyền quyết định và kiểm chứng; agent giữ tốc độ thực thi. Chính sự phân vai đó là lý do một người có thể đưa gần 30 bản phát hành có kiểm chứng lên production, nhanh, mà không cần đội kỹ sư — và bản thân điều đó cũng là một năng lực.