Tự host embedding cho RAG nội bộ với Text Embeddings Inference
Playbook triển khai Text Embeddings Inference (TEI) trong mạng nội bộ để tạo embedding cho tìm kiếm tài liệu và RAG: chọn model, kiểm thử truy hồi, kiểm soát quyền truy cập, giám sát và chuẩn bị cho môi trường air-gapped.
Một hệ thống RAG nội bộ thường không thất bại ở giao diện chat. Nó thất bại sớm hơn: kỹ sư tìm “quy trình thay GPU” nhưng hệ thống lại trả về tài liệu mua sắm chung chung.
Điểm quyết định ở đây là embedding — cách biến văn bản thành vector để so độ gần nghĩa giữa câu hỏi và các đoạn tài liệu. Nếu lớp embedding chọn sai ngữ cảnh, LLM phía sau có giỏi đến đâu cũng khó trả lời đáng tin cậy.
Với tổ chức cần giữ tài liệu trong mạng công ty, Text Embeddings Inference (TEI) của Hugging Face là một công cụ đáng cân nhắc để tự triển khai dịch vụ tạo embedding. Bài viết này tập trung vào phần việc hằng ngày của đội hạ tầng: chọn model, dựng luồng dữ liệu, kiểm thử truy hồi và vận hành an toàn.
TEI nằm ở đâu trong kiến trúc RAG?
Theo README, TEI là toolkit để triển khai và phục vụ các model embedding mã nguồn mở, đồng thời hỗ trợ model sequence classification và re-ranking.
Trong một kiến trúc RAG thông thường, TEI có thể đóng vai trò microservice tạo vector:
Pipeline nạp tài liệu lấy nội dung từ các kho nội bộ.
Bộ cắt đoạn chia tài liệu thành các phần có thể truy hồi.
Pipeline index gửi các đoạn văn bản đến TEI để tạo embedding.
Vector cùng metadata được ghi vào hệ thống lưu trữ hoặc cơ sở dữ liệu vector do đội bạn lựa chọn.
Khi người dùng đặt câu hỏi, ứng dụng gửi câu hỏi đến TEI để tạo embedding rồi tìm các đoạn gần nghĩa.
TEI không thay thế cơ sở dữ liệu vector, lớp phân quyền tài liệu hay LLM dùng để tạo câu trả lời cuối cùng.
README nêu một số khả năng đáng chú ý cho vận hành:
Dynamic batching theo token.
Tối ưu suy luận với Flash Attention, Candle và cuBLASLt.
Nạp trọng số Safetensors và ONNX.
Prometheus metrics và distributed tracing qua OpenTelemetry.
Hỗ trợ Metal khi chạy cục bộ trên máy Mac.
Có các mục hướng dẫn về Docker, model private hoặc gated, triển khai air-gapped, ARM64/aarch64 và AMD Instinct GPUs qua ROCm.
Chọn model trước khi cấp GPU
README liệt kê nhiều kiến trúc embedding được hỗ trợ, gồm Nomic, BERT, CamemBERT, XLM-RoBERTa, JinaBERT, Mistral, Alibaba GTE, Qwen2, MPNet, ModernBERT, Qwen3 và Gemma3.
Một ví dụ trong danh sách là intfloat/multilingual-e5-large-instruct, model XLM-RoBERTa kích thước 560M. Với kho tài liệu có tiếng Việt, tiếng Anh và thuật ngữ kỹ thuật lẫn nhau, đây là ứng viên nên đưa vào bài kiểm thử thực tế.
Tuy nhiên, không nên chọn model chỉ theo thứ hạng. README có dẫn danh sách MTEB, nhưng không cung cấp đánh giá riêng cho tài liệu vận hành doanh nghiệp, wiki nội bộ hay tiếng Việt trong tổ chức của bạn.
Cũng không nên suy kích thước hạ tầng chỉ từ số lượng tham số. Danh sách model trải từ 109M đến các model Qwen cỡ hơn 7B; một số được ghi là “Very Expensive”. Nhưng phần tài liệu được cung cấp không nêu bảng quy đổi từ model sang VRAM, RAM hay throughput.
README có nhắc benchmark BAAI/bge-base-en-v1.5 trên NVIDIA A10 với độ dài chuỗi 512 token. Hãy xem đây là điểm tham khảo, không phải cam kết SLO cho hệ thống của bạn.
Nguyên tắc thực tế: bắt đầu bằng một model phù hợp với ngôn ngữ và loại tài liệu cần tìm, sau đó đo trên GPU, tập tài liệu và truy vấn thật của công ty.
Playbook triển khai trong mạng nội bộ
1. Vẽ luồng dữ liệu trước khi cài
Trước khi dựng container, hãy chốt luồng tối thiểu:
Bộ nạp tài liệu lấy file từ kho nội bộ.
Bộ xử lý tách nội dung thành các đoạn văn bản.
Pipeline index gọi TEI để tạo embedding.
Vector và metadata được lưu vào hệ thống truy hồi.
Ứng dụng tìm kiếm tạo embedding cho câu hỏi, truy vấn các đoạn liên quan và gửi ngữ cảnh phù hợp đến LLM.
Điểm dễ bị bỏ qua là quyền truy cập. Đây không phải tính năng mà TEI tự quản lý trong mô tả README; đội triển khai cần thiết kế nó ở pipeline và tầng truy vấn.
Khuyến nghị là gắn metadata quyền truy cập với từng đoạn đã index, thay vì chỉ dựa vào quyền của file gốc. Trước khi hiển thị kết quả hoặc đưa ngữ cảnh cho LLM, hệ thống truy hồi cần chỉ chọn các đoạn mà người dùng được phép xem.
2. Chọn vị trí chạy và chuẩn bị artifact
README có các mục hướng dẫn cho Docker, cài đặt cục bộ, Apple Silicon, ARM64/aarch64 và AMD Instinct GPUs qua ROCm. Điều này hữu ích nếu hạ tầng của bạn có nhiều loại máy hoặc cần chạy thử ngoài cụm GPU chính.
Với môi trường cô lập Internet, hãy chuẩn bị sớm cho triển khai air-gapped:
Đưa image container vào registry nội bộ.
Chuẩn bị model và các artifact cần thiết trong kho nội bộ.
Xác nhận máy chủ production không cần tải thêm thành phần từ Internet khi khởi động.
Kiểm thử quy trình import artifact trước khi chặn egress.
Tài liệu có các mục về Docker và air-gapped deployment, nhưng phần trích dẫn không nêu sẵn cấu hình máy, cổng dịch vụ, biến môi trường hay manifest Kubernetes. Vì vậy, hãy đối chiếu với tài liệu của đúng phiên bản TEI trước khi đưa vào production; không nên suy đoán endpoint hoặc sao chép cấu hình không rõ nguồn gốc.
3. Lập bộ test truy hồi trước khi mở rộng
Đừng kiểm thử bằng câu “xin chào”. Hãy tạo tập câu hỏi từ ticket đã đóng, runbook, FAQ hoặc wiki không nhạy cảm — nơi đội vận hành đã biết câu trả lời hoặc tài liệu nguồn mong đợi.
Mỗi mẫu test nên ghi rõ:
text
Câu hỏi người dùng: <câu hỏi thật>
Tài liệu hoặc đoạn mong đợi: <tên tài liệu/đoạn>
Ngôn ngữ: <vi/en/hỗn hợp>
Nhóm được phép xem: <nhóm ACL>
Từ viết tắt hoặc hostname cần giữ nguyên: <danh sách>
Ví dụ truy vấn:
text
Quy trình khôi phục máy ảo sau khi datastore gặp sự cố là gì?
Một kết quả tốt không chỉ là câu trả lời nghe hợp lý. Hệ thống cần truy hồi đúng runbook hoặc đoạn hướng dẫn liên quan, kèm nguồn để kỹ sư kiểm tra, và không để lộ nội dung ngoài phạm vi quyền truy cập.
README có dẫn tài liệu API dạng Swagger. Khi tích hợp, hãy lấy schema, endpoint và payload từ Swagger hoặc tài liệu của chính phiên bản TEI đang chạy thay vì tự đoán định dạng yêu cầu.
Đánh giá embedding theo góc nhìn vận hành
Embedding không trực tiếp quyết định câu trả lời cuối cùng. Nó ảnh hưởng đến việc những đoạn nào được đưa vào bước tiếp theo của RAG.
Hãy đánh giá ít nhất ba lớp:
Relevance: Các kết quả đầu có thực sự liên quan đến câu hỏi không?
Permission: Người thử có được phép xem từng đoạn được trả về không?
Stability: Với cùng model, cùng index và cùng truy vấn, chất lượng có ổn định khi tải tăng không?
Mẫu ghi nhận đơn giản:
text
Truy vấn: <câu hỏi>
Kết quả mong đợi: <tài liệu/đoạn>
Kết quả thực tế: <tài liệu/đoạn>
Đúng quyền truy cập: <có/không>
Cần xử lý: <chunking/metadata/đánh giá model>
Nếu kết quả sai vì tiêu đề, bảng biểu hoặc lệnh shell bị cắt rời khỏi ngữ cảnh, đổi model có thể chưa giải quyết được vấn đề. Hãy kiểm tra parser và cách chia đoạn trước: embedding chỉ xử lý phần văn bản mà pipeline gửi vào.
Vận hành: mạng, giám sát và thay đổi model
Giới hạn bề mặt truy cập
Đặt TEI trong mạng nội bộ và chỉ cho các dịch vụ cần thiết gọi tới, chẳng hạn pipeline index và ứng dụng RAG.
Phần README được cung cấp không mô tả cơ chế xác thực hoặc phân quyền ở lớp API. Vì vậy, nếu kiến trúc yêu cầu kiểm soát truy cập, đội vận hành nên triển khai tại tầng phù hợp của mình, như reverse proxy, gateway, service mesh hoặc chính sách mạng.
Theo dõi tải và lỗi
TEI có Prometheus metrics và distributed tracing qua OpenTelemetry. Đây là nền tảng để đưa dịch vụ vào hệ thống quan sát tập trung.
Các tín hiệu nên theo dõi gồm:
Độ trễ request khi tải tăng.
Lỗi tải model hoặc lỗi suy luận.
Mức sử dụng GPU và bộ nhớ của node.
Lưu lượng từ pipeline index so với lưu lượng tìm kiếm trực tuyến.
Request bị chặn tại gateway hoặc chính sách mạng.
Coi đổi model là một thay đổi dữ liệu
Khi thay model hoặc thay đổi cách cắt đoạn, hãy lập kế hoạch đánh giá và index lại. Vector tạo bởi model mới không nên mặc định được coi là có thể dùng chung với index cũ.
Một quy trình thận trọng là:
Dựng model hoặc index mới song song.
Chạy lại bộ test truy hồi và kiểm tra quyền truy cập.
So sánh kết quả trước và sau thay đổi.
Chuyển traffic khi chất lượng đáp ứng yêu cầu.
Chỉ dọn index cũ sau khi đã xác nhận khả năng khôi phục và truy hồi.
Checklist trước khi mở rộng
[ ] Model được kiểm thử trên truy vấn tiếng Việt, tiếng Anh và thuật ngữ nội bộ.
[ ] Tải được đo trên GPU và tài liệu thật của tổ chức.
[ ] TEI chỉ mở cho các service cần thiết trong mạng công ty.
[ ] Metadata quyền được áp dụng khi truy vấn kết quả.
[ ] Metrics và tracing được đưa vào hệ thống quan sát tập trung.
[ ] Có quy trình đưa image và model vào môi trường air-gapped.
[ ] Có kế hoạch đánh giá và re-index khi đổi model hoặc đổi chunking.
TEI phù hợp khi bạn muốn tự vận hành lớp embedding trong hạ tầng của mình và cần các khả năng như Docker, batching theo token, metrics và tracing. Nhưng giá trị của một hệ thống RAG nội bộ không nằm ở việc chạy được container: nó nằm ở kiểm soát đường đi dữ liệu, quyền truy cập, chất lượng truy hồi và quy trình thay đổi có thể kiểm chứng.