Tôi nhét 372 dịch vụ vào Claude — rồi ra lệnh đừng tự nhớ giá của cái nào

Tôi nhét 372 dịch vụ và 193 sản phẩm vào con bot. Rồi ra đúng một luật: không được tự nhớ giá của bất kỳ cái nào.

Nghe ngược đời. Nếu bot đã "biết" toàn bộ bảng giá, sao còn cấm nó trả lời từ kiến thức đó? Câu trả lời nằm ở một tính chất rất cơ bản của LLM: nó không tra cứu — nó xác suất. Và xác suất không bao giờ đủ tốt khi khách hỏi giá.

Khi "để Claude tự nhớ" bắt đầu lung lay

Hồi đầu tôi nhồi nguyên bảng giá vào system prompt. Với một spa và một bot, cách đó hoạt động ổn — tôi đã kể về lựa chọn đó trong bài RAG hay Tool Use. Bộ kiến thức nhỏ, nhét vừa cửa sổ ngữ cảnh, Claude đọc và trả lời đúng. Đơn giản.

Vấn đề nảy sinh khi tôi bắt đầu nghĩ đến việc phục vụ nhiều spa. Mỗi spa một bảng giá riêng. Bảng giá thay đổi thường xuyên — khuyến mãi, điều chỉnh giá mùa vụ, thêm dịch vụ mới. Nếu giá nằm trong system prompt, mỗi lần spa đổi giá tôi phải sửa prompt thủ công. Không ổn.

Nhưng có một vấn đề sâu hơn tôi mới nhận ra: Claude không thực sự "tra cứu" giá từ prompt — nó tổng hợp câu trả lời dựa trên mọi thứ nó thấy. 99% thời gian nó đọc đúng. Nhưng khi bảng giá dài, khi tên dịch vụ giống nhau, khi có nhiều biến thể gói — 1% sai còn lại không phải là lỗi kỹ thuật. Nó là niềm tin bị phá vỡ.

Khách spa hỏi "liệu trình Thermage giá bao nhiêu" không chấp nhận "gần đúng". Họ sẽ dựa vào con số đó để quyết định đặt lịch hay không. Sai một chữ số 0 là mất khách, mất uy tín của cả spa lẫn dịch vụ của tôi.

Chia hai lớp: cái gì đúng tuyệt đối, cái gì đúng đủ tốt

Tôi quyết định chia kiến thức của bot thành hai lớp với hai cơ chế hoàn toàn khác nhau.

Lớp CATALOG — structured, exact. Mọi thứ cần đúng tuyệt đối: tên dịch vụ, giá tiền, đơn vị tính, trạng thái còn áp dụng hay không. Lưu trong bảng cơ sở dữ liệu có cấu trúc rõ ràng. Bot đọc live từ đây mỗi khi cần trả lời về giá hay thông tin cụ thể — không bao giờ từ ký ức tổng hợp.

Lớp CORPUS — semantic, "đủ tốt". Mô tả liệu trình, tư vấn công nghệ, chính sách spa, giọng thương hiệu. Những thứ cần hiểu theo ngữ nghĩa, cần trả lời tự nhiên và gợi cảm giác. Lưu dưới dạng embedding, truy hồi khi bot cần giải thích hay tư vấn sâu.

Ranh giới giữa hai lớp rất rõ: nếu câu trả lời sai dù chỉ 1% là vấn đề, nó thuộc lớp CATALOG. Tất cả phần còn lại có thể vào CORPUS.

Cái guardrail tôi ép vào kiến trúc

Tôi không chỉ phân chia trên giấy. Tôi ép nó vào code và vào system prompt của bot theo đúng một luật cứng: dữ kiện chính xác — giá, tình trạng còn hay hết, thông số cụ thể — không bao giờ được lấy từ embedding hay từ bộ nhớ tổng hợp của model. Chỉ từ structured lookup.

Trong thực tế, bot có một bộ công cụ (tool use) để tra cứu catalog trực tiếp. Khi khách hỏi giá, bot không "nhớ" và trả lời — nó gọi tool, lấy con số từ cột price_vnd của đúng cái row trong database, rồi mới trả lời. Con số khách nhận được không phải xác suất — nó là sự thật được đọc lúc đó.

Có một chi tiết thú vị: các mô tả dịch vụ được tự động tạo thành embedding từ thông tin trong CATALOG. Tức là khi tôi thêm một dịch vụ mới, nó tự được "học" vào corpus để bot có thể tư vấn theo ngữ nghĩa — "liệu trình này phù hợp với ai, cảm giác thế nào, kết hợp được với gì". Nhưng khi khách hỏi giá dịch vụ đó, bot không đọc giá từ embedding đã học. Embedding chỉ giúp bot tìm đúng dịch vụ để tư vấn — giá thì vẫn đọc thẳng từ database.

Hai lớp dùng cùng dữ liệu gốc. Nhưng chúng trả lời hai loại câu hỏi khác nhau, bằng hai cơ chế hoàn toàn khác nhau.

Vì sao điều này quan trọng hơn tôi tưởng ban đầu

Khi một người làm dịch vụ thuê bao tháng, niềm tin là sản phẩm thật. Bot chạy đúng 99% — nhưng nếu 1% sai xảy ra trên câu hỏi về giá, khách spa sẽ nhớ mãi cái 1% đó.

Kiến trúc hai lớp này cũng giải quyết bài toán vận hành: khi spa đổi giá một liệu trình, nhân viên của họ sửa trong cổng quản lý — bot cập nhật ngay lần hỏi tiếp theo, không cần tôi động tay vào prompt. Dữ liệu thay đổi ở đúng nơi nó nên thay đổi, và bot đọc từ đúng nguồn đó.

Đây là bài học tôi rút ra sau nhiều lần build: người làm AI không phải người để AI làm hết mọi thứ. Biết chỗ nào LLM giỏi hơn database, và chỗ nào database đáng tin hơn LLM — đó mới là nghề.

LLM giỏi nhất với câu hỏi có nhiều nghĩa đúng: "liệu trình này có phù hợp với da mình không?". Database đáng tin nhất với câu hỏi chỉ có một đáp án đúng: "giá dịch vụ này là bao nhiêu?". Đừng nhầm vai.

👉 Muốn tự tay xây một con bot và hiểu rõ khi nào nên để AI trả lời, khi nào nên tra database — đó là một trong những bài học thực chiến trong mini-course miễn phí: Bot AI đầu tiên của bạn. Làm xong trong một buổi tối, có thứ chạy được ngay đêm đó.