LLMOps 8 — Nền tảng GenAI ngân hàng end-to-end

Bảy bài trước lần lượt bóc tách từng mảnh: tổng quan LLMOps, mẫu ứng dụng, prompt & guardrail, bảo mật & injection, đánh giá & ảo giác, observability & chi phí, và quản trị & rủi ro. Mỗi bài trả lời một câu hỏi hẹp. Bài cuối này trả lời câu hỏi lớn: ghép chúng lại thành một nền tảng GenAI mà ngân hàng dám đưa ra production.

Điểm mấu chốt: một trợ lý GenAI trong ngân hàng không phải là "gọi API LLM rồi in kết quả". Nó là một hệ thống có nhiều lớp phòng thủ, có bằng chứng để giải trình với thanh tra, có kiểm soát chi phí, và có con người ở đúng chỗ. Bài này đưa ra kiến trúc tham chiếu, ánh xạ từng bài vào kiến trúc, rồi bàn quyết định build/buy, danh mục use case theo rủi ro, lộ trình, đội ngũ và checklist go-live.

Kiến trúc tham chiếu end-to-end

Hình dung một luồng request đi từ người dùng nội bộ (cán bộ tín dụng hỏi trợ lý tra cứu quy định) tới câu trả lời có trích nguồn. Nó đi qua các lớp sau, xếp thành "đường ống" ở giữa và các dịch vụ "bao quanh" cắt ngang mọi lớp.

Đường ống chính (data plane)

1. Cổng ứng dụng (API gateway). Điểm vào duy nhất. Chịu trách nhiệm xác thực người dùng (AuthN qua SSO/AD ngân hàng), gắn danh tính vào request, rate-limit chống lạm dụng, và ghi audit log mọi truy vấn. Không có backdoor gọi thẳng LLM.

2. Orchestration. "Bộ não" điều phối — chọn đúng mẫu ứng dụng cho từng yêu cầu: prompt đơn, RAG (Retrieval-Augmented Generation — sinh có tăng cường bằng truy hồi), hay agent (LLM gọi công cụ). Đây là nội dung bài 2. Với ngân hàng, RAG là mặc định cho đa số use case tra cứu; agent chỉ dùng khi thật sự cần và luôn kèm giới hạn công cụ.

3. Input guardrails. Trước khi gửi vào LLM: quét và che PII (thông tin định danh cá nhân), phát hiện prompt injection (bài 4), chặn câu hỏi ngoài phạm vi hoặc vi phạm acceptable-use (bài 3).

4. Retrieval. Truy hồi ngữ cảnh từ vector store — xem nền tảng RAG & retrieval. Điểm sống còn của ngân hàng: phân quyền tài liệu ở tầng retrieval. Chỉ trả về các chunk mà chính danh tính người hỏi được phép đọc (xem kiểm soát truy cập).

5. LLM. Sinh câu trả lời từ ngữ cảnh + câu hỏi. Có thể là mô hình mở tự host hoặc API bên thứ ba có ràng buộc hợp đồng (bàn ở phần build/buy).

6. Output guardrails. Sau khi LLM trả lời: rà soát PII rò rỉ, nội dung độc hại/không phù hợp, và quan trọng nhất — kiểm tra grounding (câu trả lời có bám vào nguồn truy hồi không, hay đang bịa) theo bài 5.

7. Trả lời có trích nguồn. Không bao giờ trả về văn bản trần. Luôn kèm citation trỏ về tài liệu/điều khoản nguồn để người dùng tự kiểm chứng — đây là cơ chế chống ảo giác rẻ và hiệu quả nhất.

Dịch vụ bao quanh (control plane)

Các dịch vụ này không nằm trên đường đi của một request cụ thể mà cắt ngang toàn bộ:

• Observability & Cost (bài 6): trace từng bước, log token/chi phí/độ trễ, dashboard và cảnh báo.
• Evaluation (bài 5): bộ test hồi quy offline chạy mỗi lần đổi prompt/model, cùng đánh giá online (chấm mẫu bằng LLM-judge và con người).
• Security (bài 4): red-team, phát hiện injection, cô lập công cụ của agent.
• Governance & Model Risk (bài 7): model inventory, phân tầng rủi ro, model/system card, quy trình duyệt.
• Identity & phân quyền tài liệu: nguồn sự thật về "ai được đọc gì", cấp cho cả cổng lẫn retrieval.

Ánh xạ series vào kiến trúc

Nếu thiếu bất kỳ mảnh nào, nền tảng có lỗ hổng: thiếu guardrail → rò rỉ/độc hại; thiếu evaluation → không biết khi nào chất lượng tụt; thiếu observability → chi phí thất thoát và không debug được; thiếu governance → không được duyệt lên production.

Build vs Buy & self-host vs API

Đây là quyết định chiến lược đầu tiên. Với ngân hàng, biến số chi phối là độ nhạy cảm dữ liệu và data residency (dữ liệu phải nằm trong lãnh thổ/hạ tầng nào).

Nguyên tắc cho ngân hàng:

• Dữ liệu nhạy cảm cao (thông tin khách hàng, chứng từ) → ưu tiên self-host mô hình mở hoặc triển khai riêng (private deployment) để dữ liệu không rời vành đai.
• Nếu dùng API, bắt buộc hợp đồng có điều khoản: không lưu dữ liệu (zero data retention), không dùng để train, cam kết data residency, và có DPA (Data Processing Agreement). Nếu không có → không dùng cho dữ liệu khách hàng.
• Build vs Buy tầng ứng dụng: không tự xây lại gateway/guardrail/observability nếu có sản phẩm chín. Build phần đặc thù ngân hàng (RAG trên tài liệu nội bộ, phân quyền, prompt nghiệp vụ); buy phần hạ tầng chung.

Cách thực dụng phổ biến: bắt đầu bằng API có hợp đồng chặt cho use case nội bộ ít nhạy cảm để học nhanh, song song chuẩn bị năng lực self-host cho use case chạm dữ liệu khách hàng.

Danh mục use case ngân hàng & mức rủi ro

Không phải use case nào cũng nên làm cùng lúc. Xếp theo giá trị/rủi ro để chọn điểm bắt đầu.

Quy tắc chung: use case đối mặt khách hàng và use case tham gia quyết định (tín dụng, tuân thủ) là rủi ro cao — không đưa lên sớm. Bắt đầu ở góc "nội bộ, người dùng có chuyên môn, có thể kiểm chứng đầu ra".

Lộ trình áp dụng

1. Chọn 1 use case nội bộ rủi ro thấp (thường là trợ lý tra cứu quy định). Mục tiêu là học, không phải gây ấn tượng.
2. PoC trên tài liệu thật, quy mô nhỏ, đo được.
3. Đánh giá nghiêm túc: bộ test hồi quy, grounding, khảo sát người dùng thử. Không có eval → không đi tiếp.
4. Pilot có kiểm soát với nhóm người dùng nhỏ, observability và human review đầy đủ.
5. Mở rộng dần sang use case rủi ro cao hơn, mỗi bước đều qua governance (bài 7).

Điểm quan trọng: năng lực nền tảng (guardrail, eval, observability, governance) xây một lần, dùng cho mọi use case về sau. Đầu tư ban đầu là vào nền tảng, không phải vào một tính năng.

Đội ngũ & vận hành

Nền tảng GenAI cần nhiều vai trò phối hợp, không phải một "prompt engineer" đơn độc:

• Platform/ML engineer: xây và vận hành orchestration, retrieval, self-host, observability.
• Data/RAG engineer: pipeline nạp tài liệu, chunking, embedding, cập nhật vector store, gắn phân quyền.
• Nghiệp vụ (SME): định nghĩa câu hỏi đúng, gán nhãn eval, duyệt câu trả lời mẫu.
• Model risk / compliance: validation độc lập, model card, duyệt go-live.
• Security: red-team, kiểm soát injection, quản lý bí mật/khoá.

Vận hành hằng ngày: theo dõi dashboard chi phí/độ trễ/chất lượng, chạy eval hồi quy khi đổi prompt/model, review mẫu hội thoại, cập nhật tài liệu nguồn, và giám sát drift (MLOps 6 — monitoring & drift) khi phân bố câu hỏi hoặc hành vi model thay đổi.

Cạm bẫy thường gặp

• Chạy theo hype: làm chatbot CSKH đối mặt khách hàng ngay từ đầu vì nó "ấn tượng" — trong khi nó là use case rủi ro cao nhất.
• Bỏ qua đánh giá/guardrail: demo chạy đẹp rồi đẩy thẳng lên, không có test hồi quy, không có che PII → sự cố chỉ là vấn đề thời gian.
• Đưa vào quyết định rủi ro cao quá sớm: dùng LLM để "quyết" điều kiện vay hay xử lý khiếu nại mà không có con người ở giữa.
• Bỏ qua chi phí: không đo token/request, để prompt phình và context dài → hoá đơn tăng vọt không kiểm soát (xem bài 6).
• Quên phân quyền tài liệu: RAG trả về chunk mà người hỏi không được phép đọc → rò rỉ nội bộ qua chính trợ lý.
• Coi GenAI như phần mềm thường: bỏ qua model risk và không xin duyệt governance.

Ví dụ minh hoạ luồng nền tảng

Đoạn dưới là pseudocode minh hoạ (không phải mã chạy được, không phải SQL) — thể hiện thứ tự các lớp trong một request:

# MINH HOẠ — luồng xử lý một truy vấn trợ lý tra cứu nội bộ
def handle(query, user):
    audit_log(user, query)                      # cổng: ghi vết
    if not authz.can_use(user):                 # AuthZ
        return deny()

    clean = input_guardrails(query)             # bài 3 & 4: che PII, chặn injection
    if clean.blocked:
        return safe_refusal(clean.reason)

    # retrieval CHỈ trên tài liệu user được phép đọc
    ctx = vector_store.search(clean.text, acl=user.doc_permissions)

    answer = llm.generate(                       # self-host hoặc API có hợp đồng
        system=BANK_POLICY_PROMPT,
        context=ctx, question=clean.text
    )

    checked = output_guardrails(answer, ctx)     # bài 3 & 5: PII, grounding
    if not checked.grounded:
        return "Tôi không đủ căn cứ trong tài liệu để trả lời."

    observability.record(user, tokens, cost, latency)   # bài 6
    return with_citations(checked.answer, ctx)   # luôn kèm trích nguồn

Lưu ý: nếu grounding thất bại, trợ lý từ chối thay vì bịa — với ngân hàng, "không biết" an toàn hơn "đoán sai".

Tổng kết series — bản đồ 8 bài

Series đi từ tư duy (bài 1) qua kỹ thuật (bài 2–6) tới quản trị (bài 7), và khép lại bằng nền tảng (bài 8). Xuyên suốt, thông điệp không đổi: trong ngân hàng, GenAI hữu ích nhưng phải được bọc trong nhiều lớp phòng thủ, đo lường và trách nhiệm giải trình. Để đối chiếu với hạ tầng LLM tổng quát và MLOps, xem LLM 7 — production và MLOps 7 — governance.

Use case thực tế

Bối cảnh. NCB muốn triển khai Trợ lý tra cứu quy định nội bộ cho ~300 cán bộ tín dụng và vận hành. Kho tài liệu: ~1.200 văn bản (quy chế, quy trình, thông báo) — dữ liệu nội bộ nhạy cảm nhưng không phải PII khách hàng. Chọn use case này vì rủi ro thấp–trung và giá trị rõ (cán bộ đang mất 10–15 phút/lần lục văn bản).

Quyết định triển khai. Vì tài liệu là nội bộ nhạy cảm, chọn self-host một mô hình mở trên GPU riêng cho pha sinh, kết hợp vector store nội bộ. Không đẩy tài liệu ra API bên ngoài. RAG là mẫu duy nhất; không dùng agent.

Lộ trình 12 tuần.

1. Tuần 1–3: nạp 1.200 văn bản, chunking + embedding, gắn ACL theo phòng ban vào từng chunk.
2. Tuần 4–6: dựng đường ống guardrail + retrieval + LLM + trích nguồn; build bộ eval 120 câu hỏi có đáp án chuẩn do SME gán nhãn.
3. Tuần 7–8: đo baseline — mục tiêu grounding ≥ 95%, tỷ lệ trả lời có citation đúng ≥ 90%. Vòng đầu chỉ đạt 82% grounding → chỉnh chunking và system prompt, lên 96%.
4. Tuần 9–10: pilot với 25 cán bộ, bật observability đầy đủ (token, chi phí, độ trễ, log hội thoại).
5. Tuần 11–12: model card + duyệt governance (bài 7) → go-live có kiểm soát.

Kết quả (giả định minh hoạ). Thời gian tra cứu trung bình giảm từ ~12 phút xuống ~2 phút. Chi phí vận hành đo được và ổn định nhờ dashboard. Không có sự cố rò rỉ vì retrieval tôn trọng ACL: cán bộ chỉ thấy chunk phòng ban mình được phép. Với nền tảng đã dựng, use case thứ hai (tóm tắt tài liệu tín dụng) chỉ cần thêm prompt và bộ eval mới — không phải xây lại hạ tầng.

Ghi nhớ

• Trợ lý GenAI ngân hàng là một hệ thống nhiều lớp, không phải một lời gọi API: cổng → orchestration → input guardrails → retrieval (có phân quyền) → LLM → output guardrails → trả lời có trích nguồn.
• Bao quanh đường ống là 5 dịch vụ cắt ngang: observability/cost, evaluation, security, governance, identity & phân quyền tài liệu. Thiếu mảnh nào là có lỗ hổng đó.
• Dữ liệu nhạy cảm → ưu tiên self-host mô hình mở/triển khai riêng; nếu dùng API thì bắt buộc không lưu, không train, data residency trong hợp đồng.
• Bắt đầu bằng use case nội bộ rủi ro thấp (tra cứu quy định qua RAG). Use case đối mặt khách hàng và tham gia quyết định là rủi ro cao — làm sau, kèm guardrail chặt và human fallback.
• Lộ trình: use case nội bộ → PoC → đánh giá nghiêm → pilot có kiểm soát → mở rộng dần qua governance. Đầu tư vào nền tảng dùng lại được, không vào một tính năng.
• Cạm bẫy chết người: chạy theo hype, bỏ qua eval/guardrail, đưa vào quyết định rủi ro cao quá sớm, quên chi phí, quên phân quyền tài liệu.
• Grounding thất bại thì từ chối thay vì bịa. Trong ngân hàng, "không biết" an toàn hơn "đoán sai".