BÀI VIẾT
7. Vận hành chatbot riêng tư trên production
Thiết kế cô lập tenant, tool giới hạn, kiểm soát phát hành, khôi phục lỗi và observability cho chatbot.

Trong bài viết
Kỹ thuật Chatbot · Bài 7 trong 9 bài · Nguồn được đối chiếu ngày 7 tháng 10 năm 2026. Thiết kế và giả định đề xuất được phân biệt với kết quả triển khai đã đo.

Chatbot production là ứng dụng chứa một thành phần có tính bất định. Model đưa đề xuất; dịch vụ bao quanh cung cấp danh tính, phân quyền, thực thi giới hạn, trạng thái lưu bền và khôi phục. Self-host thay đổi người vận hành dịch vụ, không làm các kiểm soát đó hết cần thiết.
Chọn chế độ triển khai theo loại dữ liệu
Private-local giữ inference và tool nhạy cảm trong ranh giới được duyệt. Hybrid xử lý dữ liệu riêng tại local và dùng dịch vụ bên ngoài được phép cho request đủ điều kiện. Hosted đơn giản hóa vận hành inference nhưng cần quyết định rõ về xử lý dữ liệu và chi phí.
Hiển thị chế độ hiện hành cho quản trị viên và thực thi ở server. Khi xử lý bên ngoài bị tắt, model local lỗi không được âm thầm fallback sang endpoint hosted. Thay vào đó, giải thích capability không khả dụng. Demo self-host công khai đi qua Cloudflare cũng không phải hệ thống cô lập khỏi mạng bên ngoài.
Giữ quyền quyết định ngoài đầu ra model
Lấy danh tính người dùng và tenant từ session đã xác thực. Lấy credential connector từ vault phía server. Cấp capability hẹp như “đọc doanh thu tháng đã duyệt”, thay vì shell chung hoặc credential database tổng quát. JSON của model không thể mở rộng capability.
Với thao tác ghi, hiển thị đúng đối tượng và thay đổi dự kiến trước khi duyệt. Gắn approval với mã request, người dùng, tenant, tham số hành động và hạn sử dụng. Tham số đổi thì cần approval mới. Dùng idempotency key để retry ngoài ý muốn không tạo tác động trùng.
Cô lập dữ liệu ở mọi lớp
Dòng database, index tài liệu, nơi lưu hội thoại, export và cache đều cần ranh giới tenant. Chính sách database đúng không bảo vệ được vector index trả tài liệu khách hàng khác. Test quyền trước khi bất kỳ bằng chứng nào đến model.
Mặc định tránh log prompt và kết quả tool nguyên văn. Ghi mã request, loại tác vụ, latency, số token, trạng thái và lỗi đã loại thông tin nhạy cảm. Nếu điều tra hỗ trợ cần nội dung, việc thu thập phải có kiểm soát, giới hạn và thông báo, kèm quy trình lưu giữ và xóa.
Giới hạn dịch vụ
Áp dụng giới hạn input, output, thời gian tool, số vòng tool tối đa, độ dài hàng đợi và ngân sách theo tenant. Giới hạn concurrency theo peak memory thực tế và thời gian chờ chấp nhận được. Request timeout cần bao phủ toàn thao tác, không chỉ model call.
Dịch vụ chỉ báo ready khi artifact model và dependency cần thiết đã sẵn sàng. Tách liveness khỏi readiness. Khi quá tải, từ chối công việc trước khi hết bộ nhớ và giải thích cách khôi phục. Dùng circuit breaker cho connector lỗi thay vì retry trong mọi hội thoại.
Triển khai artifact có thể tái lập
Lưu revision model gốc, hash adapter, tokenizer, dependency lock, revision prompt và phiên bản danh mục chỉ số trong release manifest. Kiểm tra hash trước khi nạp. Chạy process bằng user không phải root, code và model chỉ đọc, cấp bộ nhớ giới hạn và hạn chế mạng.
LXC có thể host router CPU, API và UI như demo hiện tại. GPU serving có thể cần host riêng cấu hình phù hợp. Với sản phẩm chạy trên một host, mô tả trung thực sự cố và khôi phục backup; container hóa không tự cung cấp high availability.
Theo dõi sức khỏe sản phẩm và model
Theo dõi tác vụ thành công, tỷ lệ yêu cầu chưa hỗ trợ, câu làm rõ hữu ích, phản hồi khách hàng và export lỗi bên cạnh metric dịch vụ. Với serving sinh nội dung, theo dõi chờ hàng đợi, time to first token, latency sinh, request đang chạy và áp lực bộ nhớ. vLLM cung cấp metric production cho lớp serving. Tài liệu metric production của vLLM.
Gắn label bằng nhóm hữu hạn thay vì text người dùng hoặc định danh có cardinality cao. Cảnh báo khi dịch vụ suy giảm kéo dài và tác vụ bị regression. Biểu đồ latency trung bình có thể trông tốt trong khi một nhóm khách hàng liên tục timeout.
Test lỗi và rollback
Trước rollout, thử database ngừng hoạt động, index cũ, plan sai định dạng, model crash, request bị hủy, approval hết hạn và ngân sách cạn. Xác minh UI báo thất bại hoặc hoàn tất một phần, không ngụ ý yêu cầu đã hoàn thành. Kiểm tra retry không phát lại hành động đặc quyền.
Phát hành qua offline evaluation, shadow khi được phép và canary. Giữ artifact ứng dụng và model trước đó. Ghi khả năng tương thích rollback cho schema hội thoại và định nghĩa chỉ số; rollback model riêng chưa chắc đảo ngược được migration ứng dụng không tương thích.
Phần nào đã sẵn sàng ở đây?
Demo routing công khai hiện tại có input, queue và quota giới hạn, dịch vụ CPU cô lập và không có action tool thật. Các kiểm soát này phù hợp phạm vi minh họa. Nó vẫn là thử nghiệm classifier nhỏ với dữ liệu đánh giá giả lập, chưa phải sản phẩm analytics cho client đã xác nhận chất lượng.
Release có tính phí còn cần workspace xác thực, quyền connector thật, bằng chứng chất lượng độc lập, diễn tập khôi phục, điều khoản thương mại và chính sách hỗ trợ thống nhất. Dùng bài này như checklist cần triển khai và kiểm chứng, không coi là tuyên bố các capability đã tồn tại.
Thực hành: state machine request trước triển khai
Request Commerce Assist cần trạng thái rõ: received, authorized, planned, validated, executing, completed, failed, canceled. Đề xuất ghi thêm awaiting_approval và approved trước thực thi. Lưu request ID, phiên bản policy trong chuyển trạng thái. “Model nói xong” không phải completed hợp lệ; hoàn tất cần kết quả tool xác nhận và gửi được đầu ra cho phép.
Hủy có hai khía cạnh: người dùng không cần câu trả lời nữa và backend thực sự ngừng dùng tài nguyên. Ghi cả hai. Nếu backend không ngắt query an toàn được, không gửi kết quả sau hủy nhưng vẫn tính tài nguyên đến khi kết thúc. Với hành động ghi tương lai, hủy không được coi là rollback nếu tool chưa xác nhận.
Ánh xạ ranh giới thành thành phần
| Thành phần | Trách nhiệm | Secret/dữ liệu được thấy |
|---|---|---|
| Gateway | Session, phạm vi tenant, nhận theo ngân sách | Danh tính xác thực; không đưa password database rộng vào prompt |
| Planner | Đề xuất công việc có cấu trúc hỗ trợ | Catalog, ngữ cảnh được phép |
| Tool executor | Validate, chạy thao tác cố định | Credential connector đúng phạm vi |
| Renderer | Giải thích kết quả xác thực | Envelope kết quả cho phép |
| Usage ledger | Đo công việc nhận/hoàn tất | Request ID, nhóm tác vụ, usage; không cần hội thoại thô |
Đây là ranh giới logic, không bắt buộc năm microservice. Một process có thể thực thi bằng interface riêng và credential giới hạn. Chỉ tách deployment khi cô lập hoặc scaling cần. Dịch vụ phân tán thêm timeout, xác thực giữa thành phần và kiểu lỗi.
Viết runbook sự cố có quyết định cụ thể
Giả sử model service ngừng trả lời. Gateway từ chối generation mới, giữ text đã gửi và đánh dấu request hiện tại không khả dụng; điều hướng xác định hoặc metric template hợp lệ có thể vẫn chạy. Không đổi sang provider ngoài trong workspace private-only. Operator kiểm tra readiness, memory pressure, hash artifact trước restart, rồi dùng fixture đã biết xác nhận khôi phục.
Nếu nghi lộ tenant, dừng connector và nhánh cache liên quan trước. Giữ mã request đã loại dữ liệu nhạy cảm, phiên bản release, thu hồi cache nghi vấn và điều tra ranh giới quyền. Không giữ dịch vụ mở vì điểm trung bình model tốt. Thống nhất trách nhiệm thông báo, điều tra với client trước sự cố.
Envelope observability tối thiểu
{
"request_id": "opaque-id",
"workspace_bucket": "bounded-internal-category",
"task_class": "metric_compare",
"release": "application+model+prompt-manifest",
"queue_ms": 120,
"tool_ms": 80,
"input_tokens": 1200,
"output_tokens": 180,
"outcome": "completed",
"external_processing": false
}
Giá trị minh họa schema, chưa phải trace thu thập. Giữ định danh riêng trong audit storage có kiểm soát; monitoring label hữu hạn. Thêm nhóm lỗi và số retry khi thất bại. Usage ledger cần cập nhật bền, idempotent để retry event billing không tính phí trùng.
Diễn tập khôi phục trước khi hứa SLO
Xác định nội dung backup: cấu hình, tham chiếu connector, danh mục chỉ số, nơi lưu hội thoại được duyệt nếu bật, release manifest. Có thể khôi phục trọng số từ artifact store xác thực; không mặc định luôn tải được từ public. Giữ secret trong hệ thống secret được duyệt, mô tả phục hồi riêng.
Đặt mục tiêu recovery point, recovery time như cam kết dịch vụ đề xuất rồi đo restore drill. Backup job thành công chưa chứng minh restore hoạt động. Dựng instance mới, khôi phục catalog/policy, chạy fixture cô lập tenant rồi xác nhận luồng trả lời được phép.
Ngưỡng release và bàn giao
Bàn giao runbook, báo cáo công suất, rollback, owner hỗ trợ, giới hạn đã biết. Pilot chỉ đọc một host có thể có giá trị thương mại nếu mô tả trung thực availability, lịch bảo trì. Không quảng bá high availability chỉ vì LXC tự restart.
Bài tập chấp nhận là cố tình ngắt request rồi khôi phục mà không lặp công việc, không xử lý ngoài trái phép, không báo thành công sai. Bài tập test dịch vụ quanh model, nơi nhiều lỗi thực tế xảy ra.
Từ bài viết đến thử nghiệm chạy được
Benchmark và training là thử nghiệm trên dữ liệu giả lập do tác giả xây dựng, có các template tương quan. Không chứng minh tương đương model lớn hoặc chất lượng trên dữ liệu khách hàng. Model sinh plan được đo offline; demo công khai dùng baseline có kiểm soát. Benchmark: đã hoàn thành bốn candidate. LoRA: completed, 64/64 bước.
Lộ trình và kết quả thực nghiệm · Thử demo với dữ liệu giả lập · Tải code minh họa
Bài học từ triển khai này
Demo public chạy baseline trên LXC với quota dùng chung, giới hạn body và hàng đợi. Hủy request không giải phóng worker trước khi tác vụ nền kết thúc. Đây là kiểm soát tài nguyên thực; xác thực khách hàng, RBAC và audit nghiệp vụ vẫn cần triển khai riêng khi sản xuất.


Thảo luận
Bình luận được duyệt trước khi công khai. Email của bạn được giữ riêng tư.