Chào mừng bạn đến với chuyên đề Agentic E-commerce Search.
Trong hệ sinh thái thương mại điện tử năm 2026, thanh tìm kiếm (Search Bar) không còn là một công cụ thụ động chỉ biết “khớp từ khóa”. Người dùng kỳ vọng những cỗ máy tìm kiếm có khả năng tư duy như một trợ lý mua sắm thực thụ: hiểu ngữ nghĩa phức tạp, phân tích các điều kiện ràng buộc khắt khe (giá cả, tồn kho, vị trí), và có khả năng tương tác trực tiếp với các microservices để đưa ra câu trả lời theo thời gian thực.
Series này là một bản thiết kế kiến trúc thực chiến (Architecture Blueprint) giúp các kỹ sư Backend và AI Architects gỡ bỏ giới hạn của Semantic Search truyền thống. Chúng ta sẽ cùng nhau xây dựng một cỗ máy Agentic Search hoàn chỉnh, sử dụng sức mạnh xử lý đồng thời của Golang, engine vector mạnh mẽ của Qdrant, và khung điều phối Multi-Agent từ Eino (CloudWeGo).
Cấu Trúc Series#
Series được chia thành 6 phần chuyên sâu, đi từ mô hình kiến trúc lõi cho đến các kỹ thuật tối ưu hóa chi phí trên môi trường Production:
💡 Kim chỉ nam: Loạt bài viết này sẽ không dừng lại ở mức “Proof of Concept” (PoC) viết bằng Python. Chúng ta sẽ tiếp cận bằng tư duy Systems Engineering với Golang, tập trung vào tính an toàn kiểu dữ liệu (Type Safety), hiệu năng xử lý đồng thời (Concurrency), và tính khả thi về mặt chi phí (Unit Economics) khi vận hành ở scale lớn.
Hệ thống tìm kiếm là trái tim của mọi nền tảng thương mại điện tử. Nếu khách hàng không thể tìm thấy sản phẩm, họ sẽ không mua nó.
Trong một thập kỷ qua, khi nói đến Search, mặc định chúng ta nói về Elasticsearch (với thuật toán BM25). Tuy nhiên, khi hành vi tìm kiếm của người dùng thay đổi—từ việc gõ những từ khóa cộc lốc (“giày chạy bộ nam”) sang những câu lệnh dài, chứa đầy ý định phức tạp (“tìm cho tôi một đôi giày chạy trail chống nước, size 42, dưới 2 triệu, có thể giao hàng trong hôm nay”), các cỗ máy tìm kiếm truyền thống bắt đầu bộc lộ tử huyệt.
...
Nếu bạn đã từng thử đưa một hệ thống RAG hoặc Multi-Agent viết bằng Python (sử dụng LangChain hay AutoGen) lên môi trường Production với hàng ngàn request đồng thời, chắc hẳn bạn đã nếm mùi đau khổ. Máy chủ cạn kiệt RAM, CPU nghẽn cổ chai, và độ trễ (latency) nhảy vọt một cách không kiểm soát.
Nguyên nhân không nằm ở các mô hình LLM. Nguyên nhân nằm ở chính kiến trúc điều phối (Orchestration Architecture) mà bạn đang sử dụng.
...
Trong Phần 1: The Paradigm Shift - Kiến Trúc Agentic & Sức Mạnh Điều Phối Của Golang, chúng ta đã thiết lập bộ não điều phối (Orchestration Engine) bằng Golang và Eino. Tuy nhiên, một bộ não thông minh đến đâu cũng sẽ trở nên vô dụng nếu nó được tiếp nạp thông tin sai lệch, thiếu cấu trúc hoặc bị cắt vụn.
Trong bài toán e-commerce, dữ liệu catalog sản phẩm thay đổi liên tục từng giây: giá cả biến động, tồn kho cập nhật, sản phẩm mới được thêm vào. Đồng thời, việc chia nhỏ (chunking) dữ liệu sản phẩm để đưa vào Vector Database (Qdrant) hoàn toàn khác biệt so với việc chia nhỏ một tài liệu PDF hay một bài báo.
...
Trong Phần 2: Data Ingestion & E-commerce Chunking - Đưa Dữ Liệu Sản Phẩm Vào Môi Trường AI, chúng ta đã thiết lập một pipeline đồng bộ dữ liệu sạch sẽ từ PostgreSQL sang Qdrant qua Kafka CDC. Nhưng hành trình xây dựng một hệ thống tìm kiếm chuẩn e-commerce chỉ mới bắt đầu.
Khi người dùng nhập: “laptop Asus ROG Zephyrus G14 giá dưới 30 triệu còn hàng”
Nếu sử dụng Dense Vector Search thuần túy: Hệ thống có thể trả về các laptop Asus ROG Zephyrus khác nhưng giá 45 triệu, hoặc thậm chí máy cũ đã hết hàng, vì mô hình Embedding chỉ hiểu được độ tương đồng ngữ nghĩa chung chung chứ không xử lý được các phép so sánh số học cứng (Hard Filters như price < 30,000,000 và in_stock = true). Nếu sử dụng Lexical Search (BM25) thuần túy: Hệ thống sẽ thất bại khi người dùng tìm kiếm theo ý định như “máy tính chơi game mỏng nhẹ hiệu năng cao”, vì các từ khóa này không xuất hiện trực tiếp trong văn bản mô tả sản phẩm. Giải pháp tối ưu cho e-commerce là Hybrid Search — kết hợp Dense Search (hiểu ngữ nghĩa), Sparse Search/BM25 (khớp từ khóa chính xác, mã SKU) và Filterable HNSW (lọc thuộc tính cứng hiệu năng cao).
...
Trong Phần 3: Làm Chủ Qdrant Hybrid Search - Giải Bài Toán Semantic và Hard Filters, chúng ta đã xây dựng thành công một engine tìm kiếm Hybrid mạnh mẽ, kết hợp giữa Dense Semantic và Sparse Lexical Search. Tuy nhiên, một hệ thống tìm kiếm e-commerce thực chiến không chỉ đơn thuần là việc lấy ra các văn bản tĩnh từ cơ sở dữ liệu vector.
Ví dụ, người dùng hỏi: “Tôi muốn mua tủ lạnh Samsung Inverter 400L có sẵn tại chi nhánh Quận 1 và đang được áp dụng khuyến mãi.” Nếu chỉ dựa vào Vector Database, chúng ta sẽ gặp hai lỗi nghiêm trạng:
...
Trong Phần 4: Active RAG & Strict Tool Calling - Kết Nối LLM Với Real-time Inventory API, chúng ta đã xây dựng thành công một đồ thị ReAct tuần hoàn để cho phép LLM gọi các API kiểm tra tồn kho và lấy thông tin khuyến mãi theo thời gian thực. Tuy nhiên, trong môi trường sản xuất thực tế, việc LLM có quyền truy cập vào các công cụ (Tools) vẫn chưa đủ để đảm bảo độ chính xác tuyệt đối.
...
Trong Phần 5: The Self-Reflection Critique Loop - Kỹ Thuật Ngăn Chặn Hallucination, chúng ta đã xây dựng thành công bộ kiểm duyệt câu trả lời tự động để đảm bảo độ chính xác logic. Tuy nhiên, khi đưa hệ thống Agentic Search này lên môi trường production quy mô lớn phục vụ hàng triệu người dùng, bạn sẽ lập tức đối mặt với những thách thức vận hành thực tế:
...