Sau bước lọc thời gian, hệ thống mới thực hiện truy hồi và xếp hạng. Cách này giúp tránh đưa văn bản hết hiệu lực vào ngữ cảnh trả lời.

b. Hybrid Search, reranking và graph expansion

Pipeline retrieval kết hợp:

• Tìm kiếm ngữ nghĩa bằng vector embedding.
• Tìm kiếm từ khóa/BM25 để giữ các mã văn bản, số điều, số khoản và thuật ngữ chính xác.
• Reciprocal Rank Fusion để hợp nhất hai danh sách kết quả.
• Reranker hoặc heuristic ranking để ưu tiên các đoạn phù hợp nhất với câu hỏi.
• Mở rộng đồ thị để lấy thêm điều khoản cha, điều khoản con và các căn cứ được dẫn chiếu.

Kết quả trả về cần giữ được chunk_id, provision_ids, text_display, thông tin hiệu lực và metadata trích dẫn để có thể giải thích nguồn.

c. PII Gateway và guardrail cục bộ

Trước khi dữ liệu đi tới mô hình ngôn ngữ, lớp bảo vệ cục bộ phát hiện và che giấu dữ liệu nhạy cảm như tên cá nhân, mã số định danh hoặc thông tin doanh nghiệp. Guardrail cũng có thể dừng luồng khi phát hiện prompt injection, câu hỏi thiếu ngữ cảnh hoặc yêu cầu nằm ngoài phạm vi.

Nguyên tắc thiết kế là dữ liệu phải được giảm thiểu ngay tại biên, thay vì phụ thuộc hoàn toàn vào lời nhắc gửi cho LLM.

d. Output verification và audit

Kết quả được kiểm tra về nguồn trích dẫn, độ bao phủ căn cứ và tính nhất quán với các quy tắc xác định. Các thao tác quản trị văn bản, thay đổi trạng thái hiệu lực và hành động nhạy cảm được ghi vào audit trail append-only.

e. Kiến trúc triển khai

Luồng chính có dạng:

Người dùng đặt câu hỏi
        ↓
PII Gateway / Guardrail
        ↓
Phân loại lượt hỏi và phân tích định danh pháp lý
        ↓
Temporal filter
        ↓
Hybrid retrieval → rerank → graph/context expansion
        ↓
Trả lời có căn cứ và trạng thái kiểm chứng

Trong mã nguồn hiện tại, graph tiền xử lý, temporal filter, retrieval orchestrator và các hợp đồng dữ liệu đã được tổ chức rõ. Knowledge Base production đầy đủ và một số extension sau retrieval vẫn là hạng mục cần hoàn thiện; vì vậy UX không nên cam kết những hành vi chưa được nối vào runtime.

2.3. Tính khả thi

Tính khả thi của tính năng đến từ bốn nền tảng đã có:

1. Kiến trúc phù hợp: LangGraph cho phép tách guardrail, phân tích câu hỏi, retrieval và các bước kiểm chứng thành các node có thể quan sát và kiểm thử.
2. Mô hình dữ liệu phù hợp: PostgreSQL/pgvector có thể lưu văn bản, metadata hiệu lực và embedding; quan hệ sửa đổi hoặc dẫn chiếu có thể biểu diễn bằng bảng cạnh.
3. Khả năng triển khai tăng dần: Có thể bắt đầu với hybrid search và heuristic reranker, sau đó thay thế bằng cross-encoder hoặc dịch vụ chuyên dụng khi dữ liệu đủ lớn.
4. Kiểm soát rủi ro: PII masking, temporal filter, citation requirement và audit log tạo thành các lớp bảo vệ độc lập, phù hợp với môi trường tài chính.

Các rủi ro chính là chất lượng dữ liệu pháp luật, việc parse cấu trúc Điều/Khoản/Điểm, xử lý văn bản tiếng Việt dạng scan và độ chính xác của quan hệ sửa đổi. Những rủi ro này có thể giảm bằng quy trình ingest có kiểm duyệt, dữ liệu vàng cho evaluation, kiểm tra hồi quy và cơ chế trả về MISSING_BASIS khi không có đủ căn cứ.

2.4. Hướng phát triển

• Hoàn thiện Knowledge Base production với SCD-2 cho phiên bản văn bản, pgvector cho dense search và PostgreSQL FTS cho sparse search.
• Xây dựng pipeline ingest PDF/DOCX có OCR, phân đoạn theo cấu trúc pháp lý và chuẩn hóa số hiệu văn bản.
• Hoàn thiện xử lý quan hệ sửa đổi, bổ sung, thay thế, bãi bỏ và dẫn chiếu chưa giải quyết.
• Bổ sung citation viewer: hiển thị đoạn nguồn, số văn bản, điều khoản và thời điểm hiệu lực ngay cạnh câu trả lời.
• Thêm bộ đánh giá định lượng cho temporal accuracy, citation precision, recall căn cứ và tỷ lệ từ chối đúng khi thiếu cơ sở.
• Hỗ trợ quản trị phiên bản, phê duyệt nội dung ingest và cảnh báo khi văn bản sắp hết hiệu lực.
• Mở rộng sang kiểm tra chính sách nội bộ, checklist tuân thủ sản phẩm và phân tích khác biệt giữa hai phiên bản quy định.

3. Tính năng 2 — Tự động hóa thẩm định hồ sơ vay SME

3.1. Bài toán

Một bộ hồ sơ vay SME thường gồm nhiều tài liệu PDF/DOCX từ các nguồn khác nhau: đăng ký doanh nghiệp, báo cáo tài chính, tờ khai thuế, sao kê ngân hàng, báo cáo CIC, phương án kinh doanh và hồ sơ tài sản bảo đảm.

Quy trình thủ công gặp các vấn đề:

• Người vay không biết chính xác cần nộp tài liệu nào theo từng sản phẩm tín dụng.
• Chuyên viên phải đọc và nhập lại cùng một thông tin từ nhiều chứng từ.
• Dữ liệu có thể thiếu, sai định dạng hoặc mâu thuẫn giữa ĐKKD, BCTC, thuế, ngân hàng và CIC.
• Việc kiểm tra các chỉ tiêu như doanh thu, vốn chủ sở hữu, DSCR, nhóm nợ và LTV tốn thời gian.
• Những yêu cầu bổ sung thường trao đổi qua nhiều kênh, khó theo dõi phiên bản và trạng thái.
• Báo cáo thẩm định và bộ hồ sơ nộp cuối cùng phải được tổng hợp thủ công.

Điểm nghẽn này làm kéo dài thời gian từ lúc tiếp nhận đến lúc có thể phê duyệt, đồng thời làm tăng nguy cơ bỏ sót lỗi hoặc sử dụng dữ liệu chưa được xác nhận.

3.2. Giải pháp kỹ thuật

a. Borrower Portal và checklist theo sản phẩm

Specialist tạo workspace và loan case, chọn ngân hàng, sản phẩm vay và phiên bản bộ yêu cầu. Borrower truy cập qua invitation token, xem checklist riêng của hồ sơ, tải tài liệu và theo dõi trạng thái từng yêu cầu.

Checklist có thể phân biệt tài liệu bắt buộc, tùy chọn và có điều kiện; ví dụ giấy phép con chỉ được kích hoạt khi doanh nghiệp thuộc ngành nghề kinh doanh có điều kiện.

b. Document intake, classification và extraction

Mỗi lần upload tạo document version, artifact và processing job. Worker xử lý theo lease, heartbeat, retry và input signature để tránh công bố kết quả cũ.

Luồng AI có thể:

• Preflight định dạng, kích thước và chữ ký file.
• Phân loại tài liệu như ĐKKD, BCTC, tờ khai thuế, sao kê, tài sản bảo đảm.
• Trích xuất trường dữ liệu có schema từ Gemini hoặc OpenAI khi provider được bật.
• Chuẩn hóa ngày tháng, tiền tệ, mã số thuế, tên pháp nhân và các giá trị tài chính.
• Gắn provenance để chuyên viên có thể xem dữ liệu được lấy từ tài liệu nào.

AI chỉ tạo dữ liệu đề xuất; các trường quan trọng vẫn cần trạng thái verified hoặc sự xác nhận của người có quyền.

c. Validation Rule Engine

Rule Engine đối chiếu facts đã trích xuất với chính sách của sản phẩm. Một số nhóm kiểm tra tiêu biểu:

• CIC thuộc nhóm được phép.
• Doanh nghiệp hoạt động đủ số tháng tối thiểu.
• Vốn chủ sở hữu dương và không lỗ liên tiếp theo chính sách.
• Tên pháp nhân, mã số thuế và chủ tài khoản nhất quán giữa các tài liệu.
• Doanh thu, dư nợ, DSCR và khả năng trả nợ đạt ngưỡng.
• Tài sản bảo đảm phù hợp loại tài sản và tỷ lệ LTV.
• Tài liệu có đúng thời hạn hiệu lực hoặc đã hết hạn.

Mỗi kết quả nên có severity, finding type, bằng chứng, trạng thái xử lý và action hint. Điều này giúp phân biệt lỗi chặn hồ sơ với cảnh báo cần bổ sung.

d. Readiness Dashboard và Action Center

Hệ thống tổng hợp trạng thái tài liệu, facts, validation và change request thành một chỉ số readiness. Specialist nhìn thấy các blocker, missing requirement, mismatch và nhiệm vụ cần xử lý; Borrower chỉ nhìn thấy các yêu cầu thuộc phạm vi của mình.

e. Report và submission package

Khi hồ sơ đạt điều kiện, hệ thống tạo snapshot bất biến, sinh Credit Appraisal Report và đóng gói tài liệu cùng manifest. Snapshot giúp kết quả phê duyệt có thể truy nguyên về đúng phiên bản tài liệu và dữ liệu tại thời điểm nộp.

Luồng tổng quát:

Specialist tạo workspace/case
        ↓
Chọn sản phẩm và checklist bất biến
        ↓
Borrower nhận lời mời và nộp tài liệu
        ↓
Worker phân loại → trích xuất → chuẩn hóa
        ↓
Facts được xác nhận và chạy validation rules
        ↓
Readiness Dashboard + Action Center
        ↓
Review / Change Request
        ↓
Snapshot → Report → Submission Package

3.3. Tính khả thi

Tính năng có tính khả thi cao vì đã có cấu trúc domain và API tương ứng cho workspace, loan case, participant, document, fact, finding, validation, readiness, review, report và submission.

Các yếu tố hỗ trợ triển khai thực tế:

1. Xử lý bất đồng bộ: Classification, extraction, validation và report được tách thành background jobs, tránh khóa request của người dùng.
2. Mở rộng theo adapter: Gemini và OpenAI được đóng gói qua factory/adapter, có thể chuyển provider hoặc chạy heuristic fallback.
3. Bảo toàn lịch sử: Document version, snapshot, audit log và input signature giúp kiểm tra lại kết quả.
4. Phân quyền theo vai trò và phạm vi hồ sơ: Backend thực thi access/capability, không chỉ dựa vào việc ẩn màn hình ở frontend.
5. Triển khai theo MVP: Có thể bắt đầu với một sản phẩm vay lưu động, một bộ checklist và các quy tắc blocker quan trọng trước khi mở rộng nhiều ngân hàng.

Rủi ro lớn nhất là tài liệu scan chất lượng thấp, bố cục đa dạng, thuật ngữ tài chính không đồng nhất và sai lệch giữa dữ liệu AI với chứng từ gốc. Vì vậy, hệ thống cần confidence score, evidence locator, hàng đợi review thủ công và nguyên tắc không tự động phê duyệt chỉ dựa trên kết quả LLM.

3.4. Hướng phát triển

• Hoàn thiện OCR và document layout understanding cho tài liệu scan, bảng biểu và ảnh chụp.
• Bổ sung confidence score, vị trí trích xuất theo trang/dòng và nút xác nhận từng fact.
• Mở rộng catalog nhiều ngân hàng, nhiều sản phẩm và versioned policy pack.
• Bổ sung rule builder cho chuyên viên nghiệp vụ thay vì phải sửa code khi thay đổi ngưỡng.
• Tự động phát hiện bất thường xuyên tài liệu: doanh thu không khớp, mã số thuế khác nhau, sao kê không thuộc doanh nghiệp hoặc số liệu tài chính thay đổi bất thường.
• Hoàn thiện change request loop với thông báo, SLA, phân công và lịch sử trao đổi.
• Thêm khả năng tái chạy có kiểm soát khi một tài liệu được thay thế, chỉ invalidating các kết quả phụ thuộc.
• Sinh báo cáo có trích dẫn về tài liệu nguồn, biểu đồ tài chính và phần giải thích cho từng finding.
• Tích hợp chữ ký số, kiểm tra CIC/thuế qua kênh được cấp phép và object storage mã hóa khi triển khai production.
• Xây dựng dashboard vận hành theo dõi thời gian xử lý, tỷ lệ lỗi extraction, tỷ lệ hồ sơ hoàn tất và các quy tắc thường xuyên gây blocker.

4. Nền tảng kỹ thuật dùng chung

Hai tính năng dùng chung một nền tảng bảo mật và vận hành:

Thiết kế này cho phép phát triển hai tính năng như hai module nghiệp vụ riêng, nhưng vẫn chia sẻ identity, audit, lưu trữ, quan sát hệ thống và cơ chế kiểm thử.

5. Đánh giá tổng thể và lộ trình ưu tiên

Giai đoạn 1 — Củng cố MVP

• Hoàn thiện một sản phẩm vay SME và checklist chuẩn.
• Bảo đảm upload, classification, extraction, validation, readiness và report chạy ổn định từ đầu đến cuối.
• Hoàn thiện Knowledge Base tối thiểu cho một nhóm văn bản pháp lý có dữ liệu thật.
• Thiết lập bộ test hồi quy cho các quy tắc blocker và temporal retrieval.

Giai đoạn 2 — Tăng độ tin cậy

• Thêm provenance, confidence score, citation viewer và evidence locator.
• Bổ sung bộ dữ liệu đánh giá được chuyên gia gán nhãn.
• Đo lường precision/recall của retrieval, extraction accuracy, tỷ lệ false positive và thời gian xử lý hồ sơ.
• Hoàn thiện monitoring, retry, dead-letter handling và cảnh báo worker.

Giai đoạn 3 — Mở rộng sản phẩm

• Nhiều ngân hàng, sản phẩm và bộ chính sách versioned.
• OCR/layout understanding nâng cao.
• Tích hợp các nguồn dữ liệu bên ngoài được cấp phép.
• Hỗ trợ workflow phê duyệt nhiều cấp, chữ ký số và triển khai multi-tenant.

6. Kết luận

ComplianceAI giải quyết hai điểm nghẽn có liên hệ trực tiếp trong hoạt động tín dụng: hiểu đúng quy định và xử lý đúng hồ sơ. Trợ lý pháp lý cung cấp nền tảng tra cứu có kiểm soát theo thời gian và có căn cứ; nền tảng hồ sơ vay biến quy trình thu thập, trích xuất và kiểm tra tài liệu thành một workflow có trạng thái, quy tắc và khả năng truy vết.

Với kiến trúc FastAPI–Next.js–PostgreSQL, LangGraph, processing worker và các lớp guardrail, dự án có nền tảng kỹ thuật để triển khai theo từng MVP nhỏ, kiểm chứng bằng dữ liệu thực tế và mở rộng dần mà không cần thay đổi toàn bộ hệ thống.