Hầu hết các dự án AI trong ngành ngân hàng thất bại vì một lý do không liên quan gì đến chất lượng mô hình. Các đội ngũ lãnh đạo dành hàng tháng trời để so sánh số lượng tham số và điểm số benchmark, trong khi một mối đe dọa thầm lặng đang bào mòn mọi thứ họ xây dựng. Họ coi kích thước mô hình là điều kiện để chiến thắng. Nhưng không phải vậy. Trong các quy trình làm việc đa bước và được quản lý chặt chẽ vốn đang thống trị ngành tài chính, độ chính xác không nhân lên theo cấp số nhân. Nó bị suy giảm. Nếu chỉ tập trung vào điểm số của từng bước đơn lẻ, bạn sẽ bị bất ngờ bởi sự thất bại của toàn bộ hệ thống.

Vấn đề thực sự không nằm ở kích thước mô hình

Đây là phép toán khiến các cán bộ quản trị rủi ro phải mất ngủ. Hãy tưởng tượng một quy trình gồm sáu giai đoạn riêng biệt—trích xuất dữ liệu, xác thực, chấm điểm rủi ro, kiểm tra tuân thủ, tạo tài liệu và phê duyệt cuối cùng. Mỗi giai đoạn hoạt động hoàn hảo khi đứng độc lập, đạt độ chính xác 97%. Bản năng sẽ thôi thúc chúng ta ăn mừng. Nhưng xác suất không tuân theo trực giác. Khi kết nối các bước đó lại với nhau, độ tin cậy của toàn bộ quy trình sẽ sụt giảm xuống còn khoảng 83%.

Khoảng cách giữa sự hoàn hảo cục bộ và sự thất bại toàn cục đó chính là Khoảng cách Điều phối AI (AI Coordination Gap). Đó là sự ma sát mà bạn mất đi trong quá trình bàn giao giữa các tác nhân (agents), công cụ phần mềm và người kiểm duyệt. Các cơ quan quản lý đã và đang săn tìm chính lỗ hổng này. Họ sẽ phát hiện ra nó trước khi đội ngũ kỹ sư của bạn hoàn tất báo cáo phân tích sau sự cố (post-mortem).

Đến năm 2026, cuộc thảo luận đã thay đổi. Câu hỏi không còn là mô hình nào đứng đầu bảng xếp hạng nghiên cứu. Thay vào đó là về kỷ luật ngân sách, chủ quyền dữ liệu và kiểm soát cập nhật. Bạn đang phải lựa chọn giữa một mô hình ngôn ngữ nhỏ (Small Language Model - SLM) tùy chỉnh mà bạn có thể kiểm soát trong hạ tầng riêng, hoặc một mô hình ngôn ngữ lớn (Large Language Model - LLM) có sẵn mà bạn phải thuê theo từng token.

SLM so với LLM: Điều gì thực sự thay đổi vào năm 2026

Các mô hình tiên phong có sẵn trên thị trường—GPT-4o, Claude và các đối thủ cùng tầm—vẫn chưa có đối thủ trong việc lập luận mở và các tác vụ phân tích khối lượng thấp. Chúng có khả năng hiểu được ẩn ý. Chúng xử lý được các sắc thái. Nhưng sự tiện lợi này đi kèm với một cái giá. Bạn không sở hữu các trọng số (weights). Bạn không kiểm soát được lịch trình phát hành. Một bản cập nhật âm thầm vào cuối tuần từ nhà cung cấp có thể thay đổi cách ứng dụng của bạn diễn giải các ngưỡng nợ trên thu nhập hoặc gắn cờ các giao dịch đáng ngờ, và bạn có thể không có hồ sơ ghi lại chính xác những gì đã thay đổi. Trong một ngành công nghiệp mà mọi quyết định đều yêu cầu dấu vết kiểm toán (audit trail), sự thiếu minh bạch đó là một chi phí đắt đỏ.

Các SLM tùy chỉnh được xây dựng trên các trọng số mở như Llama hoặc Mistral sẽ đảo ngược phương trình này. Chúng được xây dựng chuyên biệt cho các công việc nặng nhọc, khối lượng lớn: trích xuất các trường thông tin từ file PDF thế chấp, phân loại tài liệu KYC hoặc phân tích các ghi chú giao dịch. Vì bạn tự lưu trữ chúng, bạn có thể đóng băng một phiên bản, chạy kiểm thử sai biệt (differential testing) và chứng minh với kiểm toán viên rằng mô hình hoạt động vào tháng Ba hoàn toàn giống với mô hình hoạt động vào tháng Sáu. Chúng cũng rẻ đến mức khắc nghiệt, với chi phí mỗi token thấp hơn khoảng mười đến ba mươi lần so với các "người anh em" chạy trên đám mây. Sự đánh đổi là khả năng hẹp hơn. Một SLM sẽ không triết lý về các xu hướng thị trường. Tuy nhiên, nó có thể đóng dấu mười nghìn hóa đơn mỗi giờ mà không cần gửi dữ liệu độc quyền ra ngoài tường lửa của bạn.

Định tuyến không đồng nhất: Tỷ lệ phân chia 80/20

Những ngân hàng đang dẫn đầu đã ngừng coi đây là một lựa chọn "một mất một còn". Kiến trúc của họ là không đồng nhất (heterogeneous). Một SLM rẻ tiền, được tinh chỉnh sẽ xử lý lượt đầu tiên cho các công việc có cấu trúc và có thể dự đoán được—như trích xuất tài liệu, gắn thẻ thực thể hoặc sàng lọc điều kiện hợp lệ định kỳ—xử lý khoảng 80% tổng khối lượng. 20% còn lại, những trường hợp biên cần lập luận tương tự hoặc diễn giải chính sách phức tạp, sẽ được chuyển lên một LLM tiên phong.

Điều này không phải là lý thuyết. Một đơn vị dịch vụ thế chấp có thể để SLM trích xuất các con số thu nhập từ phiếu lương, sau đó chỉ chuyển các hồ sơ mơ hồ đến một mô hình lớn hơn để đối chiếu nhiều loại hình việc làm với các hướng dẫn liên bang đang thay đổi. Bạn cắt giảm chi phí đám mây mà không làm giảm khả năng xử lý.

Khung làm việc năm lớp để thu hẹp khoảng cách

Để thu hẹp Khoảng cách Điều phối, cần nhiều hơn là chỉ định tuyến thông minh. Nó cần một ngăn xếp (stack) rõ ràng. Dưới đây là khung làm việc năm lớp mà các đội ngũ có thể triển khai ngay bây giờ.

  1. Lựa chọn mô hình. Hãy coi việc suy luận (inference) giống như một y tá phân loại bệnh nhân. Định tuyến các tác vụ dựa trên khối lượng và mức độ nhạy cảm. Các hoạt động tần suất cao, rủi ro thấp sẽ được chuyển cho SLM. Các trường hợp liên quan đến phán đoán, sự mơ hồ hoặc giải quyết khiếu nại khách hàng sẽ được chuyển cho LLM. Hãy viết các quy tắc định tuyến bằng mã code, chứ không phải bằng một câu lệnh (prompt).

  2. Căn cứ dữ liệu. Mọi câu trả lời tiếp xúc với khách hàng đều phải dẫn chiếu về một tài liệu nguồn. Sử dụng kỹ thuật tạo phản hồi tăng cường truy xuất (retrieval-augmented generation) để neo giữ các kết quả đầu ra vào các sổ tay chính sách, bảng lãi suất và thông báo quy định thực tế của bạn. Đừng bao giờ tin tưởng vào bộ nhớ tham số (parametric memory) của mô hình đối với các mức lãi suất hoặc biểu phí hiện hành. Bộ nhớ có thể bị sai lệch. Một tệp PDF có số phiên bản thì không.

  3. Điều phối. Xây dựng các quy trình làm việc mà trong đó lộ trình có thể quan sát được. Các công cụ như LangGraph cho phép bạn định nghĩa các máy trạng thái (state machines) rõ ràng và có thể kiểm chứng. Một quyết định nên đi qua các giai đoạn đã được xác định: trích xuất, xác minh, ra quyết định, ghi nhật ký. Đừng để các tác nhân (agents) tự "trò chuyện" để đi đến kết luận trong một vòng lặp hội thoại mở. Nếu bạn không thể vẽ được sơ đồ luồng, bạn sẽ không thể giải trình với cơ quan quản lý.

  4. Truy cập công cụ. Các tác nhân cần gọi các hệ thống ngân hàng lõi, nhưng mọi sự tích hợp đều là một điểm lỗi tiềm ẩn. Sử dụng Model Context Protocol để tiêu chuẩn hóa cách các tác nhân xác thực và truy vấn sổ cái, hồ sơ CRM và cơ sở dữ liệu tuân thủ của bạn. Các giao diện thống nhất giúp giảm thiểu phạm vi xảy ra các lỗi ngầm.

  5. Xác minh. Hãy dành riêng một lộ trình cố định cho sự phán đoán của con người. Chuyển các quyết định rủi ro cao—như chuyển khoản điện tử lớn, ghi đè hạn mức tín dụng, báo cáo giao dịch đáng ngờ (SAR)—đến người kiểm duyệt hoặc đến một tác nhân xác minh thứ hai chạy trên một mô hình độc lập. Sự dự phòng ở biên sẽ bảo vệ trung tâm.

Đo lường đúng thứ cần thiết

Hãy ngừng khen thưởng các nhóm dựa trên độ chính xác của từng bước. Một đường ống (pipeline) mà mỗi mô-đun đều đạt độ chính xác 99% trên tập kiểm thử vẫn có thể thất bại với 1 trong 5 khách hàng thực tế khi các bước tương tác với nhau. Hãy bắt đầu đo lường độ tin cậy đầu-cuối (end-to-end). Đưa vào các trường hợp lỗi giả lập (synthetic failure cases). Kiểm tra các bước bàn giao giống như cách những kẻ tấn công kiểm tra các kẽ hở.

Những ngân hàng thực sự chiến thắng nhờ AI vào năm 2026 không phải là những bên thuê các mô hình lớn nhất. Họ là những bên đang kết nối các hệ thống rõ ràng nhất. Họ biết rằng một mô hình nhỏ mà bạn có thể kiểm chứng sẽ tốt hơn một mô hình lớn mà bạn không thể giải thích, và rằng