10 Bài Học Thực Chiến Khi Xây Dựng Ecommerce AI Chatbot Với LangGraph

Trong lúc có nhiều người vẫn nghi ngờ việc Agentic AI có thể ứng dụng trong thực tế như thế nào, thì mình đang triển khai một MVP mà nếu dự án này thành công — có lẽ nhiều người sẽ phải... ra đường.

Xin chào các bạn, lâu ghê không post một bài, bởi vì hơn 1 tháng nay mình đang bận xây dựng một Ecommerce Assistant — có thể gọi là Chatbot cho việc bán hàng. Nhờ cơ hội móc nối với một nền tảng có sẵn 30–40.000 shop, triển khai thử nghiệm Ecommerce Chatbot mà mình tin rằng thông minh hơn đa số các chatbot đang được tích hợp vào các trang bán hàng ngoài thị trường, có khả năng thay thế các vị trí Sale, Trực page, Chăm sóc khách hàng... Và nếu MVP này thành công thì sao? Chẳng phải là rất nhiều người đang làm các vị trí đó phải ra đường hay sao?

Nhưng bài viết này không phải để khoe — mà có thể nó sắp trở thành một minh chứng thực tế cho sức mạnh của Agentic AI áp dụng vào thực tế. Mục đích chính của bài này là chia sẻ lại những key takeaways mình vọc vạch được sau khi vật lộn với dự án này xuyên Tết.

Tệp người đọc hướng tới các bạn lập trình viên đang quan tâm tới việc tích hợp AI vào các dự án từ đơn giản tới phức tạp nhất (AI Application Engineer) nói chung, và các bạn đang muốn xây dựng những Agentic AI thông minh nói riêng.

Sơ qua về Chatbot: Tại sao nó có thể thay thế nhân viên bán hàng?

1. Query Expansion — Đừng để LLM chịu trách nhiệm hiểu hết ngôn ngữ người dùng

Khách gõ "sữa hạt" nhưng trong database tên sản phẩm là "Sữa Hạt Macca Nguyên Chất 500ml". Vector search có thể tìm được, nhưng không phải lúc nào cũng chính xác — đặc biệt với tiếng Việt và tên sản phẩm đặc thù.

Mình xây 1 lớp Query Expansion chạy TRƯỚC khi search:

"sữa hạt" → ["sữa hạt", "sữa hạt macca", "sữa hạt điều", "sữa hạt óc chó"...]

Dùng synonym dictionary (~70 entries viết tay + auto-expand từ catalog).

3. Multi-Intent: Parallel và Sequential — Khách nói 1 câu nhưng muốn 2 thứ

"Tìm sữa hạt rồi thêm 2 lọ dầu dừa vào giỏ" — đây là 2 intent khác nhau. Nếu chatbot chỉ xử lý 1 thì khách bực lắm.

Mình dùng node Supervisor với Chain-of-Thought reasoning — bắt LLM phải giải thích suy luận TRƯỚC khi commit intent. Sau đó tách thành sub-queries, route vào đúng node chuyên biệt.

Nhưng đây mới là phần hay: KHÔNG PHẢI cặp intent nào cũng chạy song song được.

Mình define 1 whitelist các cặp an toàn để parallel, còn lại default sequential. Code quyết định, không phải LLM.

4. Conversation Memory — Chatbot không nhớ thì không bằng Google

Chat được 20–30 tin nhắn mà chatbot quên sạch context, hỏi lại từ đầu — khách bỏ đi.

Nhưng nhồi hết 50 tin nhắn vào context LLM cũng không ổn — tốn token, chậm, và có 1 hiện tượng gọi là "Lost in the Middle" — LLM chú ý đầu và cuối tin nhắn tốt, nhưng quên mất thông tin ở giữa.

Mình xây 3 tầng memory:

5. Làm Tool càng xịn, Chatbot càng thông minh

Nhiều người tập trung prompt engineering nhưng quên mất: chatbot chỉ thông minh bằng TOOLS mà nó có.

6. Vector Search thôi chưa đủ — Cần thêm Reranking

Vector search (semantic) hiểu ý tốt — "đồ uống lành mạnh" tìm được sữa hạt, trà thảo mộc. Nhưng exact match thì kém — khách gõ đúng tên sản phẩm mà có khi trả kết quả khác.

Mình thêm 1 lớp reranking sau vector search — chấm điểm lại kết quả bằng code thuần:

Chạy trên server, 0 API call thêm, mà chất lượng kết quả tăng 20–35%. Rẻ mà hiệu quả.

7. Implement CRAG (Corrective RAG) — Đừng trả "Không tìm thấy" ở lần đầu

Khách hỏi "sữa hạt bán chạy nhất" — vector search trả kết quả kém — chatbot nói "không tìm thấy" — khách bỏ đi. Nhưng search lại với "sữa hạt" đơn giản hơn thì có kết quả!

Mình implement self-check theo 4 bước:

Chi phí thêm 1 lần gọi LLM khi fail, nhưng giảm ~30% tỷ lệ chatbot từ chối trả lời. Khách không bị bỏ rơi.

8. Chỉ rõ giới hạn chức năng — Đừng để Chatbot bịa

Đây là điểm nhiều chatbot AI dở: khách hỏi gì cũng trả lời, kể cả bịa. "Sản phẩm này review 5 sao" — trong khi hệ thống không có review.

Mình define rõ ràng trong prompt và code: chatbot BIẾT mình không có tính năng review, không có mã giảm giá, không track đơn. Khi khách hỏi — trả lời thẳng thắn "chưa hỗ trợ", gợi ý liên hệ shop, chứ không hallucinate.

Ngoài ra, mình dùng structured output với field unsupportedReason:

// LLM phải classify LÝ DO không hỗ trợ
type UnsupportedReason =
  | "no_review_system"
  | "no_promotion_data"
  | "no_store_info";

// → Response template phù hợp với từng trường hợp

detect keyword ("đắt nhất", "rẻ nhất")
  → code sort mảng theo giá
  → chọn đúng cái
  → inject cho LLM format response

10. Response Merger — Nhiều Node trả lời thì phải gộp thông minh

Khi chatbot xử lý 2–3 intent cùng lúc, mỗi node trả 1 đoạn response riêng. Nối bằng xuống dòng — tin nhắn rời rạc, lặp lời chào, thiếu tự nhiên.

Mình dùng 1 node Response Merger — nhận N đoạn response, mỗi đoạn được gắn type với thứ tự ưu tiên:

LLM viết lại thành 1 tin nhắn tự nhiên, mạch lạc.

Nhìn lại: 3 điều quan trọng nhất

10 bài học trên là kết quả của hơn 1 tháng vật lộn với thực tế. Có vài điều mình muốn nhấn mạnh:

• Prompt engineering có giới hạn — tool engineering, architecture engineering mới là nơi tạo ra sự khác biệt thật sự.
• Code phải kiểm soát LLM, không phải ngược lại. Mọi logic deterministic phải do code xử lý.
• Trải nghiệm người dùng là vua — chatbot thông minh nhưng trả lời rời rạc, quên context, hay bịa thì vẫn bị bỏ.