Bài 8 — Vận hành production: chunking, cập nhật, chi phí, giám sát

Demo chạy được không có nghĩa là production ổn. Bài này gom các quyết định vận hành khiến bộ nhớ agent bền, rẻ và đáng tin: chunking, cập nhật/xóa, chi phí, và giám sát.

1. Chunking đúng cách

Chunk quá to → vector "loãng", tìm kém chính xác. Chunk quá nhỏ → mất ngữ cảnh, nhiều mảnh vụn.

• Kích thước khởi điểm: 200–500 token, overlap 10–15% để không cắt đứt ý.
• Cắt theo ranh giới ngữ nghĩa (đoạn văn, mục) thay vì cắt cứng theo số ký tự.
• Với hội thoại: chunk theo turn hoặc tóm tắt từng đoạn rồi mới embed.
• Lưu doc_id + chunk_index để ghép lại và xóa theo tài liệu.

def chunk(text, size=400, overlap=60):
    words = text.split()
    step = size - overlap
    return [" ".join(words[i:i+size]) for i in range(0, len(words), step)]

2. Cập nhật và xóa (thường bị quên)

Tài liệu đổi, khách yêu cầu xóa dữ liệu (GDPR). Bộ nhớ phải upsert và delete được.

• Upsert theo id ổn định: dùng id suy ra từ nội dung/doc_id:chunk để ghi đè thay vì tạo trùng.
• Xóa theo filter: delete where doc_id = X hoặc user_id = X (quyền được quên).
• Tránh vector mồ côi: khi tài liệu bị cắt ngắn, xóa các chunk cũ dư ra.

# Qdrant upsert với id ổn định
point_id = f"{doc_id}:{idx}"
c.upsert("mem", points=[{"id": point_id, "vector": vec, "payload": payload}])
# xóa theo filter (quyền được quên)
c.delete("mem", points_selector=Filter(must=[
    FieldCondition(key="user_id", match=MatchValue(value=42))]))

3. Chi phí — hai nguồn tốn tiền

• Embedding: mỗi lần ghi/re-embed đều tốn token. Đừng embed lại mẩu không đổi → cache theo hash nội dung.
• Lưu trữ + RAM: hàng triệu vector float32 rất nặng. Dùng quantization (bài 4) và cân nhắc tier lưu trữ.

Mẹo: cache embedding theo hash text; chỉ embed khi nội dung thực sự thay đổi.

import hashlib
def cached_embed(text):
    h = hashlib.sha256(text.encode()).hexdigest()
    return cache.get(h) or cache.set(h, embed(text))

4. Giám sát chất lượng retrieval

Đừng chỉ theo dõi uptime — theo dõi chất lượng tìm kiếm:

• Recall@k trên bộ câu hỏi vàng, chạy định kỳ (cảnh báo khi tụt).
• Điểm tương đồng trung bình của top-1: tụt bất thường có thể do lệch model.
• Tỉ lệ "không tìm thấy gì trên ngưỡng": cao → thiếu dữ liệu hoặc embedding lệch.
• Latency p95 truy vấn.
• Log truy vấn + kết quả (ẩn danh) để debug và cải tiến.

5. Độ tin cậy

• Backup: pgvector đi theo backup Postgres; DB chuyên dụng cần snapshot collection.
• Re-embedding có kế hoạch: khi đổi model, chạy nền song song, chuyển đổi khi xong — đừng để lẫn hai hệ quy chiếu.
• Idempotent ingest: chạy lại pipeline không được tạo bản trùng.

Checklist go-live

• [ ] Chiến lược chunking + overlap đã chốt và test.
• [ ] Upsert theo id ổn định; xóa theo filter hoạt động.
• [ ] Cache embedding theo hash để giảm chi phí.
• [ ] Payload/field filter đều có index.
• [ ] Bộ câu hỏi vàng + đo recall@k định kỳ.
• [ ] Cảnh báo latency p95 và điểm tương đồng trung bình.
• [ ] Kế hoạch backup + re-embedding.
• [ ] Đường xóa dữ liệu theo user (compliance).

Sai lầm thường gặp

• Chunk cứng theo ký tự cắt đứt câu → vector méo, retrieve kém.
• Không có đường xóa theo user → vi phạm quyền được quên, rủi ro pháp lý.
• Insert thay vì upsert khi tài liệu cập nhật → nhân bản chunk, kết quả trùng lặp, tốn chỗ.
• Embed lại mọi thứ mỗi lần deploy → hóa đơn token khổng lồ; hãy cache.
• Chỉ giám sát uptime: hệ "sống" nhưng recall đã tụt âm thầm mà không ai biết.
• Đổi embedding model rồi query ngay mà chưa re-embed dữ liệu cũ → chất lượng sập ngầm.

Kết khóa: bạn đã đi trọn từ khái niệm → chọn công cụ → embedding/index → dựng pgvector → filter → hybrid → vận hành. Giờ bạn đủ nền để cho agent một bộ nhớ thật sự đáng tin.