Bài 1 — Vì sao Agent cần Vector Database làm bộ nhớ

Một AI agent không có bộ nhớ giống như nhân viên mất trí nhớ mỗi 5 phút: bạn nói tên mình, 3 câu sau nó hỏi lại. LLM chỉ "nhớ" những gì nằm trong context window của lượt gọi hiện tại. Hết lượt, hết nhớ. Vector database (vector DB) là nơi ta lưu lại kiến thức và ký ức để agent tra cứu khi cần.

Vấn đề cụ thể

Giả sử bạn xây một agent chăm sóc khách hàng. Khách A đã chat 40 lần trong 3 tháng. Nếu mỗi lần bạn nhét toàn bộ 40 cuộc chat vào prompt:

• Token phình to → chi phí tăng, chậm.
• Vượt context window (ví dụ 128k token) → lỗi.
• Nhiễu: model bị phân tâm bởi thông tin không liên quan.

Cách đúng: chỉ lấy ra những mẩu ký ức liên quan nhất đến câu hỏi hiện tại. Đó chính là việc vector DB làm — tìm theo ý nghĩa (semantic), không phải tìm theo từ khóa chính xác.

Embedding: chìa khóa của mọi thứ

Ta biến mỗi mẩu văn bản thành một vector (dãy số, ví dụ 1536 chiều) bằng một embedding model. Hai câu có ý nghĩa gần nhau sẽ có vector gần nhau trong không gian.

# Ví dụ tối giản
text = "Khách hàng phàn nàn giao hàng trễ"
vector = embed(text)   # -> [0.021, -0.44, 0.13, ... ] (1536 số)
# Lưu vector này kèm text gốc vào vector DB

Khi khách hỏi "Đơn của tôi bao giờ tới?", ta embed câu hỏi rồi tìm các vector gần nhất → lấy lại ký ức "phàn nàn giao hàng trễ" dù không trùng một từ nào.

3 loại bộ nhớ của agent

• Semantic memory — kiến thức/tài liệu (RAG): chính sách, sản phẩm, docs.
• Episodic memory — sự kiện đã xảy ra: "hôm 3/5 khách A đổi trả hàng".
• Working memory — tóm tắt hội thoại gần đây, thường giữ trong app, chỉ đẩy phần đáng nhớ xuống vector DB.

Vector DB chủ yếu phục vụ semantic và episodic memory.

Khung tư duy: Khi nào cần vector DB?

• Dữ liệu phi cấu trúc (văn bản, chat, tài liệu) → có.
• Cần tìm theo ý nghĩa thay vì khớp chính xác → có.
• Chỉ cần khớp ID/email chính xác → không, dùng SQL/key-value là đủ.
• Dữ liệu nhỏ (< vài nghìn mẩu), ít truy vấn → tạm dùng in-memory (FAISS) cũng được.

Các bước tối thiểu để agent "có trí nhớ"

• Chunk: cắt tài liệu/hội thoại thành mẩu vừa phải (200–500 token).
• Embed: biến mỗi mẩu thành vector.
• Store: lưu vector + text gốc + metadata (user_id, thời gian, nguồn) vào vector DB.
• Retrieve: khi có câu hỏi, embed câu hỏi, tìm top-k vector gần nhất.
• Augment: nhét các mẩu tìm được vào prompt gửi cho LLM.
• Write back: lưu thông tin mới đáng nhớ trở lại DB để dùng lần sau.

Checklist trước khi chọn công cụ (bài sau)

• [ ] Ước lượng số vector (nghìn / triệu / trăm triệu).
• [ ] Cần filter theo metadata phức tạp không?
• [ ] Có sẵn Postgres trong hệ thống không?
• [ ] Muốn tự host hay dùng managed cloud?
• [ ] Ngân sách và yêu cầu độ trễ (latency).

Sai lầm thường gặp

• Nhồi cả lịch sử vào prompt thay vì retrieve có chọn lọc — đốt token vô ích và làm model kém tập trung.
• Nhầm vector DB với LLM: vector DB không "hiểu", nó chỉ tìm vector gần nhau. Chất lượng embedding quyết định chất lượng tìm kiếm.
• Quên lưu text gốc: chỉ lưu vector thì lúc trả về không có gì để đưa vào prompt. Luôn lưu payload (text + metadata).
• Bỏ qua write-back: agent tra cứu nhưng không bao giờ ghi lại ký ức mới → mãi không thông minh lên.

Kết bài: vector DB là "hồi hải mã" của agent. Bài sau ta sẽ so 4 lựa chọn phổ biến để chọn đúng công cụ cho hoàn cảnh của bạn.