PoC|Fabbi · GTC-MSR 2026-07-12

Phương pháp GTC - chấm điểm AI theo version tài liệu

Trả lời câu hỏi: khi so sánh version (v0 so với v2), dùng checklist/tiêu chí nào để chấm điểm, engine chấm hoạt động ra sao. Rê chuột vào keyword gạch-chân-chấm để xem định nghĩa (glossary hover).

Phần 0 - Tài liệu này trả lời câu hỏi gì

Sản phẩm do AI sinh ra (tài liệu thiết kế, source code, test case) được con người hoàn thiện dần qua các version. Khách hàng muốn biết: AI tự làm được bao nhiêu phần trước khi con người can thiệp, và chấm bằng tiêu chí gì. Trang này giải thích mô hình version, phương pháp chấm 2 tầng, bộ tiêu chí chi tiết (評価項目) và cách engine tính ra từng con số.

Phần 1 - Mô hình version: v0 → v3

v0
AI sinh ra + NEXA audit tự động
Hệ thống NEXA
v1
Creator tự audit
SE (tài liệu) · Dev (code) · QC (test case)
v2
Reviewer audit chéo
BrSE (tài liệu) · TL (code) · QC Lead (test case)
v3
Client audit
Khách hàng

Tại mỗi mốc version, bản nội dung được lưu lại (snapshot). Cặp quan trọng nhất để đo hiệu quả AI là v0 so với v2 (2 ô nền xanh): v2 đã qua reviewer nên được coi là ground truth, còn v0 cho biết AI tự làm được đến đâu trước khi con người can thiệp.

Phần 2 - Phương pháp chấm 2 tầng

Tầng 1 · Chấm tuyệt đối tại v0

Checklist chất lượng, không cần bản đối chiếu

Ngay khi AI sinh xong, từng tài liệu được audit tự động theo bộ rule cố định. Rule nghiêm trọng FAIL thì tài liệu bị chặn, không chuyển công đoạn tiếp theo.

  • Cấu trúcĐủ section bắt buộc theo template từng loại tài liệu
  • Truy vết nguồnMọi factual claim có trích dẫn resolve được; mục chưa xác minh không vượt ngưỡng
  • Nhất quán chéoTham chiếu giữa tài liệu không đứt gãy, không vòng lặp, không mồ côi
  • Hoàn thiệnKhông placeholder chưa điền, không câu chữ chung chung thay đặc tả
  • Văn phong JPHeading đúng chuẩn tài liệu SI, không cam kết quá mức

Đầu ra: PASS/FAIL từng rule + 2 chỉ số Completeness%Consistency%.

Tầng 2 · Chấm tương đối, v0 so với v2

Rubric so sánh version, đo hiệu quả AI

Điểm hiệu quả AI = 完成度 × 0.50 + 精度 × 0.50
完成度 · Completeness · độ phủ so với v2 (5 nhóm = 100%)
20%構造
20%網羅性
25%詳細度
20%API連携
15%検証
精度 · Accuracy · độ đúng của phần đã viết (6 nhóm = 100%)
25%画面項目
20%ステート
15%イベント
20%WF連携
10%通知
10%検証

Hai trục cân bằng 50/50 vì thiếu nội dung và sai nội dung gây chi phí sửa tương đương. Tiêu chí con từng nhóm: Phần 3. Trọng số chốt cùng khách hàng trước khi đo.

POOR< 55%
MODERATE55 - 69%
GOOD70 - 84%
EXCELLENT≥ 85%

Phần 3 - Tiêu chí đánh giá chi tiết (評価項目)

Mỗi nhóm là một hạng mục chấm của Tầng 2; trọng số cộng đủ 100% theo từng trục. Bộ dưới đây áp cho tài liệu thiết kế màn hình; code và test case dùng bộ tương ứng riêng, cùng nguyên lý.

完成度の評価項目 · Độ hoàn thiện (Completeness)

C1. テンプレートの構造20%
  • セクションの構成(整理)
  • 日本語の専門用語(正確な使用)
  • コンテンツの構成(メタデータ→概要→仕様→参照)
  • テンプレートの遵守(規定フォーマット通り)
  • プロフェッショナルな表現(納品品質)
C2. テンプレートセクションの網羅性20%
  • ドキュメントメタデータ
  • 画面概要(Overview)
  • ステート管理(状態管理)
  • 画面レイアウト
  • セクションの仕様(詳細定義)
C3. 画面セクションの詳細度25%
  • タイトル・ステータス管理
  • ユーザー情報・認証連携
  • 入力フォーム(項目仕様)
  • 計算・処理ロジック
  • ボタン・イベント処理
C4. イベント・API連携20%
  • 認証連携(JWT)
  • CRUD操作(Operations)
  • 確認モーダル(Confirmation)
  • トースト通知(Toast Notification)
C5. バリデーションとステート管理15%
  • フィールドのバリデーション
  • 状態管理(ステート管理)
  • エラー処理

精度の評価項目 · Độ chính xác (Accuracy)

A1. 画面項目(アイテム)の正確性25%
  • 12カラムの完全実装(テンプレート準拠)
  • データソースの正確性
  • イベントマッピングの正確性
  • データ型(Type)の正確性
  • 必須項目の設定(マーク)
A2. ステート管理の正確性20%
  • ステート(状態)の定義
  • モードの特定/決定
  • ステート(状態)の遷移/切り替え
  • ボタンステートの制御
  • データフローのパターン
A3. イベント処理の正確性15%
  • API連携(インテグレーション)
  • リクエスト/レスポンスのマッピング
  • エラー処理
  • イベントの特定/詳細定義
A4. ワークフロー連携の正確性20%
  • ワークフローステータスのマッピング
  • 外部システム連携
  • ステータス遷移ロジック
  • システム間(Cross-system)データフロー
A5. メッセージ・通知の正確性10%
  • トーストメッセージの完全性(漏れがないか)
  • モーダル(確認ダイアログ)の正確性
  • エラーメッセージのマッピング
  • 成功通知(サクセス)のフロー
A6. 検証・参照の正確性10%
  • 検証(バリデーション)ルール
  • 共通処理の参照

Kiểm phép cộng: 完成度 = 20+20+25+20+15 = 100% · 精度 = 25+20+15+20+10+10 = 100%. Mọi bộ trọng số công bố đều phải cộng đủ 100 - đây là quy tắc cứng của phương pháp.

Phần 4 - Engine chấm điểm hoạt động như thế nào

Phân tích cây sectionĐọc cấu trúc của cả bản v0 và bản v2
Ghép cặp section tương ứngSo khớp gần đúng theo độ tương đồng tiêu đề (fuzzy matching, ngưỡng 0.7)
Tính độ tương đồng nội dungTF-IDF cosine similarity, thuật toán thống kê đo độ tương đồng văn bản
Trích xuất bằng chứng theo patternBảng định nghĩa hạng mục, nguồn dữ liệu, event ID, kiểu dữ liệu, đánh dấu bắt buộc
Áp trọng số Phần 3, ra verdictĐối chiếu ngưỡng; xuất JSON + báo cáo 3 mức (tổng quan, chi tiết section, bảng bằng chứng)

Rule-based, không dùng AI chấm AI. Mọi con số tính bằng thuật toán xác định - chạy lại luôn ra đúng số cũ, audit được căn cứ từng điểm. LLM nếu có chỉ gợi ý soát thêm, không bao giờ là căn cứ kết luận duy nhất.

Không có con số trần trụi. Mọi tỷ lệ phần trăm báo kèm mẫu số (bao nhiêu mục trên tổng bao nhiêu mục). Toàn bộ input được lưu kèm báo cáo để tái lập.

Phần 5 - Ví dụ với source code: hai cách đọc cùng một phép đo

Cách đo: so sánh bằng git giữa bản v0 (AI sinh) và bản v2 (reviewer chốt), từng dòng một. Hai bản được format thống nhất trước khi so để thay đổi trình bày không bị đếm nhầm là sửa. Với từng file: A = tổng số dòng bản v2, B = số dòng SE viết thêm, C = số dòng SE sửa lại; tỷ lệ giữ nguyên = (A − B − C) / A. Không đếm file test, migration, config và tính năng hệ mới thêm mà bản cũ không có.

75.7%

Tính trên tổng dòng

Màn hình đo chi tiết: 2.039 dòng bản v2, SE viết thêm 324 dòng, sửa 172 dòng → (2.039 − 324 − 172) / 2.039 = 75.7%. File lớn chi phối con số này.

92.0%

Bình quân theo file

Cùng màn hình đó, tính tỷ lệ giữ nguyên từng file rồi lấy trung bình: mỗi file một phiếu, không phân biệt to nhỏ.

Vì sao hai số lệch nhau và phải đọc cả hai: đa số file được giữ nguyên gần 100% (domain, repository, mapper), nhưng một vài file bị viết lại nhiều - file JS phía màn hình gần như viết lại toàn bộ, controller giữ 64%. Tính trên tổng dòng thì các file bị viết lại kéo số xuống 75.7%; tính bình quân file thì thấy rõ "đa số chỗ AI làm được ngay". Báo cả hai, kèm bảng per-file, mới thấy đúng AI mạnh yếu ở lớp nào. Chất lượng bàn giao cuối được chốt riêng bằng test đối chiếu hệ cũ - hệ mới (Phần 6).

Phần 6 - Số liệu tham chiếu từ dự án đã áp dụng

Phương pháp đã áp dụng trọn vẹn tại hai dự án, tài liệu thiết kế theo chuẩn SI Nhật: dự án A (phát triển mới, 8 màn hình) và dự án B (migration, 4 màn hình, đo bằng git line-compare v0 so với v2).

Sản phẩmQuy mô so sánhCoverage · độ phủAccuracy · độ đúng
Tài liệu thiết kế chi tiết (dự án A)trung bình 8 màn hình82.3%86.0%
Tài liệu thiết kế BD/DD (dự án B)4 màn hình, đếm item 5 nhóm97.0%item v0 còn lại trong v289.9%item giữ nguyên không phải sửa
Test case (dự án A)701 case AI so với 979 case chuẩn81.7%800/979 case chuẩn được AI phủ77.5%543/701 case AI khớp chuẩn
Source code (dự án B)4 màn hình, git line-compare v0 vs v2 (Phần 5)-68.1%tổng dòng AI giữ nguyên / tổng dòng v2
Đối chiếu hệ cũ - hệ mới (dự án B)cùng input, so output từng test case-100%4/4 màn hình

Ở dự án A, tỷ lệ lỗi thực sự do AI gây ra chiếm 11.1% tổng số bug ghi nhận trong giai đoạn test. Các con số là kết quả đo có bảng đếm và bằng chứng từng màn hình, không phải ước lượng.

Phần 7 - Vận hành trong dự án

AI sinh sản phẩm, Tầng 1 chạy tự động ngay; sản phẩm kèm kết quả audit trở thành v0
Creator và reviewer audit lần lượt tạo v1, v2; mỗi mốc đều lưu snapshot
Khi v2 chốt, Tầng 2 chạy so sánh v0 với v2, sinh báo cáo hiệu quả AI cho công đoạn đó
Kết quả cộng dồn vào báo cáo KPI theo milestone (xem bộ chỉ số GTC-OPT)

Cam kết 1 · Trọng số cố định: checklist và trọng số thống nhất với khách hàng trước khi đo, cố định trong suốt dự án để số liệu giữa các đợt so sánh được với nhau.

Cam kết 2 · Điểm không thay thế review: điểm số phục vụ theo dõi hiệu quả AI và cải tiến quy trình; các bước audit của con người ở v1, v2, v3 vẫn thực hiện đầy đủ bất kể điểm cao hay thấp.

Quan hệ với bộ chỉ số GTC-OPT (đọc trước khi đối chiếu 2 trang)

Điểm khácCách đọc đúng
Mã nhóm A/C trùng ký hiệuA1-A6 / C1-C5 ở trang này là nhóm tiêu chí rubric GTC (hạng mục chấm bên trong một tài liệu). A1-A4 / C1-C9 bên GTC-OPTmã chỉ số KPI toàn dự án. Hai hệ ký hiệu độc lập, không quy đổi trực tiếp.
Vị trí trong bức tranh KPIToàn bộ phương pháp trang này chính là cách đo cho chỉ số A2 Docs-gen FPA (và cùng nguyên lý cho A3 code / A4 test case) của bộ KPI GTC-OPT.
Công thức gộp 2 trụcTrang này gộp 50/50 (đã chạy thật ở dự án A). GTC-OPT định nghĩa A2 = min(Completeness%, Accuracy%) - cách gộp bảo thủ hơn (lấy trục yếu). Hai cách cùng dựa trên 2 trục này; chốt một cách với khách hàng trước khi báo số, không trộn lẫn.
Số đã đoSố ở Phần 6 là của dự án A/B đã hoàn tất. Bộ KPI GTC-OPT theo dõi PoC hiện tại, một số chỉ số còn pending.