Bài 7 — Vận hành thực tế: chi phí, độ trễ, đánh giá và gỡ lỗi memory

Từ chạy được tới chạy tốt trong thực tế

Một agent memory demo trên máy khác hẳn khi phục vụ hàng nghìn người dùng. Bài này tập trung vào vận hành: kiểm soát chi phí/độ trễ, đo chất lượng, và gỡ lỗi khi agent "nhớ nhầm" hay "quên".

Ba loại chi phí phải giám sát

• Token prompt: phình theo lịch sử và số chunk RAG. Đây thường là khoản đắt nhất.
• Lời gọi embedding: mỗi lần index và mỗi câu query đều tốn. Cache embedding của câu hỏi lặp lại.
• Độ trễ tổng: = embed query + vector search + gọi LLM. RAG thêm một vòng truy xuất trước khi model chạy.

Quy tắc thực dụng: mỗi token đưa vào prompt phải "trả tiền vé" bằng giá trị nó mang lại. Chunk không liên quan là token lãng phí và còn làm giảm chất lượng.

Các bước tối ưu chi phí/độ trễ

• Log số token thực tế mỗi request, tách theo: system / profile / RAG context / history.
• Tìm khoản phình nhất, tối ưu trước (thường là history hoặc top-K quá lớn).
• Giảm top-K xuống mức nhỏ nhất mà chất lượng chưa giảm.
• Bật cache cho embedding query và cho câu trả lời của các câu hỏi phổ biến.
• Dùng router để bỏ qua RAG ở các lượt không cần (đã học Bài 6).

Đánh giá chất lượng memory

Đừng đánh giá bằng cảm tính. Xây một bộ test hồi quy: tập câu hỏi + câu trả lời/nguồn đúng kỳ vọng.

Hai nhóm chỉ số:

• Retrieval: với mỗi câu hỏi, chunk đúng có nằm trong top-K không? (recall@K). Đây là kiểm tra trước generation.
• Answer: câu trả lời có đúng, có bám nguồn, có biết nói "không biết" khi thiếu không?

# Đánh giá retrieval đơn giản
hits = 0
for q, gold_id in testset:
    got = vstore.query(q, k=5)["ids"]
    if gold_id in got:
        hits += 1
print("recall@5 =", hits / len(testset))

Chạy bộ test này mỗi khi bạn đổi chunking, model embedding hay top-K — để biết thay đổi làm tốt lên hay tệ đi.

Khung gỡ lỗi: agent trả lời sai thì soi đâu

• In ra prompt cuối cùng. 80% lỗi memory lộ ra ngay: thiếu profile, chunk sai, lịch sử bị cắt nhầm.
• Tách retrieval vs generation. Chunk lấy về đúng chưa? Nếu sai → lỗi ở tầng vector. Nếu đúng mà trả lời vẫn lệch → lỗi ở prompt/generation.
• Kiểm tra vòng đời dữ liệu. Fact có được ghi không? Có bị đọc từ cache cũ không?
• Soi cập nhật/xóa. Nhớ nhầm thường do dữ liệu lỗi thời chưa được cập nhật.

Checklist sẵn sàng vận hành (production)

• [ ] Có log token và độ trễ tách theo thành phần?
• [ ] Có bộ test hồi quy cho cả retrieval lẫn answer?
• [ ] Có cache cho embedding/câu trả lời lặp?
• [ ] Có cơ chế cập nhật/xóa long-term memory khi dữ liệu đổi?
• [ ] Có xử lý lỗi khi vector store/LLM timeout (fallback, retry)?
• [ ] Dữ liệu cá nhân có được cô lập theo user (metadata filter) và có chính sách xóa?

Sai lầm thường gặp

• Không log token. Không biết tiền chảy đi đâu, không tối ưu được.
• Đánh giá bằng cảm tính. Đổi chunking thấy "hình như tốt hơn" nhưng không có số → dễ đi lùi mà không biết.
• Bỏ qua tầng retrieval khi debug. Cứ chỉnh prompt trong khi lỗi thật nằm ở chunk lấy về.
• Không dọn dữ liệu lỗi thời. Agent tự tin trả lời theo chính sách cũ.
• Quên fallback. Vector store lỗi là cả agent sập, thay vì trả lời suy giảm nhẹ nhàng.
• Bỏ quên quyền riêng tư. Không cô lập theo user → rò rỉ dữ liệu người này sang người khác.

Tổng kết

Vận hành memory tốt = giám sát chi phí theo token, đo chất lượng bằng bộ test có số, và gỡ lỗi theo trình tự (prompt → retrieval → generation → vòng đời dữ liệu). Bài cuối tổng hợp một quy trình quyết định để bạn áp dụng cho mọi dự án agent.