Council Review — NĐ-36-01 "Xây dựng bản quan hệ ngữ nghĩa"

Đánh giá Phần 1: 7 Mục tiêu

Ngày: 2026-04-06 | Phiên: S169 Yêu cầu: Review mục tiêu TRƯỚC KHI viết giải pháp Loại: Review mới — chưa qua vòng nào

I. BỐI CẢNH

Tại sao cần NĐ này?

Incomex đang xây dựng hệ thống quản trị doanh nghiệp hoàn chỉnh trên PG16 + Qdrant. Ba điều luật cốt lõi sắp triển khai:

Điều 39 (Knowledge Graph): Xây dựng KG đủ tin cậy để AI ra quyết định. 26 bài toán, 36 DOT, 10 quy trình. Đã ban hành v2.3 qua 3 vòng Council.
Điều 38 (SQL hoá Văn bản): Biến văn bản pháp quy (chính sách, quy trình, hợp đồng) thành dữ liệu PG có cấu trúc. DOT so sánh VB ↔ data PG tự động. Sản phẩm đầu ra = Semantic Annotation (bản chú thích ngữ nghĩa cho DOT đọc).
Điều 37 (Tổ chức Bộ máy Quản trị): Phân quyền, phân cấp, agency owners cho toàn hệ thống.

Vấn đề: Cả 3 điều trên đều giả định hệ thống có khả năng nhận diện khái niệm từ ngôn ngữ tự nhiên và mapping về đúng thực thể PG. Nhưng hạ tầng này chưa tồn tại. Cụ thể:

Con người viết "NV thử việc", "lương CB", "Xn" — hệ thống không nhận ra đây là thực thể đã khai sinh.
"Doanh thu" và "Revenue" đều lọt qua Birth Registry vì tên khác nhau — trùng lắp tích tụ.
Quan hệ ngữ nghĩa ("Doanh thu" bao hàm "Doanh thu thuần") tồn tại trong đầu người dùng, chưa ai ghi vào PG.
Đ38 cần binding VB vào PG, Đ39 cần nodes + edges có chất lượng — cả hai đều bị chặn.

NĐ-36-01 = hạ tầng nền cho cả Đ38 và Đ39. Không có nó, Đ38 chỉ trên giấy, Đ39 phải xây Graph từ text thô.

Stack hiện tại

PG16 (SSOT duy nhất) — single Contabo VPS EU ($8/tháng), Docker 6 services
Qdrant (vector search) — embedding ngữ nghĩa
Directus CMS — giao diện quản lý
Nuxt 3 — frontend
Agent Data KB — tài liệu tri thức
Multi-agent: Claude Desktop điều phối, Claude CLI + Codex + Gemini CLI thực thi
Langroid — agent framework cho AI pipeline (đã lên kế hoạch cho Đ39)

Triết lý thiết kế

PG native first: Khai thác tối đa năng lực PG trước khi dùng AI
Không phát minh: Dùng kỹ thuật chuẩn ngành đã chứng minh
Tự động 100%: Làm tay = vi phạm Hiến pháp
Assembly First: PG→Directus→Nuxt, không bypass

II. TÀI LIỆU CẦN ĐỌC

Để đánh giá đầy đủ, Council cần đọc các tài liệu sau:

#	Tài liệu	Đường dẫn	Mục đích
1	NĐ-36-01 DRAFT (đối tượng review)	`knowledge/dev/architecture/nd-36-01-semantic-relationship-infrastructure-draft.md`	7 mục tiêu cần đánh giá
2	Điều 39 v2.3 (Knowledge Graph)	`knowledge/dev/architecture/dieu39-knowledge-graph-law-draft.md`	NĐ-36-01 phục vụ: 26 bài toán, đặc biệt A3, A4, A8, B5, C1, C9, C10, C13
3	Điều 38 v3.0 DRAFT (SQL hoá VB)	`knowledge/dev/architecture/dieu38-normative-document-law-draft.md`	NĐ-36-01 phục vụ: Semantic Annotation, binding VB→PG
4	Điều 36 v5.0 DRAFT (Collection)	`knowledge/dev/architecture/dieu36-collection-protocol-law-draft.md`	NĐ-36-01 thuộc GP5 MT5 của Đ36
5	Operating Rules v7.54	`knowledge/dev/ssot/operating-rules.md`	13 NT + 6 CQ + 16 CP mà NĐ phải tuân thủ
6	Hiến pháp v4.4.0	`knowledge/dev/laws/constitution.md`	Nguyên tắc nền tảng: NT-13 PG FIRST, Assembly First

III. GIẢI PHÁP DỰ KIẾN (tóm tắt — chưa viết chi tiết)

NĐ-36-01 dự kiến xây dựng:

Hạ tầng PG (nâng cấp Birth Registry)

Bảng entity_aliases — tên gọi khác, viết tắt, tên cũ → trỏ về canonical name
Bảng entity_relations — quan hệ mềm (đồng nghĩa, bao hàm, mâu thuẫn)
Bảng abbreviation_dict — viết tắt quy ước toàn hệ thống
Bảng disambiguation_log — ghi nhận quyết định duyệt mơ hồ → Active Learning
Species mới semantic_concept — khái niệm chưa có nhà PG, chỉ phục vụ ngữ nghĩa
Bảng binding kết quả Đ38 (mapping ngôn ngữ VB ↔ PG schema) — bảng riêng

PG Extensions cần khai thác (10 tính năng native)

Pipeline Entity Linking (4 tầng)

PG exact match + constraints (free, realtime)
PG fuzzy: pg_trgm + levenshtein + unaccent (free, realtime)
Qdrant embedding similarity (batch, low cost)
Langroid agent: NER + Relation Extraction + Coreference Resolution (batch, có token)

Kỹ thuật chuẩn ngành áp dụng

Sản phẩm đầu ra cho Đ38

Semantic Annotation: Mỗi VB ban hành → pipeline chạy → sinh bản chú thích ngữ nghĩa (JSONB) → DOT đọc bằng JSONPath → tự so sánh VB ↔ data PG → chênh lệch = cảnh báo. Không cần AI, không tốn token.

2 nguồn dữ liệu cho Đ39

Nguồn 1: entity_relations (quan hệ mềm, tĩnh) — bên Birth Registry
Nguồn 2: Đ38 Semantic Annotation output (quan hệ động, có ngữ cảnh)

IV. 7 MỤC TIÊU CẦN COUNCIL ĐÁNH GIÁ

MT	Mục tiêu	Phục vụ
MT1	Nhận diện khái niệm → đúng thực thể PG (Entity Linking + Canonicalization)	Đ38 binding
MT2	Ghi nhận quan hệ ngữ nghĩa mềm (đồng nghĩa, bao hàm, mâu thuẫn)	Đ39 graph edges
MT3	Pipeline NLP 4 bước chuẩn hoá đầu vào (Normalization→NER→Linking→Relation Extraction)	Đ38 + Đ39
MT4	Phân loại 3 mức tin cậy + truy vết nguồn + provenance per annotation	Chất lượng + Đ39 A8
MT5	Bootstrap từ PG schema hiện có (Ontology Learning from RDB)	Khởi tạo nhanh
MT6	Active Learning — hệ thống tự cải thiện từ mỗi lần người sửa	Vòng lặp cải tiến
MT7	Tổ chức outcome/case study để hệ thống học được (CBR + RLHF)	Đ39 B5 + C9 + C13

V. CÂU HỎI CHO COUNCIL

Câu hỏi chung

Đầy đủ chưa? 7 mục tiêu đã phủ hết nhu cầu hạ tầng cho Đ38 + Đ39 chưa? Còn thiếu mục tiêu nào quan trọng?
PG native đã khai thác hết chưa? 10 PG features đã liệt kê — còn tính năng PG16 nào phục vụ Entity Linking / Semantic Annotation mà chúng tôi chưa tính?
Chuẩn ngành còn gì? 12 kỹ thuật NLP/Data Management đã liệt kê — có kỹ thuật nào đã public, đã chứng minh hiệu quả mà chúng tôi bỏ sót?

Câu hỏi kỹ thuật

4 tầng pipeline Entity Linking (PG exact → PG fuzzy → Qdrant embedding → Langroid agent) — thứ tự và phân chia có hợp lý? Có cách nào tiết kiệm hơn?
ltree cho phân cấp khái niệm — có phải lựa chọn tốt nhất cho PG16, hay Recursive CTE + entity_relations đã đủ?
Semantic Annotation lưu JSONB — có nên dùng cấu trúc chuẩn nào (W3C Web Annotation, JSON-LD, hay custom schema)?
Active Learning (MT6) dùng disambiguation_log — có pattern nào tốt hơn trong ngành cho bài toán Word Sense Disambiguation trong doanh nghiệp?

Câu hỏi chiến lược

Rủi ro khi scale: Hệ thống hiện tại chạy trên single VPS $8/tháng. NĐ-36-01 thêm bảng + index + materialized views — impact lên RAM/disk có đáng lo khi scale đến hàng chục ngàn khái niệm + hàng triệu annotations?
Thứ tự triển khai: NĐ-36-01 → Đ36 → Đ38 → Đ39 — có nên thay đổi thứ tự này không?
Ranh giới NĐ-36-01 vs Đ38 vs Đ39: Semantic Annotation thuộc NĐ-36-01 (hạ tầng) hay Đ38 (ứng dụng)? Binding table thuộc ai?

VI. TIÊU CHÍ ĐÁNH GIÁ

Council đánh giá theo:

OR v7.54: 13 NT + 6 CQ + 16 CP
PG FIRST (NT-13): Đã tận dụng tối đa PG native chưa?
Chuẩn ngành: Có áp dụng best practices mới nhất (đến 2025-2026)?
Khả thi: Trên single VPS $8/tháng, PG16 + Qdrant + Docker?
Không phát minh: Mọi kỹ thuật đều đã có người làm, đã chứng minh?

Council Review Request | NĐ-36-01 v1.0 DRAFT | S169 | 2026-04-06