Biến AI Agent Định Nghĩa Yêu Cầu thành “Development OS”: Deep Dive thiết kế kỹ thuật từ tạo As-Is/To-Be đến prototyping và phối hợp offshore

1. Executive Summary（Tóm tắt kỹ thuật ~300 chữ）

Bản chất khiến các doanh nghiệp Nhật Bản khó đẩy nhanh hiện đại hóa hệ thống legacy không nằm ở riêng công đoạn phát triển, mà ở “định nghĩa yêu cầu phụ thuộc cá nhân” và “tốc độ hình thành đồng thuận chậm”. GenAI đã vượt khỏi phạm vi tóm tắt biên bản họp, hỗ trợ xuyên suốt từ tự động tạo As-Is business flow → thiết kế To-Be → phát hiện mâu thuẫn/ngoại lệ → xuất danh sách yêu cầu/tài liệu thiết kế → trình bày prototype có thể chạy được, qua đó tăng mạnh throughput ở giai đoạn thượng nguồn. Bài viết này đưa ra kiến trúc tham chiếu để “đóng đinh” AI agent định nghĩa yêu cầu như một “Development OS” trong tổ chức (RAG, thực thi workflow, audit, ranh giới phân quyền, tích hợp CI), cùng các điểm thiết kế then chốt về hiệu năng, bảo mật và khả năng mở rộng.⚙️

2. Bối cảnh kỹ thuật và vấn đề（Giải thích sơ đồ kiến trúc, các điểm đau hiện tại）

Như các bài viết tham khảo đã chỉ ra, định nghĩa yêu cầu là “lõi thượng nguồn” quyết định “xây cái gì”; mọi lệch pha sẽ bị khuếch đại thành rework ở các công đoạn hạ nguồn. Đặc biệt trong doanh nghiệp lớn, nghiệp vụ có ngoại lệ/nhánh rẽ/phân quyền/audit phức tạp; sự lệch về độ chi tiết tài liệu và tri thức ngầm dễ trở thành điểm chí tử. Kết quả là vẫn tồn tại các vấn đề cấu trúc: ① phụ thuộc vào chuyên gia kỳ cựu (tập trung vào top 1% kỹ năng) ② review dễ trở thành “cảm giác” ③ thiếu prototype nên đồng thuận chậm ④ lệch nhận thức giữa offshore/nhiều vendor ngày càng lớn.

Điểm mấu chốt ở đây không phải “dùng AI như công cụ tóm tắt”, mà là quản lý các deliverable của định nghĩa yêu cầu dưới dạng biểu diễn trung gian có thể đọc bằng máy (IR: Intermediate Representation) và nối thẳng sang thiết kế/triển khai/kiểm thử. AI định nghĩa yêu cầu đóng vai trò như một “compiler”: chuyển đổi ngôn ngữ tự nhiên → IR → tài liệu/prototype/ticket.🔧

Sơ đồ luồng kỹ thuật (mô tả)： (1) Ingest audio/biên bản họp/tài liệu thiết kế hiện có/quy định → (2) chuẩn hóa & ẩn danh → (3) tham chiếu chuẩn nội bộ/dự án quá khứ/quy định bằng RAG → (4) LLM trích xuất As-Is business process (tương đương BPMN) và glossary thuật ngữ domain → (5) tạo To-Be theo định hướng thay đổi → (6) phân tích tĩnh để phát hiện ngoại lệ/mâu thuẫn/lệch phân quyền → (7) xuất danh sách yêu cầu (User Story/FR/NFR) và tài liệu thiết kế (màn hình/IF/data model) → (8) tạo prototype → (9) workflow phê duyệt và audit log → (10) đồng bộ sang Jira/Azure DevOps để triển khai.

[Meeting Audio/Notes]   [Legacy Docs]   [Policies]
        \                |              /
         \               |             /
          --> Ingestion/ETL --> PII Redaction --> Vector Index (RAG)
                                |                    |
                                v                    v
                         LLM Orchestrator  <--> Knowledge Base
                                |
                                v
                 As-Is Process IR --> To-Be Process IR
                                |
                    +-----------+-----------+
                    |                       |
                    v                       v
         Consistency/Exception Analyzer   Prototype Generator
                    |                       |
                    v                       v
       Requirements/Design Artifacts     Clickable UI/API Mock
                    |
                    v
          Approval + Audit + Ticket Sync

3. Phần kỹ thuật ①: Thiết kế business flow và mô hình yêu cầu như IR ⚙️

3.1 Vì sao AI định nghĩa yêu cầu không có IR sẽ “vỡ”

Nếu tích lũy yêu cầu dưới dạng ngôn ngữ tự nhiên, rất khó đảm bảo nhất quán về độ chi tiết/thuật ngữ/ngoại lệ; đến các bước sau sẽ biến thành “cuộc chiến diễn giải”. Vì vậy, hãy biểu diễn As-Is/To-Be theo chuẩn tương đương BPMN 2.0 (hoặc JSON riêng), cấu trúc hóa sự kiện nghiệp vụ, điều kiện rẽ nhánh, trách nhiệm (RACI), dữ liệu vào/ra. Nhờ đó, đầu ra của AI có thể được quản lý như “deliverable” với diff (Git), cho phép review và audit. IR cũng nối trực tiếp sang thiết kế test (bao phủ kịch bản) và thiết kế phân quyền (RBAC/ABAC).

3.2 Mô hình tham chiếu (ví dụ JSON Schema)

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "ProcessIR",
  "type": "object",
  "properties": {
    "processId": {"type": "string"},
    "version": {"type": "string"},
    "actors": {"type": "array", "items": {"type": "string"}},
    "activities": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "id": {"type": "string"},
          "name": {"type": "string"},
          "type": {"enum": ["task","gateway","event"]},
          "inputs": {"type": "array", "items": {"type": "string"}},
          "outputs": {"type": "array", "items": {"type": "string"}},
          "sla": {"type": "string"},
          "controls": {
            "type": "object",
            "properties": {
              "rbac": {"type": "array", "items": {"type": "string"}},
              "audit": {"type": "boolean"}
            }
          }
        },
        "required": ["id","name","type"]
      }
    },
    "edges": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "from": {"type": "string"},
          "to": {"type": "string"},
          "condition": {"type": "string"}
        },
        "required": ["from","to"]
      }
    }
  },
  "required": ["processId","version","activities","edges"]
}

3.3 Điểm then chốt khi triển khai

Không dùng trực tiếp output của LLM; bắt buộc Schema validation + hiệu chỉnh theo rule-based (ví dụ: thiếu điều kiện rẽ nhánh của gateway, phát hiện node cô lập). Vòng lặp “AI → cấu trúc hóa → kiểm chứng → review theo diff” là chìa khóa để chuyển tính phụ thuộc cá nhân thành “quy trình”.🔧

4. Phần kỹ thuật ②: Thiết kế RAG—làm sao tận dụng chuẩn nội bộ, dự án quá khứ và quy định 🔧

4.1 Phân lớp tri thức (Policy/Pattern/Project)

Độ chính xác của AI định nghĩa yêu cầu phụ thuộc vào chất lượng tri thức tham chiếu hơn là kích thước model. RAG tối thiểu nên chia 3 lớp: ①Policy (quy định nội bộ, yêu cầu audit, dữ liệu cá nhân, lưu trữ log) ②Pattern (kiến trúc chuẩn, IF chuẩn, màn hình chuẩn, quy ước đặt tên) ③Project (đặc tả hệ thống hiện hữu, DB hiện tại, quy trình vận hành). Do tần suất cập nhật và workflow phê duyệt khác nhau theo từng lớp, cần tách index và điều khiển bằng boost/filter khi truy vấn.

4.2 Ví dụ cấu hình thực tế cho Embedding/Chunking

Embedding giả định lớp tương đương text-embedding-3-large (triển khai phụ thuộc vendor). Chunk không cắt theo “đoạn văn” mà theo “đơn vị yêu cầu”. Ví dụ: 1 điều khoản trong quy định, 1 endpoint trong API spec, 1 hạng mục trong screen spec. Bắt buộc gắn metadata (system, module, confidentiality, effectiveDate) để đảm bảo khả năng giải trình của kết quả truy xuất.

rag:
  embeddingModel: "text-embedding-3-large"
  chunking:
    strategy: "semantic"
    maxTokens: 800
    overlapTokens: 120
  metadata:
    - system
    - module
    - docType
    - confidentiality  # public/internal/restricted
    - effectiveDate
  retrieval:
    topK: 8
    filters:
      confidentiality: ["internal","restricted"]
    reranker: "bge-reranker-v2-m3"

4.3 Không cho phép “tự do không tham chiếu”

Đưa “quy tắc bắt buộc tham chiếu” vào lúc sinh nội dung. Ví dụ: “quy trình có xử lý dữ liệu cá nhân phải trích dẫn quy định PII nội bộ”, “nghiệp vụ phê duyệt phải gắn template yêu cầu audit log”… biến RAG thành guardrail. Cách này giúp giảm biến động chất lượng giữa các dự án.⚙️

5. Phần kỹ thuật ③: Phân tích tĩnh để phát hiện ngoại lệ, mâu thuẫn, thiếu sót 📊

5.1 Nguồn gốc sự cố nằm ở “ngoại lệ” và “điều kiện biên”

Mẫu hình “cháy dự án” điển hình ở dự án lớn là đồng thuận luồng chuẩn nhanh, còn ngoại lệ bị để sau. AI định nghĩa yêu cầu có thể tự động tấn công điểm này. Trên To-Be IR, dùng rule để phát hiện: (a) node không thể tới (b) không có điểm kết thúc (c) điều kiện rẽ nhánh trùng/lọt (d) chưa gán vai trò (e) là đối tượng audit nhưng audit=false… rồi sinh câu hỏi phỏng vấn bổ sung.

5.2 Ví dụ rule engine (đơn giản)

def detect_orphan_nodes(process):
    ids = {a["id"] for a in process["activities"]}
    connected = set()
    for e in process["edges"]:
        connected.add(e["from"]); connected.add(e["to"])
    return list(ids - connected)

def detect_missing_rbac(process):
    missing = []
    for a in process["activities"]:
        if a.get("type") == "task" and not a.get("controls", {}).get("rbac"):
            missing.append(a["id"])
    return missing

5.3 Chỉ số benchmark (định lượng chất lượng)

“Yêu cầu tốt” thường bị nói theo cảm tính, nhưng khi triển khai AI thì việc đo lường là bắt buộc. Ví dụ: số kịch bản ngoại lệ, số trách nhiệm chưa gán, mức bao phủ đối tượng audit, xu hướng số lượng nhận xét review, effort rework. Có thể tự động tổng hợp bằng phân tích IR và vận hành như quality gate.📊

6. Phần kỹ thuật ④: Tạo prototype—biến đồng thuận thành “đặc tả chạy được” 🔧

6.1 Cho người dùng “chạm” trước khi đóng băng đặc tả

Trọng tâm của bài tham khảo là “triệt lệch pha bằng prototype chạy được”. Về kỹ thuật, mục tiêu lý tưởng là tái hiện với chi phí tối thiểu: điều hướng màn hình, kiểm soát phân quyền, validation đầu vào, API mock… để người dùng nghiệp vụ thao tác được trong vòng 48 giờ. Điểm quan trọng là không coi prototype là thứ sẽ vứt bỏ. Hãy giữ UI definition (JSON) và OpenAPI như deliverable để trượt thẳng sang triển khai.

6.2 Ví dụ contract-first với OpenAPI 3.1

openapi: 3.1.0
info:
  title: Approval API
  version: 0.1.0
paths:
  /approvals:
    post:
      summary: Create approval request
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required: [requesterId, amount, reason]
              properties:
                requesterId: { type: string }
                amount: { type: number, minimum: 0 }
                reason: { type: string, maxLength: 2000 }
      responses:
        "201":
          description: Created

6.3 Ranh giới để ngăn “đem đồ sinh ra” vào production

Tạo prototype rất mạnh nhưng cũng dễ gây sự cố. Biện pháp là tách rõ môi trường prototype khỏi production; chỉ dùng dữ liệu tổng hợp (synthetic data), cấm gửi ra ngoài, bắt buộc audit log. Đồng thời, khi chuyển từ prototype sang triển khai thật, tự động liệt kê chênh lệch (gap) để làm rõ phần yêu cầu còn thiếu.⚙️

7. Phần kỹ thuật ⑤: Ranh giới bảo mật—triệt tiêu bài toán “mang dữ liệu ra ngoài” của AI định nghĩa yêu cầu 🔒

7.1 Threat model (tối thiểu)

Định nghĩa yêu cầu trộn lẫn nghiệp vụ/khách hàng/hợp đồng/dữ liệu cá nhân, nên là một trong những vùng nguy hiểm nhất khi dùng LLM. Có thể gom threat thành: ① gửi thông tin mật ra ngoài ② prompt injection ③ RAG poisoning ④ phân quyền quá mức ⑤ không thể audit. Nếu không xử lý ngay từ thiết kế, triển khai toàn công ty sẽ bị chặn.

7.2 Biện pháp kỹ thuật (điểm triển khai)

• Tự động masking PII/thông tin hợp đồng：khi ingest, chạy DLP (regex + NER), hash hóa/tokenize.
• Phòng thủ prompt：cố định system prompt + allowlist hóa tool execution. Không diễn giải input người dùng như mệnh lệnh.
• Ký RAG：gắn chữ ký và metadata người phê duyệt cho tài liệu tri thức; tài liệu chưa phê duyệt không được đưa vào truy xuất.
• Audit log：theo dõi ai đưa gì vào, tham chiếu tài liệu nào, xuất ra cái gì.

# Ví dụ: chặn gửi ra ngoài ở môi trường prototype (ví dụ khái niệm)
server {
  listen 443 ssl;
  location / {
    proxy_pass http://prototype-app;
  }
  # giả định chặn egress ngoài allowlist bằng FW/egress
}

7.3 Thiết kế log chịu được yêu cầu audit

Tối thiểu cần ghi: (a) input artifact hash (b) prompt template version (c) model/version (d) retrieved doc IDs (e) output artifact hash. Nhờ đó có thể truy vết “vì sao ra yêu cầu như vậy”, đảm bảo trách nhiệm giải trình khi audit/kiện tụng.🔧

8. Phần kỹ thuật ⑥: Khả năng mở rộng—thiết kế vận hành cho dự án lớn và nhiều dự án song song 📊

8.1 Nút thắt không phải LLM mà là “review của con người”

Khi đưa AI vào, tốc độ sinh nội dung tăng nhưng tải review trở thành ràng buộc mới. Cách xử lý là chia deliverable thành “diff thay đổi” để giảm đơn vị review. Quản lý IR bằng Git, trình bày To-Be diff/yêu cầu diff/API diff theo PR. Đồng thời tự động gắn tag theo góc nhìn review (audit, phân quyền, hiệu năng, vận hành) và route đến đúng chuyên gia.

8.2 Thiết kế multi-tenant cho nhiều dự án song song

Vector DB/log/kho lưu deliverable nên tách theo dự án (tenant). Tối thiểu khuyến nghị tách namespace + tách khóa KMS. Khi truy vấn RAG, bắt buộc filter để không vượt biên tenant (để tránh quên gắn filter ở phía ứng dụng, nên cưỡng chế ở phía DB).⚙️

8.3 Benchmark hiệu năng (ví dụ)

Dưới đây là ví dụ benchmark giả định: nạp “biên bản 50.000 ký tự + tài liệu thiết kế hiện hữu tương đương 200 trang”, xử lý đến bước As-Is → To-Be → xuất danh sách yêu cầu (môi trường: Kubernetes v1.29, vector DB HNSW, RAG topK=8). Số liệu là mục tiêu thiết kế tham khảo; thực đo cần điều chỉnh theo từng công ty.📊

Xử lý	p50	p95	Nguyên nhân chính	Giải pháp
Ingest + chuẩn hóa	45s	120s	OCR/format	Ingest theo diff, OCR song song
Tạo embedding	90s	240s	Lượng token	chunk theo đơn vị yêu cầu, khử trùng lặp
RAG search + reranking	180ms	650ms	Tìm kiếm vector	Tinh chỉnh tham số HNSW, cache
Tạo As-Is IR	35s	80s	LLM inference	Sinh theo giai đoạn, cấu trúc hóa bằng function calling
Tạo To-Be IR	40s	95s	Tăng nhánh rẽ	Chia module, tái sinh từng phần
Phân tích tĩnh (rule)	1.2s	3.5s	Duyệt đồ thị	Phân tích incremental
Xuất danh sách yêu cầu/tài liệu thiết kế	25s	70s	Render template	Pre-compile template

9. Phần kỹ thuật ⑦: Nén “chi phí truyền đạt đặc tả” bằng AI trong mô hình offshore/nội bộ kết hợp 🔧

9.1 Chi phí thật của offshore là giao tiếp

Như bài tham khảo 3 chỉ ra, do thiếu nhân lực và chi phí tăng, offshore ngày càng được dùng nhiều. Tuy nhiên, phần lớn thất bại đến từ “tính bất đối xứng của đặc tả”. Giá trị của AI định nghĩa yêu cầu ở đây không phải dịch để bù chênh lệch tiếng Anh hay văn hóa, mà là cấu trúc hóa đặc tả để giảm mơ hồ. Nếu bàn giao theo bộ IR, OpenAPI, screen flow, acceptance criteria (Given/When/Then), chi phí truyền đạt sẽ giảm.

9.2 Ví dụ tự động tạo acceptance criteria (Gherkin)

Feature: Create approval request
  Scenario: Amount must be non-negative
    Given I am an authenticated requester
    When I submit an approval with amount -1
    Then the API should respond with 400
    And the error code should be "VALIDATION_ERROR"

9.3 Vận chuyển Change Request (CR) dưới dạng “diff”

Rework ở offshore tăng mạnh khi CR được ném bằng ngôn ngữ tự nhiên. Nếu vận hành theo hướng đính kèm diff của To-Be IR (JSON Patch) và tự động tính phạm vi ảnh hưởng (màn hình/API/DB/phân quyền/audit) vào CR, thì ước lượng/triển khai/kiểm thử sẽ ổn định hơn.⚙️

10. Bảng phân tích so sánh (so sánh từ 3 lựa chọn trở lên)

Các lựa chọn triển khai AI agent định nghĩa yêu cầu có thể chia thành 3 nhóm: ① AI định nghĩa yêu cầu dạng SaaS (ví dụ kiểu tích hợp như Acsim) ② LLM tổng quát + orchestration tự phát triển (LangGraph, v.v.) ③ lấy BPM/tool quản lý yêu cầu làm trung tâm (AI chỉ hỗ trợ). Tối ưu phụ thuộc vào mục đích và yêu cầu kiểm soát.📊

Lựa chọn	Điểm mạnh	Điểm yếu/Rủi ro	Tổ chức phù hợp	Kiểm soát (audit/phân quyền)
SaaS AI định nghĩa yêu cầu (tích hợp)	Xuyên suốt (As-Is/To-Be/prototype/tài liệu thiết kế), khởi động nhanh	Lo ngại mang dữ liệu ra ngoài, dễ “black box” hóa chức năng	SIer/doanh nghiệp muốn chạy DX quy mô lớn trong thời hạn ngắn	Phụ thuộc tính năng vendor (bắt buộc kiểm tra độ chi tiết log)
LLM tổng quát + tự phát triển (RAG/IR/tích hợp CI)	Tối ưu theo chuẩn nội bộ/quy định, kiểm soát ranh giới theo yêu cầu doanh nghiệp	Chi phí triển khai ban đầu lớn, cần tổ chức vận hành (đánh giá/cải tiến)	Tổ chức có văn hóa nội bộ hóa, muốn tích lũy năng suất thượng nguồn thành tài sản dài hạn	Mạnh nhất nếu thiết kế tốt (có thể tích hợp KMS/audit/chữ ký)
Lấy BPM/tool quản lý yêu cầu làm trung tâm + AI hỗ trợ	Dễ “đặt lên” quy trình hiện hữu, phù hợp audit/governance	Tính xuyên suốt khi sinh nội dung yếu hơn, có thể thiếu liên kết với prototype	Ngành bị quản lý chặt/yêu cầu audit cao, thay đổi thận trọng	Đi theo kiểm soát sẵn có, nhưng log tham chiếu/đầu ra của AI cần bổ sung

11. Best practices & anti-patterns (gạch đầu dòng)

✅ Best practices

• Quản lý diff IR (business flow/yêu cầu/dữ liệu) bằng Git, đưa review về mô hình PR
• Tách RAG knowledge theo Policy/Pattern/Project và bắt buộc phê duyệt + ký
• Dùng phát hiện ngoại lệ/mâu thuẫn làm quality gate, tự động sinh câu hỏi phỏng vấn bổ sung
• Giữ prototype như deliverable không vứt (OpenAPI/định nghĩa màn hình, v.v.)
• Audit log lưu “căn cứ tham chiếu (doc IDs)” để đảm bảo khả năng giải trình

❌ Anti-patterns

• Hài lòng với tóm tắt biên bản họp, không có cấu trúc hóa (IR)
• Trộn tài liệu chưa phê duyệt vào RAG, cho phép poisoning
• Chạy prototype bằng dữ liệu production (không DLP/không cô lập)
• Bỏ review vì “AI tạo nên chắc đúng” (sụp đổ ranh giới trách nhiệm)
• Tiếp tục ném CR bằng ngôn ngữ tự nhiên cho offshore, không quản lý diff

12. Lộ trình triển khai và checklist ⚙️

12.1 Tuần 0–4: PoC (kiểm chứng với 1 quy trình yêu cầu)

• [ ] Xây pipeline Ingest (biên bản họp/quy định/tài liệu thiết kế hiện hữu)
• [ ] Masking PII (DLP) và tách tenant
• [ ] Tạo As-Is IR → tạo dữ liệu “đúng” thủ công (phục vụ đánh giá)
• [ ] Tạo To-Be + phân tích tĩnh (tối thiểu 10 rule)
• [ ] Output (danh sách yêu cầu, khung OpenAPI, khung Gherkin)

12.2 Tuần 5–12: Pilot (vận hành song song 2–3 dự án)

• [ ] Tích hợp vào Git/PR (review diff IR)
• [ ] Triển khai audit log (prompt/version/retrieval IDs)
• [ ] Tích hợp Jira/Azure DevOps (tự động tạo ticket)
• [ ] Chuẩn hóa gói deliverable cho offshore (IR + OpenAPI + Gherkin)

12.3 Tuần 13–24: Triển khai toàn công ty (governance và SLA)

• [ ] Thiết lập workflow phê duyệt tri thức (Policy/Pattern/Project)
• [ ] KPI hóa quality gate (bao phủ ngoại lệ/bao phủ đối tượng audit)
• [ ] Quản lý thay đổi model/prompt (versioning)
• [ ] Quy định hóa phân định trách nhiệm của deliverable (AI/người phụ trách/người phê duyệt)

13. Tài nguyên tham khảo & bước tiếp theo

• ⚙️ BPMN 2.0 Specification（OMG）
• 🔧 OpenAPI 3.1 Specification
• 📊 Gherkin / Cucumber（chuẩn hóa acceptance criteria）
• 🔒 NIST AI RMF（khung quản trị rủi ro AI）

Bước tiếp theo：Trước hết, chọn các nghiệp vụ có nhiều ngoại lệ và yêu cầu audit mạnh như “phê duyệt”, “đề nghị”, “quản lý master data” làm đề tài, chạy vòng As-Is → To-Be → prototype → acceptance criteria trong 2 tuần. Sau đó chuẩn hóa IR và các chỉ số chất lượng thu được thành template, tạo “tính tái lập” để nhân rộng giữa các dự án—đây là con đường ngắn nhất để nâng AI định nghĩa yêu cầu từ công cụ đơn lẻ lên “Development OS”.⚙️