Cách LLM xử lý quy tắc nghiệp vụ và suy luận luồng công việc

Tại sao suy luận quy tắc nghiệp vụ nhiều hơn là tạo mã

Khi người ta hỏi liệu một LLM có “suy luận về quy tắc nghiệp vụ” được hay không, thường họ muốn điều gì đó đòi hỏi hơn là “nó có thể viết một câu if/else không.” Suy luận quy tắc nghiệp vụ là khả năng áp dụng chính sách một cách nhất quán, giải thích quyết định, xử lý ngoại lệ và luôn phù hợp với bước hiện tại của luồng công việc — đặc biệt khi dữ liệu vào không đầy đủ, lộn xộn hoặc thay đổi.

Suy luận so với xuất mã

Tạo mã chủ yếu là về sản xuất cú pháp hợp lệ trong ngôn ngữ mục tiêu. Suy luận quy tắc là về giữ nguyên ý định.

Một mô hình có thể sinh ra mã hoàn toàn hợp lệ nhưng vẫn cho kết quả nghiệp vụ sai vì:

• Văn bản chính sách mơ hồ (“khách hàng gần đây”, “rủi ro cao”, “tài liệu được phê duyệt”).
• Các quy tắc xung đột và độ ưu tiên không rõ ràng.
• Các trường hợp biên không được nêu (hoàn tiền một phần, trùng lặp, cuối tuần/ngày nghỉ).
• Trạng thái luồng công việc thay đổi điều gì nên xảy ra tiếp theo (tiếp nhận so với xem xét so với phê duyệt cuối cùng).

Nói cách khác, đúng không phải là “có biên dịch được không?” Mà là “nó có khớp với quyết định mà doanh nghiệp sẽ đưa ra, mọi lúc, và chúng ta có thể chứng minh được không?”

Mong đợi gì từ LLM

LLM có thể giúp chuyển chính sách thành các quy tắc có cấu trúc, gợi ý đường dẫn quyết định và soạn lời giải thích cho con người. Nhưng chúng không tự động biết quy tắc nào có thẩm quyền, nguồn dữ liệu nào đáng tin, hoặc bước hiện tại của trường hợp đang ở đâu. Thiếu ràng buộc, chúng có thể tự tin chọn một câu trả lời có vẻ hợp lý thay vì câu trả lời được quản trị.

Vì vậy mục tiêu không phải là “để mô hình quyết định,” mà là cung cấp cho nó cấu trúc và kiểm tra để nó hỗ trợ một cách đáng tin cậy.

Phần còn lại của bài viết sẽ làm gì

Một phương pháp thực tế trông như một pipeline:

1. Chuyển văn bản chính sách thành biểu diễn quy tắc có thể dùng được.
2. Theo dõi trạng thái luồng công việc để quyết định luôn nhất quán qua các bước.
3. Sử dụng mẫu prompt để thực thi ưu tiên, ngoại lệ và lời giải thích.
4. Căn cứ quyết định bằng công cụ và truy xuất (chỉ dùng dữ liệu được phê duyệt).
5. Hạn chế đầu ra bằng các schema để giảm mơ hồ.
6. Xác thực, kiểm thử và giám sát để lỗi được phát hiện trước khi phát hành.

Đó là khác biệt giữa một đoạn mã thông minh và một hệ thống có thể hỗ trợ các quyết định thực tế của doanh nghiệp.

Quy tắc nghiệp vụ và luồng công việc: ôn tập ngắn bằng tiếng thường

Trước khi nói về cách LLM xử lý “suy luận,” hữu ích khi tách hai thứ mà các đội thường gộp chung: quy tắc nghiệp vụ và luồng công việc.

Quy tắc nghiệp vụ là gì?

Quy tắc nghiệp vụ là các phát biểu quyết định mà tổ chức muốn thực thi một cách nhất quán. Chúng xuất hiện dưới dạng chính sách và logic như:

• Điều kiện đủ điều kiện: Ai đủ điều kiện cho một lợi ích, gói dịch vụ hay tính năng?
• Giá cả: Giảm giá nào áp dụng, và khi nào?
• Phê duyệt: Khi nào cần xét duyệt bởi quản lý?
• Tuân thủ: Cái gì phải được ghi nhật ký, che mờ hoặc chặn?

Quy tắc thường được diễn đạt dưới dạng “IF X, THEN Y” (đôi khi có ngoại lệ), và chúng nên đưa ra kết quả rõ ràng: chấp thuận/từ chối, giá A/giá B, yêu cầu thêm thông tin, v.v.

Luồng công việc là gì?

Một luồng công việc là quy trình đưa công việc từ đầu đến cuối. Nó ít liên quan đến việc quyết định cái gì được cho phép và nhiều hơn đến cái gì xảy ra tiếp theo. Luồng công việc thường bao gồm:

• Trạng thái: submitted → under review → approved/denied → completed
• Bước và chuyển giao: hỗ trợ khách hàng → tài chính → khách hàng
• Sự kiện theo thời gian: nhắc nhở, SLA, hủy tự động sau 14 ngày
• Hiệnt ượng: biểu mẫu, tệp đính kèm, mã lý do, ghi chú kiểm toán

Ví dụ nhỏ: yêu cầu hoàn tiền

Hãy tưởng tượng một yêu cầu hoàn tiền.

Đoạn quy tắc: “Hoàn tiền được cho phép trong vòng 30 ngày kể từ ngày mua. Ngoại lệ: tải xuống kỹ thuật số không được hoàn tiền sau khi đã truy cập. Ngoại lệ: tranh chấp thẻ (chargeback) phải được chuyển lên xử lý.”

Đoạn luồng công việc:

1. Khách hàng gửi yêu cầu (trạng thái: submitted).
2. Hệ thống kiểm tra ngày mua và loại sản phẩm (trạng thái: under review).
3. Nếu đủ điều kiện, phát hành hoàn tiền và thông báo khách (trạng thái: completed).
4. Nếu có chargeback, chuyển sang tài chính để điều tra (trạng thái: escalated).

Tại sao quy tắc lại khó hơn vẻ ngoài

Quy tắc trở nên rắc rối khi chúng mâu thuẫn (“khách VIP luôn được hoàn tiền” vs. “tải xuống kỹ thuật số không bao giờ được hoàn tiền”), phụ thuộc vào ngữ cảnh thiếu (tệp đã được truy cập chưa?), hoặc ẩn các trường hợp biên (gói sản phẩm, hoàn tiền một phần, luật vùng). Luồng công việc thêm một lớp nữa: quyết định phải phù hợp với trạng thái hiện tại, hành động trước đó và thời hạn.

LLM “suy luận” thế nào: khớp mẫu có cấu trúc hỗ trợ

LLM không “hiểu” quy tắc nghiệp vụ như con người. Chúng tạo từ tiếp theo có khả năng nhất dựa trên các mẫu học được từ lượng lớn văn bản. Đó là lý do tại sao LLM có thể nghe thuyết phục ngay cả khi nó đang phỏng đoán — hoặc khi nó âm thầm điền vào những chi tiết còn thiếu.

Hạn chế này quan trọng đối với luồng công việc và logic quyết định. Một mô hình có thể áp dụng quy tắc có vẻ đúng (“nhân viên luôn cần phê duyệt của quản lý”) dù chính sách thực có ngoại lệ (“chỉ trên $500” hoặc “chỉ cho nhà thầu”). Đây là một chế độ lỗi phổ biến: tự tin nhưng áp dụng sai quy tắc.

Tại sao chúng vẫn hữu ích cho quy tắc nghiệp vụ

Ngay cả khi không có “hiểu biết” thực sự, LLM có thể hữu ích khi bạn coi chúng là trợ lý có cấu trúc:

• Tóm tắt các chính sách dài thành ngôn ngữ rõ ràng để xem xét
• Ánh xạ văn bản lộn xộn thành các trường nhất quán (ai, cái gì, ngưỡng, ngoại lệ, ngày hiệu lực)
• Kiểm tra một quyết định đề xuất so với các quy tắc đã nêu (“điều khoản nào hỗ trợ việc này?”)

Chìa khóa là đặt mô hình vào vị trí mà nó không dễ lệch vào ứng biến.

Hạn chế mô hình để nó không đi lang thang

Một cách thực tế để giảm mơ hồ là hạn chế đầu ra: yêu cầu LLM trả lời theo một schema hoặc mẫu cố định (ví dụ JSON với các trường cụ thể, hoặc bảng với các cột bắt buộc). Khi mô hình phải điền rule_id, conditions, exceptions và decision, sẽ dễ phát hiện lỗ hổng và kiểm chứng đầu ra tự động hơn.

Định dạng bị hạn chế cũng làm rõ khi mô hình không biết điều gì đó. Nếu một trường bắt buộc thiếu, bạn có thể buộc hỏi bổ sung thay vì chấp nhận một câu trả lời không chắc chắn.

Kết luận: “suy luận” của LLM nên được coi là sinh ra theo mẫu được hướng dẫn bằng cấu trúc — hữu ích để tổ chức và đối chiếu quy tắc, nhưng rủi ro nếu coi nó là cơ chế quyết định không thể sai.

Biến văn bản chính sách lộn xộn thành biểu diễn quy tắc có thể dùng

Tài liệu chính sách viết cho con người: chúng trộn mục tiêu, ngoại lệ và “lẽ thường” trong cùng một đoạn. LLM có thể tóm tắt văn bản đó, nhưng nó sẽ tuân thủ quy tắc đáng tin cậy hơn khi bạn chuyển chính sách thành đầu vào rõ ràng, có thể kiểm thử.

Quy tắc “có thể dùng” trông như thế nào

Biểu diễn quy tắc tốt có hai đặc điểm: chúng không mơ hồ và có thể kiểm tra.

Viết quy tắc như các phát biểu bạn có thể kiểm thử:

• IF/THEN cho quyết định (đủ điều kiện, phân tuyến, phê duyệt)
• MUST / MUST NOT cho các ràng buộc cứng
• MAY cho các tuỳ chọn được phép (thường cần tiêu chí phân xử)

Quy tắc có thể được cung cấp cho mô hình dưới nhiều dạng:

• Gạch đầu dòng ngôn ngữ thường (nhanh, vẫn có cấu trúc)
• Bảng (tốt cho chính sách dựa trên ngưỡng)
• YAML/JSON (tối ưu khi bạn muốn đầu ra bị hạn chế và xác thực tự động)

Xử lý xung đột và độ ưu tiên

Chính sách thực tế mâu thuẫn. Khi hai quy tắc đối nghịch, mô hình cần một cơ chế ưu tiên rõ ràng. Các cách phổ biến:

• Cụ thể hơn thắng chung chung (một ngoại lệ vượt qua mặc định)
• Quyền lực cao hơn thắng (pháp chế/tuân thủ > sở thích đội)
• Mới hơn thắng (phiên bản chính sách mới ghi đè cũ)
• Số ưu tiên tường minh (đáng tin cậy nhất)

Hãy nêu rõ quy tắc xung đột hoặc mã hóa nó (ví dụ priority: 100). Nếu không, LLM có thể “lấy trung bình” các quy tắc.

Ví dụ: biến một đoạn thành danh sách quy tắc

Văn bản chính sách gốc:

“Refunds are available within 30 days for annual plans. Monthly plans are non-refundable after 7 days. If the account shows fraud or excessive chargebacks, do not issue a refund. Enterprise customers need Finance approval for refunds over $5,000.”

Structured rules (YAML):

rules:
  - id: R1
    statement: "IF plan_type = annual AND days_since_purchase <= 30 THEN refund MAY be issued"
    priority: 10
  - id: R2
    statement: "IF plan_type = monthly AND days_since_purchase > 7 THEN refund MUST NOT be issued"
    priority: 20
  - id: R3
    statement: "IF fraud_flag = true OR chargeback_rate = excessive THEN refund MUST NOT be issued"
    priority: 100
  - id: R4
    statement: "IF customer_tier = enterprise AND refund_amount > 5000 THEN finance_approval MUST be obtained"
    priority: 50
conflict_resolution: "Higher priority wins; MUST NOT overrides MAY"

Bây giờ mô hình không đoán cái gì quan trọng — nó đang áp dụng bộ quy tắc mà bạn có thể xem xét, kiểm thử và version.

Theo dõi trạng thái luồng công việc để mô hình luôn nhất quán

Luồng công việc không chỉ là một tập hợp quy tắc; nó là một chuỗi sự kiện nơi các bước trước thay đổi những gì nên xảy ra tiếp theo. “Bộ nhớ” đó là trạng thái: các sự kiện hiện tại về trường hợp (ai đã gửi gì, cái gì đã được phê duyệt, cái gì đang chờ, và hạn chót nào áp dụng). Nếu bạn không theo dõi trạng thái một cách tường minh, luồng công việc sẽ hỏng theo những cách dễ đoán — phê duyệt trùng lặp, bỏ qua kiểm tra cần thiết, đảo quyết định, hoặc áp dụng chính sách sai vì mô hình không thể suy diễn chính xác những gì đã xảy ra.

“Trạng thái” nghĩa là gì bằng tiếng thường

Hãy nghĩ trạng thái như bảng điểm của luồng công việc. Nó trả lời: Chúng ta đang ở đâu bây giờ? Những gì đã làm? Những gì được phép tiếp theo? Với một bản tóm tắt trạng thái rõ ràng, LLM sẽ không mở lại các bước đã xong hoặc phỏng đoán.

Cách truyền trạng thái cho mô hình

Khi gọi mô hình, bao gồm một payload trạng thái ngắn gọn cùng với yêu cầu của người dùng. Các trường hữu ích:

• Tên bước và trạng thái (ví dụ manager_review: approved, finance_review: pending)
• ID ổn định (request ID, employee ID) để mô hình không trộn các trường hợp
• Dấu thời gian (submitted at, last updated) để giải quyết tình huống “mới hơn thắng”
• Cờ (ngoại lệ chính sách, thiếu tài liệu, cần chuyển xử lý)

Tránh nhét mọi tin nhắn lịch sử. Thay vào đó, cung cấp trạng thái hiện tại cộng với một nhật ký kiểm toán ngắn các chuyển đổi chính.

Giữ một nguồn sự thật duy nhất

Xem hệ thống điều phối luồng (cơ sở dữ liệu, hệ thống ticket, hoặc orchestrator) là nguồn sự thật duy nhất. LLM nên đọc trạng thái từ hệ thống đó và đề xuất hành động tiếp theo, nhưng hệ thống mới là thẩm quyền ghi lại các chuyển đổi. Điều này giảm sự “trôi trạng thái”, nơi câu chuyện của mô hình lệch khỏi thực tế.

Ví dụ: snapshot trạng thái luồng phê duyệt

{
  "request_id": "TRV-10482",
  "workflow": "travel_reimbursement_v3",
  "current_step": "finance_review",
  "step_status": {
    "submission": "complete",
    "manager_review": "approved",
    "finance_review": "pending",
    "payment": "not_started"
  },
  "actors": {
    "employee_id": "E-2291",
    "manager_id": "M-104",
    "finance_queue": "FIN-AP"
  },
  "amount": 842.15,
  "currency": "USD",
  "submitted_at": "2025-12-12T14:03:22Z",
  "last_state_update": "2025-12-13T09:18:05Z",
  "flags": {
    "receipt_missing": false,
    "policy_exception_requested": true,
    "needs_escalation": false
  }
}

Với snapshot như thế này, mô hình có thể giữ nhất quán: nó sẽ không hỏi lại phê duyệt của quản lý, sẽ tập trung vào kiểm tra tài chính và có thể giải thích quyết định theo các cờ và bước hiện tại.

Mẫu prompt cải thiện tuân thủ quy tắc và quyết định

Một prompt tốt không chỉ hỏi câu trả lời — nó đặt kỳ vọng về cách mô hình nên áp dụng quy tắc và cách nó nên báo cáo kết quả. Mục tiêu là quyết định có thể lặp lại, không phải văn phong sáng tạo.

1) Role prompting: giao một công việc cụ thể, không là cảm xúc

Hãy cho mô hình một vai trò cụ thể gắn với quy trình của bạn. Ba vai trò hoạt động tốt cùng nhau:

• Policy analyst: diễn giải văn bản quy tắc và ánh xạ vào trường hợp hiện tại.
• Validator: kiểm tra quyết định so với yêu cầu và đánh dấu đầu vào thiếu.
• Agent: thực hiện hành động tiếp theo trong luồng (tạo ticket, soạn email, đặt trạng thái).

Bạn có thể chạy tuần tự (“analyst → validator → agent”) hoặc yêu cầu cả ba đầu ra trong một phản hồi có cấu trúc.

2) Hướng dẫn từng bước (không yêu cầu suy luận ẩn)

Thay vì yêu cầu “chain-of-thought,” hãy chỉ định các bước và sản phẩm hiển nhiên:

1. Xác định quy tắc liên quan.
2. Trích xuất đầu vào cần thiết từ trường hợp.
3. Áp dụng quy tắc theo thứ tự ưu tiên.
4. Đưa ra quyết định và bước tiếp theo.

Điều này giúp mô hình có tổ chức mà vẫn tập trung vào sản phẩm: quy tắc nào được dùng và kết quả là gì.

3) Yêu cầu luận cứ có cấu trúc: id quy tắc + bằng chứng

Giải thích tự do rất dễ chệch hướng. Yêu cầu một luận cứ ngắn gọn trỏ tới nguồn:

• ID quy tắc sử dụng (ví dụ R-12, R-18)
• Bằng chứng (trích dẫn đoạn văn bản từ chính sách và trường hợp cụ thể)
• Giả định (chỉ khi một đầu vào thiếu)

Điều đó giúp việc xem xét nhanh hơn và gỡ lỗi khi có bất đồng.

4) Mẫu checklist: đầu vào, quyết định, ngoại lệ, bước tiếp theo

Sử dụng một mẫu cố định mỗi lần:

• Inputs received: …
• Inputs missing: …
• Decision: approve/deny/needs-review
• Rule references: [R-…]
• Exceptions considered: …
• Next workflow step: update status / request info / escalate

Mẫu giảm mơ hồ và thúc đẩy mô hình hiển thị các khoảng trống trước khi cam kết vào hành động không chính xác.

Dùng công cụ và truy xuất để căn cứ quyết định vào dữ liệu thực

LLM có thể viết câu trả lời thuyết phục ngay cả khi thiếu dữ kiện quan trọng. Điều đó hữu ích để phác thảo, nhưng rủi ro cho quyết định nghiệp vụ. Nếu mô hình phải phỏng đoán trạng thái tài khoản, hạng khách hàng, thuế vùng, hoặc giới hạn đã đạt, bạn sẽ nhận được lỗi có vẻ tự tin.

Công cụ giải quyết điều đó bằng cách biến “suy luận” thành hai bước: lấy bằng chứng trước, quyết định sau.

Công cụ thường dùng giữ mô hình trung thực

Trong hệ thống nặng về quy tắc và luồng công việc, vài công cụ đơn giản làm hầu hết công việc:

• Tra cứu cơ sở dữ liệu (hồ sơ khách hàng, trạng thái tài khoản, quyền lợi, tổng dùng)
• Kho chính sách/quy tắc (văn bản quy tắc được phê duyệt, procedure có version, danh sách ngoại lệ)
• Máy tính (phí, tính tỷ lệ theo thời gian, thuế, ngưỡng)
• API ticket/luồng (vụ việc mở, bộ đếm SLA, phê duyệt, hoàn thành bước)

Chìa khóa là mô hình không “bịa ra” dữ kiện vận hành — nó yêu cầu chúng.

Truy xuất: chỉ mang về các quy tắc liên quan

Ngay cả khi bạn để mọi chính sách trong kho trung tâm, bạn hiếm khi muốn dán toàn bộ vào prompt. Truy xuất chọn lọc chỉ các đoạn phù hợp cho trường hợp hiện tại, ví dụ:

• Chính sách hủy cho gói của khách
• Điều khoản tuân thủ theo quốc gia/tiểu bang
• Quy tắc ngoại lệ khi có chargeback

Điều này giảm mâu thuẫn và ngăn mô hình theo một quy tắc lỗi thời chỉ vì nó xuất hiện trước đó trong ngữ cảnh.

Biến đầu ra công cụ thành bằng chứng cho quyết định

Một mẫu đáng tin là coi kết quả công cụ như bằng chứng mà mô hình phải trích dẫn trong quyết định. Ví dụ:

1. Công cụ: get_account(account_id) → status="past_due", plan="Business", usage_this_month=12000
2. Công cụ: retrieve_policies(query="overage fee Business plan") → trả về quy tắc: “Overage fee applies above 10,000 units at $0.02/unit.”
3. Công cụ: calculate_overage(usage=12000, threshold=10000, rate=0.02) → $40.00

Giờ quyết định không phải đoán: đó là kết luận được neo vào các đầu vào cụ thể (“past_due”, “12,000 units”, “$0.02/unit”). Nếu sau này bạn kiểm toán kết quả, bạn có thể thấy chính xác dữ kiện và phiên bản quy tắc nào được dùng — và sửa phần tương ứng khi thay đổi.

Đầu ra bị hạn chế: schema giảm mơ hồ

Văn bản tự do linh hoạt, nhưng cũng là cách dễ khiến luồng công việc hỏng. Mô hình có thể cho một câu trả lời “hợp lý” nhưng không thể tự động hoá (“nghe có vẻ ổn với tôi”) hoặc không nhất quán giữa các bước (“approve” vs. “approved”). Đầu ra bị hạn chế giải quyết điều này bằng cách ép mọi quyết định vào một dạng dự đoán được.

Trả về quyết định dưới dạng JSON

Một mẫu thực tế là yêu cầu mô hình trả về một đối tượng JSON duy nhất mà hệ thống bạn có thể parse và điều phối:

{
  "decision": "needs_review",
  "reasons": [
    "Applicant provided proof of income, but the document is expired"
  ],
  "next_action": "request_updated_document",
  "missing_info": [
    "Income statement dated within the last 90 days"
  ],
  "assumptions": [
    "Applicant name matches across documents"
  ]
}

Cấu trúc này khiến đầu ra hữu ích ngay cả khi mô hình không thể quyết định hoàn toàn. missing_info và assumptions biến sự không chắc chắn thành các bước tiếp theo có thể hành động, thay vì phỏng đoán ẩn.

Dùng enumerations để giới hạn kết quả

Để giảm biến thể, định nghĩa các giá trị cho phép (enum) cho các trường chính. Ví dụ:

• decision: approved | denied | needs_review
• next_action: approve_case | deny_case | request_more_info | escalate_to_human

Với enum, hệ thống phía dưới không cần dịch các từ đồng nghĩa, dấu câu hay giọng điệu. Nó chỉ phân nhánh theo các giá trị đã biết.

Tại sao schema khiến luồng an toàn hơn

Schema hoạt như lan can bảo vệ. Chúng:

• Ngăn các “câu trả lời một phần” bằng cách bắt buộc các trường cần thiết.
• Giúp kiểm toán dễ hiểu lý do ra quyết định (qua reasons).
• Cho phép tự động hoá đáng tin cậy: hàng đợi, thông báo và tạo tác vụ có thể kích hoạt trực tiếp từ decision và next_action.
• Hỗ trợ xác thực: bạn có thể từ chối đầu ra không khớp schema và yêu cầu mô hình thử lại.

Kết quả là bớt mơ hồ, ít lỗi biên và các quyết định đi qua luồng công việc một cách nhất quán.

Chiến lược xác thực: bắt lỗi trước khi phát hành

Ngay cả một prompt tốt vẫn có thể “nghe hợp lý” trong khi lặng lẽ vi phạm quy tắc, bỏ bước bắt buộc hoặc bịa ra một giá trị. Xác thực là tấm lưới an toàn biến câu trả lời có vẻ hợp lý thành quyết định đáng tin cậy.

Kiểm tra trước: xác thực đầu vào trước khi suy luận

Bắt đầu bằng việc đảm bảo bạn có thông tin tối thiểu cần thiết để áp quy tắc. Kiểm tra trước nên chạy trước khi mô hình đưa ra quyết định.

Kiểm tra điển hình bao gồm các trường bắt buộc (ví dụ loại khách, tổng đơn, vùng), định dạng cơ bản (ngày, ID, tiền tệ) và phạm vi cho phép (số không âm, phần trăm tối đa 100%). Nếu cái gì đó sai, trả về lỗi rõ ràng và có thể hành động (“Thiếu 'region'; không thể chọn bộ luật thuế”) thay vì để mô hình phỏng đoán.

Kiểm tra sau: xác thực quyết định so với quy tắc

Sau khi mô hình đưa ra kết quả, kiểm tra xem nó có nhất quán với bộ quy tắc hay không.

Tập trung vào:

• Phủ kín quy tắc: Quyết định có trích dẫn hoặc ánh xạ tới các quy tắc áp dụng không, hay nó bỏ qua chính sách bắt buộc?
• Kiểm tra mâu thuẫn: Đầu ra có xung đột với đầu vào đã nêu không (ví dụ, “approved” trong khi điều kiện chặn là true)?
• Các trường hợp biên: Kiểm thử ngưỡng như (chính xác $10,000), trạng thái rỗng (“no prior violations”), và các kịch bản “vừa vượt”

Xác thực lần hai: bước rà soát có chủ đích

Thêm một “lần chạy thứ hai” đánh giá lại câu trả lời đầu. Có thể là một lần gọi mô hình khác hoặc cùng mô hình với prompt kiểu validator chỉ kiểm tra tuân thủ, không sáng tạo.

Một mẫu đơn giản: lần đầu sản xuất quyết định + luận cứ; lần hai trả về valid hoặc danh sách cấu trúc các lỗi (thiếu trường, vi phạm ràng buộc, giải thích quy tắc mơ hồ).

Ghi log: làm cho quyết định có thể kiểm toán

Với mỗi quyết định, ghi lại các đầu vào được dùng, phiên bản quy tắc/chính sách, và kết quả xác thực (bao gồm phát hiện lần hai). Khi có vấn đề, điều này cho phép tái tạo chính xác điều kiện, sửa ánh xạ quy tắc và xác nhận sửa — mà không cần đoán mô hình “nghĩ gì.”

Kiểm thử và giám sát độ tin cậy quy tắc và luồng công việc

Kiểm thử các tính năng LLM dựa trên quy tắc/luồng công việc ít là “nó có sinh ra gì không?” mà là “nó có đưa ra cùng một quyết định mà một người thận trọng sẽ đưa ra, vì đúng lý do, mọi lần không?” Tin tốt: bạn có thể kiểm thử nó với cùng kỷ luật như logic quyết định truyền thống.

Unit test cho quy tắc nghiệp vụ (kiểm tra nhỏ, dự đoán được)

Coi mỗi quy tắc như một hàm: với các đầu vào, nó phải trả về kết quả mà bạn có thể khẳng định.

Ví dụ, với quy tắc hoàn tiền “hoàn trong 30 ngày cho món chưa mở,” viết các trường hợp cụ thể với kết quả mong đợi:

• Tuổi đơn = 10 ngày, chưa mở = true → approve
• Tuổi đơn = 10 ngày, chưa mở = false → deny
• Tuổi đơn = 45 ngày, chưa mở = true → deny
• Trường hợp biên: đúng 30 ngày, trường 'unopened' thiếu, tín hiệu mâu thuẫn

Các unit test này bắt lỗi lệch một đơn vị, trường thiếu và hành vi “hỗ trợ” của mô hình khi cố gắng điền vào chỗ trống.

Kiểm thử kịch bản cho luồng công việc (nhiều bước, theo thời gian)

Luồng công việc hỏng khi trạng thái không nhất quán giữa các bước. Kiểm thử kịch bản mô phỏng hành trình thực:

• Kiểm tra đường đi: gửi yêu cầu → yêu cầu tài liệu → tài liệu nhận → quyết định
• Cạnh theo thời gian: “nếu không phản hồi sau 7 ngày, gửi nhắc,” “nếu 30 ngày trôi qua, đóng case”
• Phân nhánh: khách hàng khiếu nại, yêu cầu ngoại lệ chính sách, phát hiện case trùng

Mục tiêu là xác minh mô hình tôn trọng trạng thái hiện tại và chỉ thực hiện các chuyển tiếp cho phép.

Xây một “gold set” các trường hợp đã biết

Tạo bộ dữ liệu tuyển chọn các ví dụ thực, ẩn danh với kết quả đã đồng thuận (và luận cứ ngắn). Giữ nó có phiên bản và xem lại mỗi khi chính sách thay đổi. Một gold set nhỏ (100–500 trường hợp) rất mạnh vì nó phản ánh thực tế lộn xộn — dữ liệu thiếu, cách diễn đạt khác nhau, quyết định lằn ranh.

Giám sát khi vận hành (phát hiện drift trước khách hàng)

Theo dõi phân phối quyết định và tín hiệu chất lượng theo thời gian:

• Drift: tỷ lệ chấp thuận/từ chối thay đổi mà không có cập nhật chính sách
• Tăng đột biến ở needs_review hoặc chuyển lên người (thường do prompt, truy xuất, hoặc dữ liệu đầu vào lỗi)
• Cụm lỗi theo sản phẩm, vùng hoặc loại chính sách

Kết hợp giám sát với rollback an toàn: giữ prompt/bộ quy tắc cũ, gắn feature flag cho phiên bản mới và sẵn sàng quay lui khi số liệu xấu đi. Cho sách hướng dẫn vận hành và kiểm soát phát hành, xem /blog/validation-strategies.

Koder.ai phù hợp ở đâu trong pipeline này

Nếu bạn thực hiện các mẫu ở trên, thường bạn sẽ xây một hệ thống nhỏ xung quanh mô hình: lưu trạng thái, gọi công cụ, truy xuất, xác thực schema và điều phối luồng. Koder.ai là một cách thực tế để prototype và triển khai kiểu trợ lý có luồng công việc đó nhanh hơn: bạn mô tả luồng trong chat, sinh một web app hoạt động (React) cùng các dịch vụ backend (Go với PostgreSQL), và lặp an toàn bằng snapshots và rollback.

Điều này quan trọng cho suy luận quy tắc nghiệp vụ vì các “lan can” thường nằm trong ứng dụng, không phải trong prompt:

• Planning mode giúp thiết kế luồng (các trạng thái, chuyển tiếp cho phép, đường xử lý) trước khi thực thi.
• Đầu ra bị ràng buộc theo schema có thể được cưỡng chế ở rìa API, nên bạn chỉ chấp nhận các quyết định có thể parse.
• Các móc công cụ (đọc DB, truy xuất chính sách, máy tính, cập nhật ticket) được triển khai như các endpoint rõ ràng, biến “lấy bằng chứng trước, quyết định sau” thành mặc định.
• Xuất mã nguồn giúp bạn không bị khóa khi prototype trở thành mission-critical.

Giới hạn, sử dụng an toàn và khi nào cần giữ con người trong vòng lặp

LLM có thể rất tốt trong áp dụng các chính sách hàng ngày, nhưng không tương đương một engine quy tắc xác định. Hãy đối xử với chúng như trợ lý quyết định cần lan can, không phải quyền lực cuối cùng.

Những điểm LLM hay gặp khó

Ba chế độ lỗi thường xuất hiện trong luồng nặng quy tắc:

• Ngoại lệ hiếm và trường hợp biên: Nếu một ngoại lệ xảy ra một năm một lần, nó có thể ít đại diện trong dữ liệu huấn luyện và dễ bị bỏ sót trừ khi bạn cung cấp rõ trong prompt hoặc truy xuất từ tài liệu chính sách.
• Ngữ cảnh dài và ràng buộc “chôn sâu”: Khi chi tiết quan trọng rải rác khắp nhiều trang hoặc tin nhắn, mô hình có thể đánh trọng số quá cao vào văn bản gần nhất hoặc sống động nhất và bỏ áp dụng các ràng buộc trước đó.
• Độ chính xác số học và tính toán chặt: Tổng, chia tỷ lệ, ngưỡng và quy tắc làm tròn có thể sai lệch. Dùng công cụ cho toán và yêu cầu mô hình trích dẫn các con số chính xác nó đã dùng.

Khi nào yêu cầu rà soát bởi con người

Thêm rà soát bắt buộc khi:

• Kết quả có rủi ro cao (chuyển tiền, tuân thủ, an toàn, cam kết pháp lý, tín dụng/đủ điều kiện khách hàng).
• Mô hình báo tự tin thấp (nó hỏi để phỏng đoán đầu vào thiếu, không tìm thấy cơ sở chính sách, hoặc đưa ra lập luận mâu thuẫn).
• Trường hợp mới (sản phẩm mới, vùng mới, chính sách mới được thay đổi) hoặc nhạy cảm bất thường.

Đường xử lý khi cần chuyển tiếp để công việc vẫn tiến

Thay vì để mô hình “sáng tạo ra” điều gì đó, định nghĩa các bước tiếp theo rõ ràng:

1. Hỏi câu làm rõ (ngày, hạng khách, khu vực pháp lý, trạng thái phê duyệt).
2. Chuyển cho nhân viên cùng các dữ kiện trích xuất, quyết định đề xuất và trích dẫn.
3. Tạo ticket khi chính sách mơ hồ hoặc mâu thuẫn, để sửa tại nguồn (và sau đó có thể truy xuất tự động).

Một khung triển khai đơn giản

Dùng LLM trong luồng nặng quy tắc khi bạn có thể trả lời “có” cho hầu hết các câu sau:

• Chúng ta có thể neo quyết định vào văn bản chính sách đã phê duyệt hoặc dữ liệu hệ thống không?
• Chúng ta có thể hạn chế đầu ra (schema, hành động cho phép, trích dẫn bắt buộc)?
• Chúng ta có thể xác thực (kiểm tra, ngưỡng, unit test, lấy mẫu) trước khi thực thi?
• Chúng ta có đường chuyển tiếp con người cho các trường hợp rủi ro hoặc không chắc chắn?

Nếu không, hãy giữ LLM ở vai trò nháp/trợ lý cho đến khi các kiểm soát đó tồn tại.