Title Page

Performance Review - Checker Cert v3.26.2

Mục đích

Đánh giá hiệu năng thực tế của Checker Cert v3.26.2, xác định điểm lỗi và nhóm rủi ro để định hướng phạm vi tự động hóa phù hợp.

Cohort v3.26.21,200cert trong card 9627; 1,199 đã có quyết định
Độ phủ cert71.7%1,199/1,672 cert population
Ops duyệt55.9%670/1,199 cert đã có quyết định
Ops từ chối44.1%529/1,199 cert đã có quyết định
Đơn vị đếm. OA = một tài khoản · cert = một lần hồ sơ được nộp và xét (đơn vị mặc định của mọi bảng) · run = một lần checker quét, một cert có thể có nhiều run.
Sáu mẫu số phụ.
  • 1,202 cert OA Logs sau dedupe
  • 1,182 cert Debug Trace
  • 525 cert reject có taxonomy
  • 1,672 cert population
  • 1,024 OA
  • 1,046 cert docType=1A / 606 lượt

Mỗi trang ghi mẫu số của chính nó ở footer.

Ba định nghĩa phải đọc trước.
  • A0 là nhóm lỗi kỹ thuật, nằm ngoài trục rủi ro A1 < A2 < A3.
  • A2 là tuyến human review có chủ đích, không phải nhóm sai.
  • Dấu ★ nghĩa là khoảng tin cậy 95% (tính theo phương pháp Wilson score interval — phù hợp cho tỷ lệ nhị phân trên mẫu nhỏ/vừa, chính xác hơn công thức chuẩn thông thường) không chồng lấn với nhóm đối chiếu — đây là mô tả vị trí khoảng, không phải kết quả kiểm định thống kê.
Đơn vị tínhcert và OA — mẫu số chính 1,200 cert cohort / 1,199 cert đã có quyết định. Đơn vị đếm: OA/cert/run — xem ghi chú.
Kỳ tính17–25/08/2026
Nguồn20260826_OA Logs.csvcard 9627card 965620260826_OA Debug Trace_1608-2508.xlsxcheckers.jsbackground.js

Executive Summary

Checker đang phân tách rủi ro đến đâu, và còn thiếu gì để tự động hóa?

Mục đích

Tóm tắt các đánh giá chính của báo cáo — không bao gồm đề xuất hành động, xem đề xuất ở Trang 13.

Ba câu hỏi cốt lõi

1 · Checker có thực sự phân tách được rủi ro không?

  • Trang 3 — Cohort phân bố thế nào theo docType, biz_type và cateName?
  • Trang 4 — Cert phân bố thực tế vào bốn nhóm Result (AI) ra sao, Checker phủ được bao nhiêu phần khối lượng duyệt, và Ops approve/reject thế nào trong từng nhóm?
  • Trang 5 — Nộp lần đầu và nộp lại rơi vào nhóm nào, và tỉ lệ được duyệt khác nhau ra sao?
1 · Approval Rate có sự phân hoá69.7→25.7%theo trục A1→A3
2 · Ranh giới còn mờ30.3/25.7%A1 vẫn bị từ chối / A3 vẫn được duyệt

2 · Checker Rules đang cảnh báo lỗi gì nhiều nhất và có đáng tin cậy không? Lỗi Cert bị từ chối (thật sự) nhiều nhất là gì?

  • Trang 6 — Cert bị Ops reject phân bố thế nào theo main_desc, Type và ba cấp taxonomy?
  • Trang 7 + 8 — Với hồ sơ nộp GPKD (Bộ 1A), lỗi tập trung ở đâu, và lỗi nào lọt vào nhóm checker kết luận đạt?
  • Trang 9 — Mục kiểm nào áp đảo về số lượng cờ — và có đáng tin không?
  • Trang 10 — Nơi Checker gắn cờ có thật sự trùng với nơi Ops từ chối? (điều tra sâu L4.1)
3 · Cảnh báo lớn nhất: L4.141.5%gấp 2.7 lần mục đứng thứ hai (653/1,575 cert cờ vàng, card 9656)

3 · Dữ liệu hiện có đủ để tự động hóa không, và bước tiếp theo là gì?

  • Trang 11 — Trung vị thời gian chờ quan sát khác nhau ra sao giữa trong/ngoài giờ, theo thứ và theo A0–A3?
  • Trang 12 — Dữ liệu kỳ này cho phép kết luận gì về khả năng dùng Checker để giảm kiểm duyệt thủ công?
  • Trang 13 — Lộ trình cải thiện nào giảm được kiểm duyệt thủ công, xếp theo mức nỗ lực?
Đơn vị tínhcert — xem mẫu số chi tiết tại từng trang gốc được trích dẫn
Kỳ tính17–25/08/2026
Nguồntổng hợp toàn báo cáo

Demographic

Đối chiếu đặc điểm OA theo cateName và biz_type, đặc điểm cert theo docType

Mục đích

Mô tả thành phần cohort trước khi diễn giải kết quả Checker.

OA distinct1,024mẫu số cateName/biz_type
Cert distinct1,200mẫu số cho docType
docType 1A87.2%1,046/1,200 cert GPKD
Top-5 cateName47.9%490/1,024 OA, còn lại rải rác 17 nhóm
Chi tiết docType và biz_type × certified

docType (cert)

docTypeCert%
1A1,04687.2%
1B413.4%
2A403.3%
2B70.6%
3A524.3%
3B141.2%
Tổng1,200100%

biz_type × certified (OA)

biz_typecertified=0certified=1Tổng OA% OA (certified=1)
Undefined258673259.3%
TNHH1836137950.1%
HKD1314916220.7%
CTCP1414415820.0%
Tổng3037211,024100%
  • Biz Info chỉ được ghi nhận sau khi cert được duyệt, nên OA có certified=1 mới có dữ liệu đầy đủ để phân loại biz_type. Trong nhóm Undefined, 67 OA có certified=1 vẫn chưa xác định được loại hình; 258 OA có certified=0 bao gồm cả trường hợp chưa có Biz Info.

Top 5 Danh mục của các OA

cateNameOA% của 1,024
Công nghệ & Thiết bị13713.4%
Mua sắm & Bán lẻ13212.9%
Dịch vụ khác868.4%
Giáo dục & Đào tạo807.8%
Thực phẩm & Đồ uống555.4%
Others (17 cate còn lại)53452.1%
Tổng1,024100%
Đơn vị tínhOA và cert — mẫu số 1,024 OA distinct (cateName, biz_type) và 1,200 cert distinct (docType)
Kỳ tính17–25/08/2026
Nguồncard 9627
Key takeaways
  1. docType 1A chiếm 1,046/1,200 cert = 87.2%, nên các đặc tính quan sát của Bộ 1A nhìn chung gần với đặc tính toàn bộ cohort cert, ví dụ cơ cấu lỗi từ chối.
  2. Trong số OA đã certified, TNHH chiếm 50.1%; HKD và CTCP lần lượt chiếm 20.7% và 20.0%, gần tương đương nhau.
  3. Top 5 danh mục phản ánh lựa chọn ngành tại bước đăng ký OA. Nhóm ngành Retail/F&B có tỷ trọng tạo mới đáng chú ý; đặc biệt Mua sắm & Bán lẻ và Công nghệ & Thiết bị có xu hướng đặt tên OA theo sản phẩm/dịch vụ hơn.

Phân bố nhóm & quyết định ops

Tỉ trọng bốn nhóm Result (AI) và khác biệt giữa lần đầu với nộp lại

Mục đích

Đối chiếu kết quả Checker với quyết định Ops trên toàn cohort và theo nhóm lần nộp.

Tỉ trọng478 · 69.7%528 · 50.0%144 · 25.7%49 · 73.5%
A1 QualifiedA2 Human reviewA3 Không đạtA0 Lỗi kỹ thuật

Độ phủ: 71.7% cert (1,199/1,672 population) · 75.4% OA (1,023/1,356). Số trong thanh: cert · % approve của nhóm đó trên toàn cohort 1,199 cert.

Cơ cấu, tỉ lệ approve và chênh lệch giữa hai lần nộp

NhómLần đầuNộp lạiΔ cơ cấuΔ Approve
Cert% cơ cấu% ApproveCert% cơ cấu% Approve
A136340.5%71.9%11538.1%62.6%−2.4pp−9.3pp
A238843.3%51.3%14046.4%46.4%+3.1pp−4.9pp
A310511.7%18.1% ★3912.9%46.2% ★+1.2pp+28.1pp ★
A0414.6%70.7%82.6%87.5%−1.9pp+16.8pp
Tổng897100%56.6%302100%53.6%—−3.0pp
Phân bố order_submit và tỉ lệ approve
order_submitCert% của 1,200Tỉ lệ approve
189874.83%56.6%
222318.58%48.0%
3705.83%68.6%
460.50%83.3% ᵐ
510.08%100.0% ᵐ
720.17%50.0% ᵐ

Dấu ᵐ = nhóm dưới 30 cert; đọc như giả thuyết cần kiểm thêm.

Đơn vị tínhcert · 1,200 phân bố / 1,199 có quyết định; lần đầu và nộp lại xác định bằng order_submit
Kỳ tính17–25/08/2026
Nguồn20260826_OA Logs.csvcard 9627card 9656checkers.js
Key takeaways
  1. A2 là nhóm lớn nhất: 528/1,199 cert = 44.0%; 264/528 = 50.0% bị Ops reject. Đây là tuyến human review theo thiết kế.
  2. A1 chiếm 478/1,199 = 39.9%, nhưng 145/478 = 30.3% cert vẫn bị Ops từ chối; chưa có bằng chứng để tự động approve toàn nhóm.
  3. A3 vẫn được Ops duyệt 37/144 = 25.7%, nên không thể tự động từ chối. Tỉ lệ approve quan sát là 18.1% lần đầu và 46.2% khi nộp lại — chưa kiểm định.
  4. A0 chỉ 49/1,199 = 4.1% và là rổ sự cố kỹ thuật, không nằm trên trục rủi ro A1 < A2 < A3.
  5. Sau hồ sơ bị từ chối, nhìn chung ở (các) lần nộp lại, chưa thấy hồ sơ nộp lại dịch chuyển về nhóm AI tốt hơn: A1 giảm 40.5% → 38.1%, trong khi A2+A3 tăng 55.0% → 59.3%. Đồng thời, khả năng phân tầng của AI suy yếu ở lần nộp lại, nổi bật ở A3 khi tỷ lệ Ops approve tăng từ 18.1% lên 46.2%. Cần bóc tách nguyên nhân giữa OA chưa khắc phục đúng/đủ và Checker chưa nhận diện được hồ sơ đã cải thiện.

Chuyển đổi nhóm qua lần nộp

Từ lần nộp đầu, OA được duyệt hoặc tiếp tục nộp lại như thế nào?

Mục đích

Theo dõi kết quả lần nộp đầu và hai lựa chọn của OA bị từ chối: nộp lại hoặc không nộp lại.

Phễu theo OA distinct: lần 1 có 898 OA; trong 389 OA bị từ chối, 206 nộp lại lần 2 và 183 không nộp lại. Sau lần 2, 72 OA tiếp tục nộp lần 3. Nhóm AI chỉ phủ 130/206 OA ở lần 2 và 28/72 OA ở lần 3.

Đơn vị tínhOA distinct · 898 OA lần 1; 206 OA nộp lần 2; 72 OA nộp lần 3
Kỳ tính17–25/08/2026 cho lần 1; các lần sau mở rộng ngoài kỳ/version
Nguồn20260826_OA Logs.csvcard 9627report_outline_v29.md
Key takeaways
  1. Lần đầu là điểm quyết định lớn nhất: 508/898 OA (56.6%) approve ngay; 389 OA reject, bước vào correction journey.
  2. Drop-off lớn nhất ngay sau reject lần 1: chỉ 206/389 (53.0%) quay lại nộp lần 2; 183/389 (47.0%) không nộp lại — reject lần đầu đi kèm mất OA đáng kể.
  3. Nộp lại có recovery nhưng hạn chế: 86/206 = 41.7% approve ở lần 2, 35/72 = 48.6% ở lần 3. Retry bổ sung 121 OA approve, đưa tích lũy 56.6% → 70.0%.
  4. First-pass success là leverage point lớn nhất: reject lần đầu khiến 47% OA không quay lại → ngăn lỗi trước 1st submission có giá trị hơn tối ưu xử lý sau reject. Gợi ý: nghiên cứu UI/UX Flow Cert mới.
  5. Correction loop chưa cải thiện như kỳ vọng: A1 không tăng sau reject; retry A1/A2 approval thấp hơn lần đầu, chỉ 41.7% approve ở lần 2. Cần kiểm tra reject message có actionable và OA có sửa đúng/đủ.
  6. AI logic cần phân biệt 1st submission và re-submission: A3 đổi 18.1% → 46.2% approve, không nên dùng cùng decision rule cho A3 ở hai stage (Trang 13, mục 3.3).

Lý do ops từ chối

Phân bố lý do reject theo main_desc và ba cấp taxonomy

Mục đích

Mô tả lý do reject theo đúng ba cấp taxonomy và đúng grain.

Cert reject có taxonomy525trên 529 cert bị reject
Lượt cert × main_desc647cert nhiều main_desc đếm ở mỗi nhóm
Lượt cert × reason693grain chi tiết nhất

Lý do từ chối theo Type

TypeLượt% của 647
Cert Doc39961.7%
OA Info15624.1%
Biz Info477.3%
Disable457.0%
Tổng647100%
  • Cert Doc (giấy tờ hồ sơ) chiếm áp đảo, hơn 3/5 tổng lượt, gấp 2.5 lần OA Info (cách trình bày OA — cùng chủ đề L4.1 ở Trang 9–10).

Lý do từ chối theo Type x main_desc

Typemain_descCert%Lượt
Cert DocYTKD16331.0%165
Cert DocGeneral13325.3%134
OA InfoImages8015.2%116
Cert DocDKKD6712.8%67
DisableDisable458.6%45
OA InfoDescriptions438.2%47
OA InfoName336.3%33
Biz InfoBusiness315.9%31
Cert DocXMTH224.2%25
Biz InfoRepresentative (16+1)173.2%17
Cert DocCVXT101.9%10
Cert DocXMGD30.6%3
Cộng dồn647—693
  • 525 cert ≤ 647 lượt cert × main_desc ≤ 693 lượt cert × reason — không cộng dồn thành cert.
  • Lý do từ chối lớn nhất kỳ này là XT_81 — vấn đề tên sản phẩm/dịch vụ.
Đơn vị tínhcert và lượt cert × reason — 525 cert taxonomy match, 647 lượt main_desc/Type, 693 lượt reason
Kỳ tính17–25/08/2026
Nguồn20260826_OA Logs.csvcard 9627card 9656[ZOA-BI] Reason of Cert Rejection.xlsx
Key takeaways
  1. Một cert có nhiều lý do là nghiệp vụ hợp lệ — 101/525 cert có taxonomy match mang từ 2 main_desc trở lên = 19.2%, nên tổng 647 lớn hơn 525 theo thiết kế.
  2. Gộp theo Type: Cert Doc chiếm 399/647 = 61.7% — áp đảo hẳn so với OA Info 24.1%, Biz Info 7.3%, Disable 7.0%. Phần lớn lý do từ chối nằm ở giấy tờ hồ sơ, không phải thông tin OA.
  3. XT_81 là reason có số cert lớn nhất trong 46 reason đã match: 117/525 cert = 22.3%. Đây là điểm ưu tiên để điều tra, không phải bằng chứng Checker đã hoặc chưa bao phủ reason này hay có thể giảm workload.

docType 1A · hồ sơ nộp GPKD

Với hồ sơ nộp GPKD, lỗi tập trung ở đâu và nhóm nào xuất hiện trong A1?

Mục đích

Đọc lý do reject riêng cho nhóm hồ sơ lớn nhất, chéo với bốn nhóm Result (AI).

Cert docType 1A1,04687.2% cohort — hồ sơ nộp GPKD
YTKD ở A145.5%65/143 lượt YTKD nằm ở nhóm checker kết luận đạt

Lý do từ chối Bộ 1A theo Type x main_desc

Typemain_descA1A2A3A0Lượt% của 606
Cert DocYTKD655913614323.6%
Cert DocGeneral168025212320.3%
OA InfoImages325821211318.6%
Cert DocĐKKD14272216410.6%
OA InfoDescriptions102372426.9%
DisableDisable98130305.0%
OA InfoName91290305.0%
Biz InfoBusiness41460244.0% ᵐ
Cert DocXMTH10221152.5% ᵐ
Biz InfoRepresentative05100152.5% ᵐ
Cert DocCVXT221050.8% ᵐ
Cert DocXMGD011020.3% ᵐ
Tổng17129113014606100%

Dấu ᵐ = nhóm dưới 30 lượt, đọc như giả thuyết. Type: Cert Doc 352/606=58.1% · OA Info 185/606=30.5% · Biz Info 39/606=6.4% · Disable 30/606=5.0% (mapping theo card 9656, khớp cách gộp ở Trang 6).

Chi tiết main_desc / sub_desc

main_desc / sub_desc — chi tiết

main_desc / sub_descA1A2A3A0Lượt%
YTKD / SPDV_General55376610417.2%
General / General_Dup1571507312.0%
Images / Avatar, banner20331316711.1%
ĐKKD / ĐKKD_Lack710151335.4%
Descriptions / Descriptions_Brand91632305.0%
Name / Name91290305.0%
General / General_XMGD71570294.8% ᵐ
Images / Avatar, banner_Not related71250244.0% ᵐ
Images / Avatar_Portrait51231213.5% ᵐ
Business / Required Email31250203.3% ᵐ
YTKD / KDDK_Medical31310172.8% ᵐ
ĐKKD / ĐKKD_Lines7910172.8% ᵐ
Disable / Disable_Multiple7710152.5% ᵐ
Representative / Representative_Confirm05100152.5% ᵐ

14 sub_desc từ 15 lượt trở lên. 26 sub_desc còn lại (dưới 15 lượt) cộng dồn 111 lượt = 18.3%, không liệt kê riêng — đáng chú ý nhất trong nhóm này: XMTH_Onwership 14 · Descriptions 12 · General_XMTH 11 · ĐKKD_Unactive 10, còn lại 22 mục mỗi mục ≤6 lượt. Mọi % đọc như giả thuyết.

Đơn vị tínhlượt cert × sub_desc — mẫu số 606 lượt trên 1,046 cert docType=1A (1,046 là toàn bộ cohort 1A gồm cả approve, KHÔNG lọc chỉ cert có reject reason match — khác cách tính 525 ở Trang 6, xem key takeaway)
Kỳ tính17–25/08/2026
Nguồncard 9656card 962720260826_OA Logs.csv
Key takeaways
  1. YTKD là nhóm lỗi duy nhất tập trung ở A1: 65/143 = 45.5% lượt YTKD nằm ở A1. Riêng SPDV_General (tương ứng mã XT_81) có 55/104 = 52.9% lượt ở A1, nhiều hơn A2 (37/104 = 35.6%). Đây là bằng chứng độc lập từ card 9656, khớp phân tích L4.1 dựa trên Debug Trace ở trang 10.
  2. General_Dup gần như vắng mặt ở A1: 1/73 = 1.4% lượt. Đối lập với YTKD — cert mang lỗi trùng lặp hầu như không nằm trong nhóm checker kết luận đạt.
  3. Mẫu số 1,046 ở trang này khác bản chất mẫu số 525 ở Trang 6: 525 = cert reject có match taxonomy (đã lọc chỉ reject); 1,046 = toàn bộ cert docType=1A (gồm cả approve). 606 lượt sub_desc chỉ đến từ phần cert reject trong 1,046 đó — chưa tách riêng được bao nhiêu cert 1A thực sự có reject reason match (con số tương đương "525" nhưng riêng cho 1A chưa được tính).

docType 1A · Nhánh bổ sung & lỗi trùng lặp

Hồ sơ GPKD: nhánh vận hành bổ sung, hành vi nộp lại, và lỗi trùng tên OA/ECN

Mục đích

Hai nhánh phân tích độc lập cho hồ sơ GPKD: (1) đặc điểm OA, tỉ lệ duyệt theo lần nộp và hành vi nộp lại — dùng mẫu số vận hành riêng, không đối chiếu Checker; (2) đối chiếu 4 mã lỗi trùng tên OA/ECN (General/General_Dup) và rule XT_59 — dùng mẫu số card 9656 như Trang 7.

Nhánh phân tích bổ sung về hồ sơ nộp GPKD

Cảnh báo mẫu số. Các bảng dưới đây có tệp mẫu 1,444 cert / 1,216 OA, lấy trực tiếp từ dữ liệu vận hành trên Metabase, không đối chiếu kết quả Checker.

A · Đặc điểm OA nộp hồ sơ GPKD (mẫu số 1,216 OA)

biz_type: TNHH 424 (34.9%) · Undefined 414 (34.0%) · HKD 204 (16.8%) · CTCP 174 (14.3%). Kiểm tổng = 1,216. Nhãn Undefined mang cùng hạn chế đã nêu ở trang 3.
cateName năm nhóm đầu: Công nghệ & Thiết bị 169 · Mua sắm & Bán lẻ 156 · Dịch vụ khác 105 · Giáo dục & Đào tạo 92 · Thực phẩm & Đồ uống 68.

B · Tỉ lệ được duyệt theo thứ tự lần nộp (mẫu số 1,444 cert)

Lần nộpcertDuyệtTừ chối% duyệt
Lần 11,09359050354.0%
Lần 225912313647.5%
Lần 3 trở lên92573562.0%

Kiểm tổng 1,093+259+92 = 1,444. Lần 1 gồm 1 cert được duyệt tự động. Nhóm "lần 3 trở lên" gộp các lần 3–7 để bảo đảm n ≥ 30. Thứ tự lần nộp tính trên toàn bộ lịch sử OA (mọi loại bộ giấy tờ, mọi thời điểm), không phải thứ tự riêng cho hồ sơ GPKD. Chưa kiểm định chênh lệch 54.0% / 47.5% / 62.0%; không suy diễn nhân quả.

Lỗi trùng tên OA hoặc trùng ECN

MãÝ nghĩa ngắnCert distinct
XT_28DN đã có OA xác thực tương tự — tìm & xin thêm quyền quản lý69
XT_30Bộ hồ sơ HKD đã dùng cho OA khác (1 GCN HKD chỉ xác thực 1 OA)11
XT_72Hồ sơ/thông tin đăng ký trùng tài khoản đã xác thực cùng tên10
XT_29Hồ sơ DN đã dùng cho nhiều OA (nhiều sản phẩm/dịch vụ)0
Union 4 mã90

69+11+10+0 = 90 = union → không có overlap giữa 4 mã trong kỳ này (một cert chỉ nhận đúng 1 trong 4 mã dup-type). 90 cert này là tập con của 73 lượt General_Dup + phần còn lại của General ở bảng chi tiết phía trên (grain khác nhau — lượt sub_desc so với cert distinct theo mã, không cộng trực tiếp). Nguồn: Metabase card 9656 qua card__9656 (giữ nguyên business logic gốc).

Phụ lục 1 — Tỉ lệ được duyệt theo loại hình doanh nghiệp (mẫu số 1,444 cert)
biz_typecertDuyệtTừ chối% duyệt
TNHH48937511476.7%
HKD2351746174.0%
CTCP2121446867.9%
Undefined5087743115.2%

Kiểm tổng 489+235+212+508 = 1,444. Undefined có tỉ lệ duyệt thấp vượt trội (15.2% so với 67.9–76.7%) nhưng đây là hệ quả của định nghĩa biến, không phải bằng chứng về chất lượng hồ sơ theo loại hình: phần lớn nhóm này là OA chưa từng được duyệt nên trường loại hình còn trống — xem trang 3.

Phụ lục 2 — XT_59 (ĐKKD_Lack) đối chiếu với checkers.js

Văn bản XT_59: "Quản trị viên vui lòng cung cấp đầy đủ các trang của Giấy chứng nhận đăng ký doanh nghiệp có dấu mộc và chữ ký của cơ quan cấp HOẶC chọn bộ xác thực bằng Công văn xác thực." Rule rules_data.js gán mã này cho cvxt-format (L1.3.B).

Phát hiện — đọc trực tiếp checkers.js. Hàm chkCvxtFormat (dòng 1461–1520) — hàm thật sự kiểm mộc đỏ/chữ ký và độ phủ trang — chỉ được gọi khi docType === 'cvxt' (runPolicyChecks, dòng 2475–2480). Khi nộp thẳng Giấy ĐKKD (docType === 'gpkd' — đúng trường hợp XT_59 đang nói tới), hàm này không chạy. docType được xác định thuần theo tên file (getDocType, dòng 990–995: prefix gpkd_/cvxt_), không phân biệt bản điện tử (PDF gốc) hay ảnh chụp.

Hệ quả: hiện không có bước kiểm tự động nào về độ đủ trang trên path GPKD, dù điện tử hay giấy chụp. Mapping XT_59 ↔ cvxt-format là suy diễn theo tên rule, chưa được người viết checkers.js xác nhận — không dùng để tính coverage/recall của rule đối với XT_59. Chưa có truy vấn Metabase riêng cho tần suất XT_59 trong kỳ.

Đơn vị tínhcert · nhánh vận hành 1,444 cert / 1,216 OA (Metabase, không đối chiếu Checker); lượt cert × sub_desc mẫu số 606/1,046 cho phần General/General_Dup (card 9656, cùng nguồn Trang 7)
Kỳ tính17–25/08/2026
Nguồncard 9656card 962720260826_OA Logs.csvcheckers.jsrules_data.js
Key takeaways
  1. Trong 503 OA (hồ sơ GPKD, nộp lần đầu, bị từ chối, có quyết định trong kỳ; lấy được 500/503 — thiếu 3 do giới hạn phân trang khi truy vấn): 245/500 = 49.0% đã nộp lại, 255/500 = 51.0% chưa nộp lại. Đây là ảnh chụp tại thời điểm truy vấn, có thể đổi nếu chạy lại sau.
  2. Kết quả lần nộp 2: 99/244 = 40.6% được duyệt (244/245 đã có kết quả, 1 đang chờ) — thấp hơn 54.0% của lần nộp đầu (bảng B). So sánh mô tả, không nhân quả.
  3. Thời gian đến lần nộp 2 (n=245): trung vị khoảng 1 ngày, 63.3% nộp lại trong vòng không quá 1 ngày (cùng ngày 41.2% · 1 ngày 22.0%). Lần nộp 2 không giới hạn loại bộ giấy tờ, có thể là bất kỳ loại nào.
  4. A3 nghiêng về lỗi giấy tờ: ĐKKD_Lack 15/33 = 45.5% lượt ở A3 (cao nhất trong bốn nhóm), Representative_Confirm 10/15 = 66.7% lượt ở A3 trong khi A1 không có lượt nào.
  5. ĐKKD là nhóm đặc thù của 1A với 64/606 = 10.6% lượt, chia ba loại khác bản chất: thiếu giấy 33 (51.6% của ĐKKD) · sai ngành nghề 17 (26.6%) · hết hiệu lực 10 (15.6%) · HKD 4 (6.3%). Ba loại đầu cần ba cách xử lý khác nhau.

Cờ theo mục kiểm L-code

Phân bố cờ đỏ, vàng, xám theo 18 mục kiểm

Mục đích

Mô tả trạng thái rule trong Debug Trace mà không nối với taxonomy reject.

Đạt15,673lượt trên 19,036 lượt mục kiểm
Cảnh báo1,5758.3% lượt
Không đạt1,1926.3% lượt
Xám / chờ596573 xám + 23 chờ

Phân bố cờ đỏ

Mục kiểmCert cờ đỏ% của 1,182
L3.2 CCCD NDD khớp20217.1%
L4.2 Không có OA trùng tên / trùng ECN15613.2%
L4.7 Ảnh bìa đúng policy14111.9%
L1.1 Tên NDD (GPKD) khớp tra cứu13111.1%
11 mục kiểm còn lại cộng dồn56247.5%

Mẫu số 1,182 cert. Đơn vị: cert distinct cờ đỏ tại mục kiểm đó (không phải run). Dòng "còn lại" là lượt, không phải cert distinct — 630+562=1,192.

Phân bố cờ vàng

Mục kiểmCert cờ vàng% tổng cảnh báo
L4.1 Tên OA đúng policy65341.5%
L4.2 Nghi trùng tên với OA khác24615.6%
L4.4 Description OA đúng policy23414.9%
L4.5 Description OA ít liên quan DN23114.7%
L1.1 Tên NDD (GPKD) khớp tra cứu795.0%
7 mục kiểm còn lại cộng dồn1328.4%

Cùng mẫu số 1,182 và đơn vị cert với bảng cờ đỏ. Dòng "còn lại" là lượt, không phải cert distinct — tổng 1,575.

Điểm cần chú ý khi đối chiếu hai mức cờ.
  • Chỉ mình L4.1 (kiểm tên OA) tạo ra 653/1,575 = 41.5% tổng số cert bị cảnh báo toàn hệ thống — gấp x2.7 lần mục kiểm đứng thứ hai (L4.2, nghi trùng tên, 15.6%).
  • Nhưng ở mức cờ đỏ — tức khi Checker tự kết luận cert "KHÔNG ĐẠT" — L4.1 hầu như không tự đưa ra kết luận "không đạt" đó: chỉ 2/1,192 = 0.2% trường hợp.
  • → L4.1 gần như chỉ dừng ở mức cảnh báo (cờ vàng), hiếm khi tự nâng lên thành "không đạt" (cờ đỏ).
  • → Gánh nặng thực sự dồn vào bước kiểm duyệt thủ công đọc cảnh báo, không phải vào việc chính rule này tự động kết luận "không đạt" cho hồ sơ.
Ngành nghề đặc thù Y tế - Bugs

L0.3 (computeIndustryRequirement() trong checkers.js, 27 rule định nghĩa trong rules_data.js) là cơ chế tách biệt hoàn toàn khỏi 18 mục kiểm L-code phía trên. Rule chạy regex trên oaName + description + category, không đối chiếu MST/OCR, chỉ cảnh báo và không trừ điểm.

Case phát hiện. Cert 547735, OA “Bếp Mạnh Đạt” thuộc ngành thiết bị bếp, bị rule clinic (XT_33) gắn nhầm nhãn “Phòng khám/Cơ sở y tế” dù không có căn cứ trong dữ liệu đầu vào.

Phân loại 81/110 cert có XT_33 thực sự fire

Kết quả xác minhCertTỉ trọng
oaName/category có căn cứ y tế6377.8%
Không liên quan y tế — false positive xác nhận1619.8%
Không xác minh được22.5%

Ví dụ false positive: 547735 Bếp Mạnh Đạt · 545314 2M Technocom · 545956 Thang Máy Miền Trung · 546820/546913 Lọc nước Thiên Vương; các OA này đều thuộc nhóm Công nghệ & Thiết bị/Sản xuất & Chế tạo. Riêng 545131 “Nhà Thuốc Ngân Anh” là lỗi phân loại chéo: có liên quan y tế nhưng bị rule clinic bắt trước thay vì rule pharmacy.

Giới hạn điều tra. Đã loại trừ hai giả thuyết bằng source code và raw JSON: description lấy thẳng từ API Zalo, không nối thêm danh sách trùng tên; cả ba input của cert 547735 đều sạch và không khớp regex nào. Cơ chế khiến alert vẫn fire chưa xác định được; cần thêm sidepanel.js để kết luận.
Phụ lục — Feedback nhân sự (OA_Feedback.csv) theo mục kiểm

Nguồn 280 dòng feedback trong kỳ (v3.26.2, 17–25/08). Đây là feedback tự nguyện từ 4 người, top-1 chiếm 78.6% và top-3 chiếm 97.5% số dòng — không có mẫu số (không biết mỗi rule được review trên bao nhiêu cert), nên bảng dưới chỉ dùng để chẩn đoán định tính, không xếp hạng rule theo mức lỗi. Mã ở đây là hệ canonical (L4.1.B, L1.3.B) — khác hệ Debug Trace của 2 bảng cờ phía trên, không so trực tiếp số dòng feedback với số cờ.

Mục kiểmSaiCải thiệnTổng
L4.1.B dup-oa11110121
L4.628432
L4.525025
L2.1101525
L1.123124
L3.220020
9 mã còn lại cộng dồn27633
Tổng24436280
L4.1.B (dup-oa) chiếm 121/280 = 43.2% tổng feedback trong kỳ — gấp x4 lần mã đứng thứ hai. Nhánh "Nghi trùng tên với OA khác" có 84 dòng, 75 báo "Sai"; ghi chú phổ biến nhất là "không trùng" (72 lần) — phần lớn feedback là reviewer nói rule báo nhầm trùng tên. → Cần review rule.
Đơn vị tínhlượt mục kiểm và cert — mẫu số 1,182 cert Debug Trace, 19,036 lượt mục kiểm; phụ lục L0.3 xác minh 81/110 cert XT_33; phụ lục feedback 280 dòng (định tính, không xếp hạng rule)
Kỳ tính17–25/08/2026
Nguồn20260826_OA Debug Trace_1608-2508.xlsxcheckers.jsrules_data.jscontent_main.js20260826_OA Feedback.csv
Key takeaways
  1. L4.1 (kiểm tên OA) tạo 653/1,575 = 41.5% tổng cert bị cảnh báo toàn hệ thống — gấp 2.7 lần mục đứng thứ hai. Nhưng gần như không tạo cờ đỏ (2/1,192 = 0.2%): đây là mục kiểm "cảnh báo nhiều, tự chặn ít".
  2. Các mục có số cờ đỏ cao nhất lại khác hẳn: L3.2 202/1,182 cert, L4.2 156/1,182, L4.7 141/1,182 và L1.1 131/1,182. Cờ đỏ và cờ vàng tập trung ở hai nhóm mục kiểm khác nhau.
  3. L4.3 Category OA có 0/1,182 cờ. Output hiện tại không phân biệt được "không có vi phạm" với "rule không phát cờ"; cần evidence ở cấp thực thi để xác nhận.
  4. Mẫu số 1,182 cert của trang này khác 1,199/1,200 (toàn cohort ở các trang khác) — 21 cert bị loại do thiếu bản ghi chi tiết trong Debug Trace hoặc không xác định được dòng đại diện. Mã mục kiểm (L-code) ở đây cũng khác cách đánh số trong checkers.js từ L1.4/L4.2 trở đi — cùng rule, khác số thứ tự.
  5. L4.1.B chiếm 121/280 = 43.2% tổng feedback trong kỳ, x4 lần mã đứng thứ hai. Trong đó nhánh "Nghi trùng tên với OA khác" có 84 dòng, 75 báo "Sai", ghi chú phổ biến nhất là "không trùng" (72 lần) — tức phần lớn feedback là reviewer nói rule báo nhầm trùng tên. Cần review rules.

Đối chiếu cờ với lý do reject

Đối chiếu nơi Checker gắn cờ với nơi ops ghi lý do từ chối

Mục đích

Đối chiếu cờ Checker, kết quả ops và reason ở cấp cert nhưng không biến đồng xuất hiện thành mapping rule ↔ reason.

Tiếp nối trang 9. L4.1 một mình tạo 41.2% tổng cảnh báo hệ thống. Câu hỏi ở trang này: cảnh báo đó có đáng tin không — có thật sự trùng với lý do ops từ chối, hay phần lớn chỉ là nhiễu?

Tỉ lệ duyệt của L4.1 x Nhóm AI

TậpApproveRejectCertTỉ lệ approve
A1 · L4.1 CẢNH BÁO1076016764.1% ★
A1 · L4.1 ĐẠT1232114485.4% ★
A2 · L4.1 CẢNH BÁO9110519646.4%
A2 · L4.1 ĐẠT826514955.8%
Phân rã 8 rule của L4.1 từ prompt

Prompt nằm ở background.js dòng 2046–2086, không có trong checkers.js. Mẫu số 654 cert cohort có lỗi L4.1 (652 vàng + 2 đỏ). Đường xử lý: 649 nhánh AI + 3 regex fallback + 2 cert tên OA rỗng.

RuleNội dungCert% của 649
R9nameMatch — tên OA khác hoàn toàn tên DN52881.4%
R5ALL CAPS — mọi chữ cái (≥4 ký tự) viết hoa12118.6%
R6Title Case sai quy cách, ngưỡng ≥2 từ vi phạm8112.5%
R4Ký tự cảnh báo & @ ( )446.8%
R8Soft flag (số 1, tốt nhất, chính thức, official…)233.5% ᵐ
R2Độ dài dưới 5 hoặc trên 50 ký tự162.5% ᵐ
R9bTên DN không đọc được (ký tự lỗi)10.2% ᵐ
R9cTên OA chứa phần bổ sung không có trong tên DN10.2% ᵐ

ᵐ = dưới 30 cert, % kèm khoảng tin cậy. R1, R3, R7 không bắn lần nào trong kỳ.

Tách hai bản chất. Danh tính 528 cert · trình bày 283 cert · chồng lấn 162 · chỉ trình bày 121 cert (A2 48 · A1 64 · A3 8 · A0 1). Kiểm: 528 + 283 − 162 = 649.

Các mã liên quan Tên OA khác tên DN - ST_02, ST_03, XT_81

MãPhân loại & hướng dẫn nộpCert distinct
ST_03Tên OA là Nhãn hiệu & hướng dẫn nộp cách 219
XT_81Tên OA khác tên DN/HKD & hướng dẫn nộp cách 3: 01 YTKD sản phẩm/dịch vụ174
ST_02Tên OA khác tên DN/HKD & hướng dẫn nộp cách 2 hoặc 345
Tổng (đã loại DUP)218

Tổng 3 lỗi liên quan "Tên OA khác tên Doanh nghiệp" là 218 cert, trên mẫu số 525 cert → 218/525 = 41.5% tổng lỗi reject toàn kỳ.

Lỗi containment R9 của L4.1. Chỉ dẫn cho AI ghi rõ "chấp nhận một bên chứa bên kia", nhưng 78/535 = 14.6% cert có một bên tên nằm trọn trong bên còn lại mà vẫn bị báo không khớp. Ví dụ: "Gọn Barber Studio" so với "Gọn" · "goat media" so với "goat" · "1001 Studio" so với "1001" · "MELI LOGISTICS" so với "MELI" · "HẢI ĐĂNG DUONG" so với "HẢI ĐĂNG DƯƠNG" (chỉ khác dấu thanh điệu). Mẫu hình chung: AI trượt khi tên doanh nghiệp là một từ rất ngắn nằm trong tên OA dài hơn. → Đề xuất chỉnh ở Trang 13.
Chi tiết bổ sung: nhóm nộp lần đầu, phạm vi toàn kỳ, và độ tin cậy hai nhánh xử lý

Trong nhóm 503 cert nộp lần đầu bị từ chối (hồ sơ GPKD): ST_03 13 cert = 2.58% · XT_81 109 cert = 21.67% → gộp lại khoảng 24.3% cert bị từ chối ở lần nộp đầu có liên quan vấn đề tên OA.

Mở rộng ST_03 ra toàn kỳ (bỏ giới hạn loại giấy tờ và lần nộp): 19 cert. Sáu cert chênh lệch ngoài phạm vi: 548344 (loại 1B, lần 1) · 545836 (1B, lần 2) · 548656, 548545, 545503, 547720 (đều hồ sơ GPKD nhưng là lần nộp thứ 2). → Lỗi này lặp lại ở lần nộp lại, không chỉ ở lần đầu.

Đối chiếu 13 cert ST_03 với dữ liệu chi tiết mục kiểm: 9/13 cert có bản ghi, trong đó 8/9 được cảnh báo đúng; 1 cert (545581) chấm đạt vì đi nhánh dự phòng và tính độ giống 100%. 4/13 cert không có bản ghi dù thời điểm quyết định nằm trong phạm vi dữ liệu bao phủ (16/08 09:52 – 25/08 19:19) — không phải lệch kỳ mà là khoảng trống dữ liệu thật, chưa rõ nguyên nhân.

Kiểm độ nhạy ngưỡng ký tự: đổi ngưỡng lọc từ 3 xuống 2 ký tự chỉ làm 2/383 cert dịch chuyển, nhóm 78 cert chứa trọn không đổi → ngưỡng ký tự không phải biến số quan trọng. Hai ca dịch chuyển còn trái ngược nhau: 543979 ("Leading Star AI" so với "Ngôi Sao Dẫn Đầu AI") là khớp thật do dịch nghĩa Anh–Việt; 544099 ("Tủ Bếp Nhôm Kính" so với "Lê Minh Tú") là nhiễu thuần do trùng chữ sau khi bỏ dấu. → Yếu tố quyết định là ý nghĩa của từ trong ngữ cảnh, không phải độ dài ký tự.

Độ tin cậy hai nhánh xử lý: mục kiểm tên OA có nhánh chính dùng AI và nhánh dự phòng dùng thuật toán cố định (chỉ chạy khi AI lỗi). Trên 909 lượt cảnh báo: nhánh AI 899 = 98.9% · nhánh dự phòng 3 = 0.3% · 7 = 0.8% không xác định được. → Nhánh dự phòng rất hiếm, không phải nguyên nhân gây biến động kết quả.

Khoảng trống phân loại mức bảo hộ: đã rà toàn bộ mã nguồn — không có đoạn nào tra cứu cơ sở dữ liệu bảo hộ nhãn hiệu. Cơ chế kiểm thương hiệu duy nhất nằm ở kiểm ảnh đại diện và ảnh bìa (đối chiếu danh sách thương hiệu nổi tiếng cố định), không liên quan mục kiểm tên OA và cũng không tra cứu đăng ký thật. → Phân loại ST_03 so với XT_81 là quyết định thủ công 100% của người kiểm duyệt sau khi Checker đã cảnh báo.

Đơn vị tínhcert distinct và lượt cert × reason — nhiều mẫu số riêng theo từng bảng, xem chi tiết trong thân trang.
Kỳ tính17–25/08/2026
Nguồn20260826_OA Debug Trace_1608-2508.xlsxcard 9656card 9627checkers.jsbackground.js
Key takeaways
  1. Tập 104 cert chỉ có L4.1 CẢNH BÁO bị ops từ chối 45 cert = 43.3%; 27/45 cert reject có XT_81. Đây là candidate guardrail cần kiểm thêm, chưa phải cơ sở đổi màu rule hoặc tự động quyết định.
  2. 78/535 = 14.6% cert bị cảnh báo sai dù hai tên chứa trọn nhau — lỗi containment R9 của L4.1, đề xuất chỉnh ở Trang 13. Chi tiết xem khối "Lỗi containment R9" bên trên.
  3. Nếu chuyển candidate này khỏi A1, tỉ lệ reject của phần A1 còn lại giảm từ 30.3% xuống 26.7%, nhưng 59 cert được approve cũng bị giữ lại cùng 45 cert reject — đánh đổi 1 : 1.31.
  4. A1 · L4.1 CẢNH BÁO approve thấp hơn rõ rệt L4.1 ĐẠT (64.1% so với 85.4%, xem bảng trên) — quan sát mô tả, chưa kiểm định.
  5. Bảng _REJECT_RULES chứa 12 mã trong khi ops dùng 38 mã; độ phủ 161/1,002 = 16.1% lượt cert × reason. Mã vắng không đồng nghĩa Checker không kiểm vấn đề đó.

Thời gian chờ duyệt

Thời gian chờ duyệt theo thời điểm nộp và theo nhóm Result (AI)

Mục đích

Mô tả thời gian chờ quan sát theo thời điểm nộp và nhóm Result (AI).

Nộp trong giờ2.15htrung vị · 838 cert (8:00–17:59 T2–T6)
Nộp ngoài giờ10.47htrung vị · 361 cert
Chênh lệch8.32htrung vị quan sát; chưa kiểm định

Trong giờ vs ngoài giờ

NhómCertTBTrung vị
Nộp trong giờ8383.83h2.15h
Nộp ngoài giờ3618.72h10.47h

838 + 361 = 1,199 = cohort đã có quyết định. p25/p75/Max: xem dữ liệu gốc.

Theo nhóm Result (AI)

Nhóm AICertTBTrung vị
A0495.11h2.17h
A14785.37h2.68h
A25285.22h2.55h
A31445.44h2.46h

Trung vị 2.17h (A0)–2.68h (A1), chênh 31 phút. Thứ tự A1 > A2 > A3 > A0. CHƯA kiểm định.

Đơn vị tínhgiờ (thời gian chờ), tính trên cert — mẫu số 1,199 cert đã có quyết định
Kỳ tính17–25/08/2026
Nguồncard 962720260826_OA Logs.csv
Key takeaways
  1. Chênh lệch trung vị quan sát giữa ngoài giờ và trong giờ là 8.32h trên hai nhóm 361 và 838 cert. Đây là chênh lệch mô tả, chưa kiểm định và không kết luận nguyên nhân.
  2. Trung vị của bốn nhóm nằm trong khoảng 2.17–2.68h, chênh 31 phút; chưa thực hiện kiểm định để kết luận khác biệt thống kê hoặc khả năng dự báo.

Kết luận · Trang 12

Checker đã phân tách được mức độ rủi ro, nhưng chưa tạo được ranh giới quyết định đủ an toàn để tự động hóa

Mục đích

Tổng hợp các kết luận đã có bằng chứng ở trang 3–11 theo ba lớp: tín hiệu Checker đang tạo ra được, nghịch lý còn tồn tại, và những điểm yếu đang cản trở tự động hóa.

1 · TÍN HIỆU

Trên 1,199 cert đã có quyết định, tỉ lệ Ops duyệt giảm dần theo thứ tự nhóm rủi ro:
A1 duyệt 333/478 = 69.7%
A2 duyệt 264/528 = 50.0%
A3 duyệt 37/144 = 25.7%

Checker có khả năng phân tách rủi ro — nhóm được đánh giá tốt hơn thì thực tế được duyệt nhiều hơn.

2 · NGHỊCH LÝ

Nhóm tốt chưa đủ tốt để tự động duyệt: A1 là nhóm Checker kết luận đạt, nhưng 145/478 = 30.3% vẫn bị Ops từ chối.

Nhóm xấu chưa đủ xấu để tự động từ chối: A3 là nhóm Checker kết luận không đạt, nhưng 37/144 = 25.7% vẫn được Ops duyệt.

A2 chia gần đôi: chiếm 44.0% khối lượng, duyệt 50.0% — đây là tuyến kiểm duyệt thủ công có chủ đích, không phải bằng chứng Checker sai.

3 · ĐIỂM YẾU

W1. Ngay cả khi giữ 104 cert A1 chỉ có cảnh báo tên OA ở luồng thủ công, phần A1 còn lại vẫn bị từ chối 100/374 = 26.7%.

W2. Mức trùng giữa cờ Checker và lý do từ chối của Ops chỉ là quan sát, chưa được xác nhận là quan hệ nghiệp vụ.

W3. Một số rule và nguồn dữ liệu chưa đủ truy vết: mục kiểm L4.3 Category OA có 0/1,182 cờ nhưng chưa phân biệt được "không vi phạm" với "rule không phát cờ".

Hàm ý cho quyết định. Ở trạng thái hiện tại, Checker phù hợp hơn với vai trò phân luồng theo rủi ro và hỗ trợ ưu tiên xử lý, hơn là trực tiếp thay thế quyết định của Ops trên toàn bộ A1–A3. Phân tách được rủi ro chưa đồng nghĩa với đủ điều kiện tự động hóa: để bỏ được bước kiểm duyệt thủ công, cần một ranh giới quyết định đủ rõ để biết chắc nhóm nào an toàn.
Các giới hạn cần giữ khi đọc kết quả

· Checker v3.26.2 phủ 1,199/1,672 = 71.7% cert được duyệt trong kỳ và 1,023/1,356 = 75.4% OA. Kết luận về Checker không đại diện cho toàn bộ tập hồ sơ.
· Hồ sơ nộp giấy Đăng ký Kinh doanh (docType=1A) chiếm 1,046/1,200 = 87.2% cert, nên kết luận chủ yếu phản ánh loại hồ sơ này.
· Lần nộp đầu so với nộp lại có tỉ lệ từ chối 43.4% so với 46.4%, nhưng chưa có một chiều khác biệt thống nhất giữa các nhóm A0–A3. Không dùng kết quả này để thay đổi cách xử lý theo lần nộp trước khi ghép được chuỗi nộp của cùng một OA.
· Trung vị thời gian từ lúc nộp đến lúc có quyết định là 2.15 giờ trong giờ làm việc so với 10.47 giờ ngoài giờ — đây là khác biệt mô tả, chưa xác định nguyên nhân.
· XT_81 là lý do từ chối có số cert lớn nhất: 117/525 = 22.3%, nhưng lý do từ chối của Ops và cờ Checker chưa được xác nhận có quan hệ một–một.

Kết luận chính
  1. Checker v3.26.2 đã phân tách được mức độ rủi ro, theo 3 nhóm A1/A2/A3.
  2. Với lần nộp đầu tiên, tỉ lệ approved có sự phân hoá rõ rệt giữa 3 nhóm và có khả năng duyệt tự động. Với các lần nộp lại, sự phân hoá về tỉ lệ approved giảm dần.
  3. Rule L4.1 đang có nhiều lượt cảnh báo. Cần cải thiện rule này để đẩy cert về các nhóm đúng hơn.
Đơn vị tínhcert — mọi kết luận neo vào mẫu số 1,200 cert cohort / 1,199 cert đã có quyết định; mẫu số phụ ghi tại trang gốc
Kỳ tính17–25/08/2026
Nguồntổng hợp trang 3–11

Lộ trình cải thiện · Trang 13

Ba tầng hành động: Quick fixes — thêm rules — thêm quy trình xử lý

Mục đích

Ưu tiên hành động theo nỗ lực, rủi ro và mức độ sẵn sàng.

Tầng 1 - Quick fixes

1.1Điều chỉnh lỗi containment trong R9 của L4.1 — ảnh hưởng 78/535 cert
1.2Điều chỉnh 4 thành phần chuẩn hoá tên (DUP_OA_STOPWORDS, VN_GEO_WORDS, stripOaNameCore, stripCompanyPrefix) và nâng cấp stripCompanyPrefix() thành extractProperName() — ảnh hưởng 24/528 cert
1.3Bỏ kiểm độ dài tên trùng lặp ở R2 của L4.1 vì luồng tạo OA đã kiểm trước Checker
1.4Fix bugs L0.3 (Ngành nghề đặc thù)
1.5Fix bugs trong files Gsheet

Tầng 2 - Thêm rules

2.1Tách lỗi danh tính và trình bày trong L4.1; cho AI tự điều chỉnh lỗi trình bày
2.2Với L4.1 rule R9; bổ sung trademark blocker độc lập để đưa cert có tên trùng với nhãn hiệu đã được bảo hộ ra khỏi A1

TẦNG 3 · Thêm quy trình xử lý - thay đổi lớn

3.1Kết nối CSDL bảo hộ nhãn hiệu (WIPO) để phân loại rủi ro pháp lý; tạo trademark blocker để có vùng an toàn cho L4.1
3.2Đọc và phân biệt hai loại giấy thường gặp: Giấy phép phòng khám; Giấy chứng nhận nhãn hiệu (đã bảo hộ)
3.3Phân biệt certId nộp 1st submission và re-submission trong AI logic — đặc biệt A3 đổi ý nghĩa mạnh giữa hai lần nộp (18.1% → 46.2% approve, xem trang 5), nên không thể áp dụng cùng interpretation/decision rule cho A3 ở hai stage này
Phụ lục Quick fix 1 - Lỗi containment trong R9 của L4.1

Trích oaKey/dnKey của 535 cert có cờ L4.1 và kiểm lại bằng thuật toán chuỗi con độc lập.

Mức trùng lặp thực tếCertTỉ trọngĐánh giá
Chứa trọn nhau nhưng vẫn trả match=false7814.6%Vi phạm chỉ dẫn “chấp nhận một bên chứa bên kia”
Trùng ≥1 token đáng kể, không chứa trọn7413.8%Ranh giới, cần xem từng ca
Không trùng token38371.6%Mismatch cấu trúc

Mẫu hình: core brand rất ngắn nằm trong tên OA dài hơn, ví dụ “Gọn Barber Studio”/“Gọn”, “goat media”/“goat”, “1001 Studio”/“1001”, “MELI LOGISTICS”/“MELI”; hai ca “HẢI ĐĂNG DUONG”/“HẢI ĐĂNG DƯƠNG” chỉ khác dấu thanh điệu. Đổi ngưỡng token từ ≥3 xuống ≥2 ký tự chỉ làm 2/383 cert dịch chuyển và không thay đổi nhóm 78.

Điều chỉnh đề xuất. Dùng lại thuật toán containment deterministic trong checkers.js (dòng 1780–1817, hiện ở nhánh fallback) làm lớp kiểm tra chéo sau nhánh AI. Khi containment chỉ đến từ địa danh, phải dùng danh sách địa danh để loại trừ false match.
Phụ lục Quick fix 2 - Chuẩn hoá tên và enhance stripCompanyPrefix
Vấn đề hiện tại. Logic startsWith(prefix) → slice(prefix.length) giả định loại hình doanh nghiệp là một chuỗi cố định ở đầu tên. Vì vậy “Công ty luật TNHH Thinksmart” bị parse thành luật tnhh thinksmart thay vì tên riêng Thinksmart.

Bốn thành phần chuẩn hoá tên chưa đồng bộ

Thành phần trong checkers.jsHiện trạngKhoảng trống
DUP_OA_STOPWORDSChỉ có 9 dạng địa danh; dùng cho dup-oa qua extractSignalTokensThiếu phần lớn tỉnh/thành và không phục vụ trực tiếp oa-name
VN_GEO_WORDSDanh sách địa danh đầy đủ hơn; dùng ở Rule 6 và nhánh fallbackChưa được tái sử dụng nhất quán khi bóc tên cho R9
stripOaNameCoreBóc 21 tiền tố loại hình kinh doanh ở đầu chuỗiKhông xử lý hậu tố địa danh và không cùng logic với stripCompanyPrefix
stripCompanyPrefixChỉ bóc một danh sách hẹp các tiền tố pháp lý; được gọi ở fallback của R9Không xác định trọn loại hình doanh nghiệp; không xử lý hậu tố địa danh
Phạm vi quan sát. Có 24/528 cert lỗi danh tính mang hậu tố địa danh trong oaKey; bóc địa danh ở cả hai phía làm 0/24 cert tăng mức chứa. Đây là quick fix để đồng bộ cách xử lý, không phải bằng chứng sẽ cải thiện tự động hoá.
Điều chỉnh chung. Dùng một lớp chuẩn hoá có tham số theo từng rule và tái sử dụng VN_GEO_WORDS để nhận diện hậu tố địa danh. Khi kiểm tra containment, phải loại trường hợp phần trùng duy nhất là địa danh để tránh tạo false match.
Định nghĩa cần áp dụng. Tên doanh nghiệp gồm hai thành phần: Loại hình doanh nghiệp + Tên riêng. Cần nhận diện trọn cụm loại hình doanh nghiệp; mọi phần đứng sau cụm này là Tên riêng và được áp dụng quy tắc viết hoa của tên riêng.

Sáu loại hình doanh nghiệp cần nhận diện

Loại hìnhCác dạng marker cần nhận diện
Công ty trách nhiệm hữu hạn một thành viênCông ty TNHH MTV · TNHH MTV · TNHH một thành viên · trách nhiệm hữu hạn một thành viên
Công ty trách nhiệm hữu hạnCông ty TNHH · TNHH · trách nhiệm hữu hạn
Công ty cổ phầnCông ty CP · CTCP · cổ phần
Công ty hợp danhCông ty HD · HD · hợp danh
Doanh nghiệp tư nhânDNTN · doanh nghiệp tư nhân
Doanh nghiệp nhà nướcDNNN · doanh nghiệp nhà nước
Logic mới cho Doanh nghiệp. Với tên bắt đầu bằng “Công ty” hoặc “Cty”, tìm marker pháp lý theo thứ tự dài và cụ thể trước — đặc biệt TNHH MTV trước TNHH. Toàn bộ phần từ đầu tên đến hết marker là Loại hình doanh nghiệp; phần còn lại là Tên riêng.

Ví dụ xác định Tên riêng

Tên doanh nghiệpLoại hình doanh nghiệpTên riêng
Công ty luật TNHH ThinksmartCông ty luật TNHHThinksmart
Công ty TNHH Luật Gia KhangCông ty TNHHLuật Gia Khang

Phân loại chủ thể trước khi trim

Nhóm chủ thểCách xử lý
Doanh nghiệpXác định trọn cụm loại hình → trim đến hết marker → phần còn lại là Tên riêng
Đơn vị phụ thuộc doanh nghiệpChi nhánh / Văn phòng đại diện / Địa điểm kinh doanh dùng parser riêng vì tên có thể chứa đầy đủ tên doanh nghiệp mẹ
Các tổ chức khácRule riêng cho Hộ kinh doanh; VPĐD doanh nghiệp nước ngoài tại Việt Nam; Trường công lập có Quyết định thành lập; Tổ chức phi chính phủ; Đơn vị sự nghiệp công lập; Hiệp hội; Hợp tác xã
Ràng buộc. Không gộp đơn vị phụ thuộc hoặc các tổ chức khác vào sáu marker doanh nghiệp. Ví dụ “CHI NHÁNH CÔNG TY TNHH ABC TẠI HÀ NỘI” không thể chỉ tìm TNHH rồi trả về “ABC TẠI HÀ NỘI”, vì có thể xác định sai tên riêng của chủ thể đăng ký.
Concept đề xuất. Đổi stripCompanyPrefix() thành extractProperName(): input là tên pháp lý; phân loại chủ thể trước, sau đó áp dụng logic marker doanh nghiệp hoặc parser riêng theo loại chủ thể; output là Tên riêng. Không tiếp tục mở rộng mảng prefix cố định.
Phụ lục Quick fix 3 - Bugs L0.3 và files Gsheet
Hạng mụcĐiều chỉnhBằng chứng hiện cóXử lý
Fix bugs L0.3Sửa rule ngành nghề đặc thù để tránh rule clinic bắt sai hoặc cướp match từ pharmacy.16/81 = 19.8% false positive xác nhận; chi tiết tại phụ lục Trang 9.Kiểm lại thứ tự rule và dữ liệu đầu vào trước khi phát cảnh báo.
Fix bugs trong files GsheetSửa thao tác cập nhật thông tin tài khoản OA khi Ops duyệt Approve nhưng dữ liệu sau đó không được cập nhật.Chưa có mẫu số định lượng trong report.Bổ sung log xác nhận ghi thành công và cơ chế retry/đối soát.
Chi tiết Tầng 2 - Thêm rules
Hạng mụcĐiều chỉnhBằng chứng hiện cóXử lý
Tách danh tính và trình bày trong L4.1Tách hai tín hiệu: danh tính gồm R9, R9b, R9c; trình bày gồm R2, R4, R5, R6, R8. Với lỗi chỉ thuộc nhóm trình bày, cho AI hướng dẫn OA tự điều chỉnh.Danh tính 528 cert · trình bày 283 · cả hai 162 · chỉ trình bày 121: A2=48 · A1=64 · A3=8 · A0=1.Lỗi danh tính chuyển kiểm duyệt; lỗi chỉ trình bày đi luồng tự sửa.
Trademark blocker độc lập cho L4.1 rule R9Giữ kết quả khớp tên tách biệt với trạng thái bảo hộ. Bổ sung một blocker độc lập để nhận diện trường hợp tên OA trùng với nhãn hiệu đã được bảo hộ.R9 hiện chỉ phát hiện khác biệt tên và chưa tra cứu CSDL bảo hộ; trạng thái bảo hộ vẫn cần nguồn xác nhận riêng.Đưa cert có tên trùng với nhãn hiệu đã được bảo hộ ra khỏi A1; chuyển sang luồng kiểm duyệt phù hợp.

Bằng chứng chi tiết - Tách lỗi danh tính và trình bày trong L4.1

Danh tính

R9 · R9b · R9c
528 cert

Trình bày

R2 · R4 · R5 · R6 · R8
283 cert

162 cert mắc cả hai nhóm. 121 cert chỉ có lỗi trình bày, gồm A2=48 · A1=64 · A3=8 · A0=1. Đây là quy mô ứng viên cho luồng AI tự hướng dẫn sửa cách trình bày, không phải số cert đã chứng minh có thể tự động hoá.

Luồng đề xuất. Lỗi chỉ thuộc nhóm trình bày → AI hướng dẫn OA tự sửa. Với L4.1 rule R9, giữ phép so khớp tên tách biệt và bổ sung trademark blocker độc lập; cert có tên trùng với nhãn hiệu đã được bảo hộ phải được đưa ra khỏi A1.

Giới hạn pháp lý: R9 hiện chỉ phát hiện tên khác nhau và không tra cứu CSDL bảo hộ nhãn hiệu. Việc phân biệt ST_03 với XT_81 vẫn là quyết định thủ công; vì vậy trademark blocker chỉ có thể triển khai sau khi kết nối nguồn như WIPO.

Đơn vị tínhcert — mẫu số theo từng đề xuất: 535 cert có cờ L4.1 · 528 cert lỗi danh tính · 654 cert đối chiếu cách so tên · 81/110 cert XT_33 đã xác minh
Kỳ tính17–25/08/2026
Nguồncard 9627card 965620260826_OA Debug Trace_1608-2508.xlsxcheckers.jsbackground.jsrules_data.jscontent_main.js

Phụ lục

Với kỳ 17/08 đến 15/09, overview tệp mẫu

Population

5,056

cert (3,906 OA) sau dedupe
Độ phủ: 3,506/5,056 cert (69.3% population) có Debug Trace.

Cohort v3.26.2

3,474

cert đã quyết định

docType 1A

85.6%

4,330/5,056 cert (GPKD)

A1 vẫn bị reject

31.2%

430/1,380 cert (gộp 2 lần nộp)

L4.1 dẫn đầu cờ vàng

42.2%

1,923/4,552 lượt vàng

Ghi chú phạm vi dữ liệu. Trang 1 đến 13 lấy dữ liệu kỳ 17/08–25/08 (~1,200 cert có dùng Checker). Trang 14 Phụ lục lấy dữ liệu kỳ 17/08–15/09 (~3,527 cert có dùng Checker), chủ yếu để xem population có gì khác với kỳ 17/08–25/08 không. Nếu cơ cấu vẫn tương đồng, có thể xem các insight kỳ 17/08–25/08 có khả năng đại diện.

Thanh tỉ trọng bốn nhóm — mẫu số 3,474 cert đã quyết định

NhómCert% của 3,474% Approve
A1 · Qualified1,38039.7%68.8%
A2 · Human review1,57145.2%46.6%
A3 · Không đạt38311.0%30.8%
A0 · Lỗi kỹ thuật1404.0%72.1%

Độ phủ Debug Trace: 3,506/5,056 cert (69.3% population).

Cơ cấu, tỉ lệ approve và chênh lệch giữa hai lần nộp

NhómLần đầu: Cert%approveNộp lại: Cert%approveΔ Approve
A11,02270.7%35863.4%−7.3pp
A21,14246.7%42946.4%−0.3pp
A327723.8%10649.1%+25.2pp
A012070.0%2085.0%+15.0pp
Đơn vị tính: cert — tổng hợp từ các trang khác
Kỳ tính: 17/08–15/09/2026
Nguồn: TỔNG HỢP report_data.json
1 / 14