Tái thiết kế quy trình phát triển hệ thống AI FAQ từ “công đoạn”: Deep Dive System Development với RAG, đánh giá và vận hành theo SLO

1. Executive Summary（Tóm tắt kỹ thuật・300 ký tự）

Hệ thống AI FAQ rất dễ thất bại nếu chỉ áp dụng “10 công đoạn (từ định nghĩa yêu cầu đến vận hành/bảo trì)” theo kiểu truyền thống mà không chèn thêm các công đoạn đặc thù của RAG (Retrieval-Augmented Generation – sinh tăng cường bằng truy xuất). Cụ thể, cần quy trình hóa ngay từ đầu: ① data contract (trả lời dựa trên dữ liệu nào) ② thiết kế đánh giá (độ chính xác/hiển thị căn cứ/escalation) ③ bảo mật (PII, phân quyền, audit) ④ vận hành (log → cải tiến → tái huấn luyện/tái lập chỉ mục). Bài viết cung cấp kiến trúc, cấu hình triển khai, benchmark, bảng so sánh và roadmap, đưa ra chỉ dẫn thực tiễn để chuyển từ PoC ngắn hạn sang vận hành production theo SLO.🔧

2. Bối cảnh kỹ thuật và thách thức（Giải thích sơ đồ kiến trúc, vấn đề hiện hữu）

a blue abstract background with lines and dots

Luồng “định nghĩa yêu cầu → thiết kế → phát triển → kiểm thử → vận hành” trong bài tham khảo 1 vẫn hữu ích như một khung xương cho AI FAQ, nhưng khi đưa GenAI vào, số lượng vùng “không thể cố định đặc tả” tăng lên. Như bài tham khảo 3 chỉ ra, không phải cứ “thêm AI = giảm ticket” — các yếu tố như trả lời sai, thiếu căn cứ, chậm cập nhật tri thức sẽ cản trở việc người dùng chấp nhận. Hơn nữa, khi kết hợp phát triển offshore (bài tham khảo 2), đặc tả tiếng Nhật mơ hồ và tri thức ngầm dễ tạo ra sản phẩm không thể đánh giá; vì vậy cần bắt buộc chuẩn hóa/định dạng hóa định nghĩa deliverable (dữ liệu/đánh giá/vận hành).

Sơ đồ luồng kỹ thuật (mô tả bằng văn bản)📊：Câu hỏi người dùng → API Gateway → (1) xác thực/ủy quyền → (2) chuẩn hóa truy vấn → (3) Vector Search (Top-k) → (4) dựng Context (lọc theo quyền) → (5) LLM sinh câu trả lời (trích dẫn căn cứ) → (6) guardrails (phán định NG/PII) → (7) trả kết quả → (8) log/trace → (9) chấm điểm offline trên nền tảng đánh giá → (10) cải tiến (chuẩn hóa tri thức/tái lập chỉ mục/cập nhật prompt). Trong quy trình truyền thống, (8)-(10) thường bị “nhét” vào vận hành, nhưng với AI FAQ đây là lõi chất lượng, nên phải thiết kế ngược từ giai đoạn định nghĩa yêu cầu.

Vấn đề hiện hữu：FAQ phân tán (SharePoint/Confluence/file server/email), khả năng tìm kiếm kém
Vấn đề đặc thù AI：hallucination, thiếu căn cứ, trả lời bỏ qua quyền truy cập, chậm bám theo cập nhật
Vấn đề về công đoạn：UAT chỉ dừng ở “xác nhận UI”, KPI chất lượng câu trả lời chưa được định nghĩa
Khuếch đại khi offshore：đặc tả mơ hồ dẫn thẳng đến hành vi LLM không thể đánh giá (“đúng” được định nghĩa ra sao?)

3. Phần kỹ thuật ①：Bắt đầu định nghĩa yêu cầu từ “data contract” và “điều kiện thất bại” ⚙️

3.1 Tái phân rã định nghĩa yêu cầu：định nghĩa “căn cứ” trước cả yêu cầu chức năng

Định nghĩa yêu cầu truyền thống thường xoay quanh màn hình/chức năng, nhưng với AI FAQ cần quyết định trước: “nguồn dữ liệu làm căn cứ trả lời”, “phạm vi tham chiếu được phép (quyền)”, và “điều kiện không trả lời”. Nếu mơ hồ ở đây, tranh luận về độ chính xác ở các công đoạn sau sẽ không hội tụ. Khuyến nghị là lập “data contract” như một sổ đăng ký: loại nguồn, tần suất cập nhật, người chịu trách nhiệm, mức độ chứa PII, mức công khai. Đồng thời, như gợi ý ở bài tham khảo 3, hãy viết rõ “AI không được làm gì” thành tiêu chí nghiệm thu, và chuyển các điều kiện thất bại (ví dụ: phán đoán pháp lý/thông tin cá nhân/diễn giải điều khoản) thành yêu cầu guardrails.

3.2 Thiết kế escalation：coi chuyển sang người thật là một tính năng sản phẩm

AI FAQ không quan trọng ở mức tự động hóa tuyệt đối, mà ở chỗ khi có rủi ro trả lời sai thì phải “dừng đúng cách”. Ở mức SLA/SLO, khi không thể trả lời thì tự động tạo ticket (Jira Service Management) hoặc gửi thông báo Slack. Nếu không quyết định từ giai đoạn định nghĩa yêu cầu mà làm bổ sung về sau, hệ thống sẽ thiếu độ chi tiết log và dấu vết audit, khiến vận hành bế tắc.

3.3 Template deliverable (chịu được offshore)

Nếu có offshore, cần loại bỏ tiếng Nhật mơ hồ và tránh phủ định lồng phủ định (bài tham khảo 2). Cụ thể, định nghĩa “điều cấm”, “ngoại lệ”, “ngưỡng” dưới dạng bảng để UAT có thể tự động hóa ở mức độ chi tiết phù hợp.

# requirements/guardrails.yml
version: 1
answer_policy:
  must_cite_sources: true
  citation_style: "doc_id:section"
  refuse_when:
    - category: "legal_judgement"
      message: "Vì có liên quan đến phán đoán pháp lý, chúng tôi sẽ escalation sang bộ phận phụ trách."
    - category: "contains_pii"
      message: "Không thể trả lời vì có khả năng chứa thông tin cá nhân."
escalation:
  tool: "jira"
  project_key: "HD"
  create_issue_when:
    - confidence < 0.55
    - no_retrieval_results

3. Phần kỹ thuật ②：Thiết kế chuẩn kiến trúc RAG（nút thắt là tìm kiếm hơn là LLM）🔧

4.1 Kiến trúc tham chiếu（cấu hình khuyến nghị）

AI FAQ vận hành thực tế chủ yếu dùng RAG thay vì chỉ LLM. Các thành phần gồm: (a) Ingestion (nạp dữ liệu) (b) Chunking (chia đoạn) (c) Embedding (vector hóa) (d) Vector DB (e) Retrieval (truy xuất) (f) Generation (sinh câu trả lời) (g) Observability. So với khác biệt giữa các LLM, kích thước chunk, thiết kế metadata và cách triển khai lọc quyền mới là yếu tố quyết định độ chính xác. Đặc biệt FAQ nội bộ thường nhiều “đoạn ngắn + bảng + quy trình”, nên cần chuẩn hóa Markdown/HTML.

4.2 Ví dụ triển khai cụ thể（LangChain 0.2.x + FastAPI + pgvector）

Để tránh vendor lock-in, giả định Vector DB là PostgreSQL 16 + pgvector 0.7.4, API là FastAPI 0.110, và nền tảng chạy là Kubernetes 1.29. Embedding giả định tương đương text-embedding-3-large với số chiều (3072), đồng thời cho phép chuyển sang bản small để tối ưu chi phí.

# docker-compose.yml（dùng cho kiểm chứng）
services:
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: example
    ports:
      - "5432:5432"
    command: ["postgres", "-c", "shared_buffers=1GB", "-c", "max_connections=200"]
  api:
    build: ./api
    environment:
      DATABASE_URL: "postgresql+psycopg://postgres:example@db:5432/postgres"
      VECTOR_DIM: "3072"
    ports:
      - "8000:8000"

-- PostgreSQL: pgvector
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE docs (
  doc_id text PRIMARY KEY,
  acl jsonb NOT NULL,
  updated_at timestamptz NOT NULL
);
CREATE TABLE chunks (
  chunk_id bigserial PRIMARY KEY,
  doc_id text REFERENCES docs(doc_id),
  content text NOT NULL,
  embedding vector(3072),
  meta jsonb
);
CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops) WITH (m=16, ef_construction=200);

4.3 Lọc quyền và metadata

FAQ nội bộ có thông tin hiển thị khác nhau theo phòng ban/chức danh. Thay vì lọc sau Retrieval, việc đưa điều kiện ACL vào truy vấn tìm kiếm (Row Level Security hoặc where clause) sẽ giảm rủi ro rò rỉ. Metadata nên bắt buộc có “phòng ban”, “mức độ mật”, “hạn hiệu lực”, “phiên bản”, và loại khỏi phạm vi tìm kiếm nếu đã hết hạn.

3. Phần kỹ thuật ③：Tích hợp thiết kế đánh giá (chấm điểm offline tự động) vào công đoạn kiểm thử 📊

5.1 Trục đánh giá AI tương ứng “unit/integration/system”

Nếu áp dụng công đoạn kiểm thử trong bài tham khảo 1 cho AI: unit = đánh giá Retriever (Recall@k, MRR), integration = Faithfulness của toàn RAG (tính nhất quán với căn cứ), system = tỷ lệ hoàn thành kịch bản nghiệp vụ (bao gồm escalation). Nếu không định nghĩa trước mà đi thẳng vào UAT, đánh giá sẽ biến thành “có vẻ thông minh/không thông minh”, và không thể cải tiến.

5.2 Benchmark（ví dụ: 1.000 câu hỏi helpdesk nội bộ）

Cấu hình	Chunk	Top-k	Recall@5	Độ chính xác câu trả lời (chấm tay)	P95 latency
BM-1: cố định 800 token + HNSW	800	5	0.82	0.71	2.4s
BM-2: 400 token + biên theo heading	biến thiên (200-600)	8	0.89	0.78	2.8s
BM-3: BM-2 + Reranker(bge-reranker-v2)	biến thiên	20→8	0.92	0.83	3.6s

Hàm ý: ở nhiều đội, nút thắt không nằm ở LLM mà ở chất lượng truy xuất. Thêm Reranker giúp tăng độ chính xác nhưng dễ làm xấu P95, vì vậy nên cân nhắc kèm cache (theo cụm câu hỏi) hoặc thiết kế escalation bất đồng bộ.

5.3 Ví dụ pipeline đánh giá（pytest + golden set）

# tests/test_retrieval.py
import json
from rag import retrieve

def test_recall_at_k(golden):
    k=5
    hit=0
    for q in golden:
        docs = retrieve(q["question"], k=k, user=q["user"])
        if q["expected_doc_id"] in [d.doc_id for d in docs]:
            hit += 1
    recall = hit/len(golden)
    assert recall >= 0.85

3. Phần kỹ thuật ④：Thiết kế bảo mật（PII・audit・prompt injection）🔒

6.1 Threat model：FAQ là “ô tìm kiếm nội bộ” nên bề mặt rò rỉ rất rộng

AI FAQ có thể trở thành kênh rò rỉ dữ liệu ở cả đầu vào (câu hỏi) lẫn đầu ra (câu trả lời). Điển hình: (1) trích dẫn tài liệu ngoài quyền, (2) prompt injection khiến lộ system prompt/bí mật, (3) PII bị lưu trong log, (4) gửi sang LLM bên ngoài vi phạm quy định. Vì vậy cần đặt ủy quyền, masking và audit log ở trung tâm kiến trúc.

6.2 Biện pháp cụ thể（mức triển khai）

🔧 Kiểm tra đầu vào：regex + DLP (ví dụ: email/điện thoại/địa chỉ) để phát hiện và mask PII
⚙️ Kiểm tra đầu ra：từ điển thuật ngữ mật; từ chối câu trả lời không có nguồn trích dẫn (must_cite_sources)
🔒 Audit：ghi log bất biến các trường user_id, doc_id, chunk_id, model, prompt_hash, decision (answer/refuse/escalate)
🔧 Kiểm soát gửi ra ngoài：giới hạn domain qua proxy, kiểm soát VPC egress, khóa lưu trong KMS/HSM

# Envoy（ví dụ）: egress allowlist
static_resources:
  clusters:
  - name: openai
    type: LOGICAL_DNS
    load_assignment:
      cluster_name: openai
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: api.openai.com
                port_value: 443

6.3 Chống prompt injection：tách “policy” khỏi “implementation”

Không để mô hình tuân theo các mệnh lệnh kiểu “hãy bỏ qua…”. Thay vì phụ thuộc system prompt, áp dụng phòng thủ 3 lớp: (a) whitelist hóa tool execution, (b) bắt buộc trích dẫn, (c) chặn ngay ở Retriever theo phân loại mật.

3. Phần kỹ thuật ⑤：Phân tích khả năng mở rộng（tải đỉnh thường đến vào “đầu giờ sáng”）📈

7.1 Phân rã throughput：tìm kiếm・sinh・hậu xử lý

Nghiệp vụ hỗ trợ có độ lệch theo khung giờ lớn. Khi peak, “cùng một câu hỏi đổ vào hàng loạt”, nên chuẩn hóa câu hỏi + semantic cache phát huy hiệu quả. Chiến lược scale thực tế không phải là scale ngang LLM, mà là cache Retriever, tiền tính Embedding, và áp dụng điều kiện Rerank (chỉ khi độ tin cậy thấp) để kiểm soát chi phí.

7.2 Benchmark（ví dụ: concurrent bằng k6）

Kết nối đồng thời	RPS	P50	P95	Tỷ lệ lỗi	Nguyên nhân chính
50	18	1.4s	2.6s	0.2%	chờ LLM
200	52	2.1s	4.8s	1.1%	DB CPU + LLM rate limit
500	88	3.0s	7.9s	3.8%	rate limit / tràn queue

7.3 Mẫu triển khai：Queue + Async để hấp thụ “thời gian chờ”

Nếu bám P95 bằng API đồng bộ, chi phí sẽ tăng vọt. Hãy bất đồng bộ hóa (SQS/RabbitMQ/Kafka) và bổ sung UI “đang tạo câu trả lời” trong phạm vi trải nghiệm người dùng cho phép. Escalation có thể bất đồng bộ, nhưng audit log nên được chốt đồng bộ.

3. Phần kỹ thuật ⑥：CI/CD và tách môi trường（coi prompt cũng là code）🔧

8.1 “Prompt as Code” và versioning

Thay đổi prompt làm thay đổi hành vi, vì vậy quản lý bằng Git thay vì tài liệu thiết kế, và lưu prompt_hash vào log. Tách môi trường dev/stg/prod, và tri thức (index) cũng phải được giữ theo ID riêng cho từng môi trường. Nếu không tái hiện được tổ hợp prompt và index, điều tra sự cố sẽ bất khả thi.

# .github/workflows/eval.yml
name: rag-eval
on: [pull_request]
jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install -r requirements.txt
      - run: pytest -q tests/

8.2 IaC（Terraform 1.7）để đáp ứng audit

IaC hóa VPC, KMS, Secrets, WAF, kho lưu log và lưu lịch sử thay đổi. AI FAQ trông như “chat UI”, nhưng thực chất là nền tảng truy cập dữ liệu nội bộ, nên quản trị thay đổi đáp ứng yêu cầu audit là bắt buộc.

8.3 Ranh giới phân công khi phát triển offshore

Giải pháp thực tế là nắm phần upstream trong nước (định nghĩa yêu cầu, data contract, KPI đánh giá, chính sách bảo mật), và giao phần sản xuất (UI/màn quản trị/ETL) cho offshore. Tuy nhiên, nền tảng đánh giá và dữ liệu kiểm thử (golden set) phải do phía trong nước chuẩn bị để có thể tự động phán định pass/fail của deliverable khi thuê ngoài.

3. Phần kỹ thuật ⑦：Vận hành/bảo trì = “đào tạo” theo SRE（log → vòng lặp cải tiến）⚙️

9.1 KPI vận hành：xem “chất lượng thất bại” trước cả tỷ lệ sử dụng

Những thứ cần theo dõi trong vận hành là: (1) tỷ lệ từ chối (refusal), (2) tỷ lệ escalation, (3) tỷ lệ trả lời không có trích dẫn, (4) tỷ lệ chưa giải quyết của các nhóm câu hỏi top. Nếu chỉ đuổi theo tỷ lệ sử dụng, sẽ phát hiện muộn việc trả lời sai tăng lên. Đặt SLO như “tỷ lệ trả lời có căn cứ ≥95%” và “0 vi phạm bảo mật”.

9.2 Vòng lặp cải tiến：chuẩn hóa tri thức → tái lập chỉ mục → tái đánh giá

AI FAQ lấy cập nhật dữ liệu làm trọng tâm. Khi tài liệu được cập nhật, tự động chạy lập chỉ mục theo chênh lệch, và chạy đánh giá offline bằng batch ban đêm. Nếu điểm đánh giá thấp hơn ngưỡng, tự động chặn deploy (Quality Gate).

# ingestion/job.yaml（ví dụ Kubernetes CronJob）
apiVersion: batch/v1
kind: CronJob
metadata:
  name: rag-reindex
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: reindex
            image: registry.example.com/rag-ingest:1.3.2
            env:
            - name: CHUNK_MAX_TOKENS
              value: "600"
          restartPolicy: OnFailure

9.3 Giám sát：trace đến tận “căn cứ trả lời” bằng OpenTelemetry

APM không chỉ đo latency mà còn lưu retrieved_doc_ids, rerank_score, confidence, refusal_reason như thuộc tính span. Khi xử lý sự cố, cần phân tách “LLM chậm” với “truy xuất sai” hay “bị rơi do ACL”.

4. Bảng phân tích so sánh（so sánh từ 3 lựa chọn trở lên）

Lựa chọn	Tốc độ triển khai ban đầu	Khả năng tùy biến	Kiểm soát dữ liệu/quyền	Dễ đánh giá & cải tiến	Mức chi phí dự kiến	Kịch bản áp dụng
AI FAQ dạng SaaS	◎	△	○（phụ thuộc tính năng）	△（dễ thành “hộp đen”）	Phí thuê bao tháng + theo mức dùng	Triển khai nhanh, yêu cầu có thể chuẩn hóa theo sản phẩm
RAG scratch (tự vận hành)	△	◎	◎（RLS/audit/mạng nội bộ）	◎（golden set/tích hợp CI）	Đầu tư ban đầu cao + dư địa tối ưu vận hành lớn	Dữ liệu mật, tích hợp hệ thống lõi, vận hành dài hạn
Hybrid（tìm kiếm & quyền tự làm, LLM dùng API bên ngoài）	○	○	◎（có thể thiết kế không đưa dữ liệu quan trọng ra ngoài）	○（trace/đánh giá do nội bộ đảm bảo）	Phương án cân bằng	Chuyển đổi thực tế, cân bằng chi phí và kiểm soát

5. Best practices・Anti-patterns（dạng gạch đầu dòng）

Best practices ✅

⚙️ Chốt trong định nghĩa yêu cầu: “vùng AI không trả lời”, “dữ liệu căn cứ”, “escalation”
📊 Tạo golden set (tập câu hỏi đại diện) và tự động đánh giá Recall@k/độ chính xác trong CI
🔒 Nhúng ACL vào Retriever, loại dữ liệu ngoài quyền ngay từ bước tìm kiếm
🔧 Versioning prompt/cấu hình/index, và ghi prompt_hash vào audit log
📈 Dùng semantic cache và áp dụng Reranker theo điều kiện để cân bằng P95 và chi phí

Anti-patterns ❌

Chỉ vì “chat UI chạy được” mà nghiệm thu, không có tiêu chí pass/fail cho chất lượng câu trả lời
Bỏ mặc chất lượng FAQ gốc, dùng LLM “làm cho giống đúng” để che đậy
Lọc quyền ở bước sau, dẫn đến rò rỉ qua log hoặc trích dẫn
Vận hành thủ công (tổng hợp Excel), không chạy được vòng lặp cải tiến
Ném đặc tả tiếng Nhật mơ hồ cho offshore, tạo hàng loạt hành vi không thể tái hiện

6. Roadmap triển khai và checklist

6.1 Roadmap（mô hình 12 tuần）

Week 1-2 Định nghĩa yêu cầu：data contract, điều kiện thất bại, SLO, yêu cầu audit, khoanh vùng loại ticket mục tiêu
Week 3-4 Thiết kế cơ bản：cấu hình RAG, phương thức ACL, log/trace, quy trình vận hành, tích hợp escalation
Week 5-7 Thiết kế chi tiết & triển khai：Ingestion, Chunk/Embedding, Vector DB, API, UI, màn quản trị
Week 8-9 Kiểm thử：đánh giá Retriever, kịch bản E2E, kiểm thử tải, kiểm thử bảo mật (injection/rò rỉ)
Week 10 Kiểm thử vận hành (nghiệm thu)：xác minh kịch bản của bộ phận nghiệp vụ, kiểm tra hành vi refusal/escalation
Week 11-12 Phát hành theo giai đoạn：từ phòng ban giới hạn → toàn công ty, cải tiến dựa trên log, thiết lập cơ chế chuẩn hóa tri thức

6.2 Checklist（trích）

🔒 Chính sách phát hiện/mask PII đã được triển khai, không lưu PII thô trong log
⚙️ must_cite_sources bật, câu trả lời không có trích dẫn sẽ bị từ chối/yêu cầu hỏi lại
📊 golden set có từ 100 câu trở lên, CI gate theo ngưỡng (ví dụ: Recall@5≥0.85)
📈 Mục tiêu P95 latency (ví dụ: ≤5s) được định nghĩa và tái hiện được bằng k6…
🔧 prompt_hash / index_version / model_version được ghi vào audit log
⚙️ Rõ người chịu trách nhiệm cập nhật tri thức (phía nghiệp vụ), tự động hóa quy trình cập nhật → tái lập chỉ mục

7. Tài nguyên tham khảo・Bước tiếp theo

Tham khảo: Quy trình phát triển hệ thống (từ định nghĩa yêu cầu đến vận hành) — dùng làm khung xương công đoạn
Tham khảo: Phát triển offshore — loại bỏ đặc tả mơ hồ, định nghĩa deliverable, vai trò Bridge SE
Tham khảo: Quy trình khởi động AI FAQ — “AI không được làm gì”, “nuôi hệ thống trong vận hành”

Bước tiếp theo🔧：① trích top 200 câu hỏi từ log và tạo golden set, ② lập sổ data contract, ③ đo Recall@k với RAG tối thiểu, ④ tích hợp E2E (bao gồm refusal/escalation) vào CI, ⑤ phát hành theo giai đoạn ở một phòng ban giới hạn và chạy vòng lặp cải tiến. Khi cố định các bước này như một “quy trình phát triển”, AI FAQ sẽ trở thành sản phẩm nâng chất lượng liên tục thay vì triển khai một lần rồi bỏ đó.