Giới thiệu dự án

Trong kỷ nguyên Công nghiệp 4.0, dữ liệu phi cấu trúc dạng văn bản (unstructured text) chiếm hơn 80% tổng khối lượng dữ liệu số toàn cầu. Tuy nhiên, việc chuyển hóa các khối văn bản thô khổng lồ này thành tri thức có cấu trúc mà máy tính có thể hiểu, suy luận và truy vấn là một thách thức lớn trong lĩnh vực Trí tuệ Nhân tạo (AI) và Xử lý Ngôn ngữ Tự nhiên (NLP). Đồ thị tri thức (Knowledge Graph - KG), kể từ khi được Google giới thiệu vào năm 2012 với triết lý "things, not strings", đã trở thành nền tảng cốt lõi cho các hệ thống tìm kiếm thông minh, gợi ý và trả lời câu hỏi tự động.

Đề tài "Xây Dựng Đồ Thị Tri Thức Trong Hệ Thống Thông Tin" (Constructing Knowledge Graphs with Semantic Role Labeling in Information Systems) được thực hiện bởi sinh viên Nguyễn Minh Hiếu (MSSV: 16520399), dưới sự hướng dẫn của PGS. Đỗ Phúc và TS. Ngô Đức Thành tại Trường Đại học Công nghệ Thông tin - ĐHQG TP.HCM (UIT). Đề tài giải quyết các vấn đề cốt lõi sau:

  • Vấn đề thực tiễn (Problem Statement): Các hệ thống trích xuất thông tin mở (Open Information Extraction - OpenIE) hiện nay như IMoJIE, MinIE hay OpenIE-5 thường trích xuất các bộ ba $(h, r, t)$ chứa các cụm từ quá dài ở chủ ngữ hoặc vị ngữ, làm mất đi các siêu dữ liệu ngữ cảnh thiết yếu (thời gian, địa điểm, cách thức, nguyên nhân, mục đích).
  • Mất mát thông tin & Xử lý đồng tham chiếu kém hiệu quả: Việc giải quyết đồng tham chiếu (Coreference Resolution) dạng ngây thơ (naive) thay thế toàn bộ các từ chỉ hộ bằng thực thể đầu tiên dẫn đến mất tính đa dạng ngữ nghĩa và tạo ra các nút trùng lặp, thiếu nhất quán trên đồ thị.
  • Mục tiêu của dự án:
    1. Xây dựng một pipeline tự động chuyển hóa văn bản phi cấu trúc thành Đồ thị tri thức dạng thuộc tính có nhãn (Labeled Property Graph - LPG).
    2. Tích hợp kỹ thuật Gán nhãn vai nghĩa (Semantic Role Labeling - SRL) dựa trên mô hình ngôn ngữ BERT kết hợp Nhận dạng thực thể tên riêng (Named Entity Recognition - NER) và Khử đồng tham chiếu (Coreference Resolution) để bảo toàn tối đa siêu dữ liệu của sự kiện.
    3. Lưu trữ, quản lý và tối ưu hóa truy vấn đồ thị trên cơ sở dữ liệu đồ thị Neo4j thông qua ngôn ngữ Cypher, đồng thời làm giàu thực thể qua liên kết Wikidata.
    4. Xây dựng hệ thống tự động sinh câu hỏi - câu trả lời (Question-Answer Generation) và công cụ tìm kiếm ngữ nghĩa (Semantic QA Search Engine) chứng minh tính ứng dụng của đồ thị tri thức.
  • Phạm vi và giới hạn: Dự án tập trung vào văn bản tiếng Anh thuộc các miền tri thức tổng quát; sử dụng chuẩn chú giải PropBank (với 5 đối số chính và 15 bổ ngữ ARGM-*), triển khai kiểm nghiệm trên các tập dữ liệu chuẩn như OntoNotes 5.0, OIE-2016, CaRB và SQuAD.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Các phương pháp trích xuất bộ ba truyền thống và OpenIE bộc lộ nhiều nhược điểm khi xây dựng đồ thị tri thức tự động từ văn bản phức hợp:

Hệ thống / Giải pháp Cách tiếp cận trích xuất Khả năng giữ ngữ cảnh & Modifier (ARGM-*) Xử lý Coreference Định dạng lưu trữ tri thức Hạn chế chính
OpenIE-5 / MinIE Rule-based & Statistical Parsers Kém (Tách cụm từ cơ học, mất bổ ngữ chỉ phương tiện/mục đích) Không tích hợp sẵn Triples thuần túy $(s, p, o)$ Thực thể bị dài dòng; phân mảnh quan hệ
IMoJIE / SpanOIE Seq2Seq Neural Model & Span Selection Trung bình (Dồn toàn bộ modifier vào Object span) Không tích hợp Flat Tuples Không cấu trúc hóa được thuộc tính sự kiện
text2kg / T2KG NLP Pipeline + DBpedia Mapping Cơ bản (Phụ thuộc dependency tree) Rule-based cơ bản RDF Triplestore Khó truy vấn quan hệ có thuộc tính phức hợp
dstlr Distributed Pipeline (Spark + Solr) Trung bình (Dựa trên OpenIE) Tích hợp cơ bản Neo4j LPG Chưa bóc tách sâu cấu trúc vai nghĩa
SRL-KG (Đề xuất) BERT-based SRL + SpaCy NER + Coref Xuất sắc (Bóc tách chi tiết Temporal, Location, Manner, Purpose...) Neural Coreference Resolution Neo4j Labeled Property Graph (LPG) Cần tài nguyên tính toán cho Transformer

Yêu cầu người dùng & Hệ thống theo mô hình MoSCoW:

  • Must have: Pipeline trích xuất bộ ba kết hợp SRL; module xử lý Coreference Resolution bảo toàn ngữ cảnh; lưu trữ đồ thị trên Neo4j với đầy đủ thuộc tính trên cạnh; module sinh câu hỏi theo vai nghĩa (Who, What, Where, When, Why, How).
  • Should have: Làm giàu thực thể (Entity Enrichment) qua Wikidata API; giao diện trực quan hóa đồ thị tương tác bằng thư viện đồ họa (neo4jd3 / neovis.js).
  • Could have: Tích hợp bộ tìm kiếm câu hỏi - câu trả lời ngữ nghĩa đa chiều; module phân tách câu phức (Sentence Decomposer).
  • Won't have (ở giai đoạn này): Hỗ trợ đa ngôn ngữ thời gian thực (real-time multilingual parsing); cơ chế tự động suy diễn luật logic quy mô lớn (ontology reasoning engine).

Thiết kế hệ thống

Kiến trúc tổng thể của hệ thống gồm 4 phân hệ chính hoạt động theo chuỗi xử lý khép kín:

[ Unstructured Raw Text ]
           │
           ▼
┌────────────────────────────────────────────────────────┐
│ 1. EXTRACTOR SYSTEM                                    │
│   ├── Sentence Decomposer (Phân tách mệnh đề)          │
│   ├── Coreference Resolution (AllenNLP Neural Coref)   │
│   ├── Named Entity Recognition (SpaCy NER 18 Types)    │
│   └── Semantic Role Labeling (BERT-based SRL Engine)   │
└────────────────────────────────────────────────────────┘
           │
           ▼
┌────────────────────────────────────────────────────────┐
│ 2. KNOWLEDGE GRAPH BUILDER & STORAGE                   │
│   ├── Property Triples Generator (JSON Triples)        │
│   ├── Wikidata Entity Linking & Enrichment             │
│   └── Neo4j Graph Database (Cypher Engine & LPG Model) │
└────────────────────────────────────────────────────────┘
           │
           ▼
┌────────────────────────────────────────────────────────┐
│ 3. DOWNSTREAM APPLICATION SERVICES                     │
│   ├── Question-Answer Pair Generator (Rule-based/Roles)│
│   └── Semantic QA Pair Searcher Engine                 │
└────────────────────────────────────────────────────────┘
           │
           ▼
┌────────────────────────────────────────────────────────┐
│ 4. VISUALIZATION & INTERACTIVE DASHBOARD               │
│   ├── Graph Viewer (neo4jd3 / neovis.js)               │
│   └── Interactive Analytics (Entity & Relation Stats)  │
└────────────────────────────────────────────────────────┘

Technology Stack và phiên bản sử dụng:

  • Ngôn ngữ lập trình: Python 3.7+
  • Deep Learning & NLP Frameworks: AllenNLP v1.0.0 (mô hình BERT-based SRL & Coreference Resolution), SpaCy v2.3.x (Mô hình en_core_web_sm / en_core_web_lg hỗ trợ 18 nhãn thực thể), PyTorch v1.5.1, Hugging Face Transformers.
  • Cơ sở dữ liệu đồ thị: Neo4j Community Server v4.1.x, Neo4j Python Driver v4.x.
  • Thư viện Frontend & Trực quan hóa: Neo4jd3, Neovis.js, D3.js v5.x, Bootstrap 4.
  • API & Tích hợp ngoài: Wikidata SPARQL Wrapper / Plasticity API credits.

Mô hình dữ liệu đồ thị (Labeled Property Graph - LPG):

Khác với mô hình RDF chỉ lưu trữ bộ ba thuần túy dẫn đến bùng nổ số lượng nút trung gian khi biểu diễn thuộc tính (reification), mô hình LPG cho phép gán trực tiếp các thuộc tính (key-value pairs) vào cả Nút (Node) và Cạnh (Relationship):

  • Node Labels: :Person, :Organization, :Location, :Event, :Entity...
    • Node Properties: name, wikidata_id, entity_type, mentions_count.
  • Relationship Types: Các vị ngữ chuẩn hóa (ví dụ: :went_to, :founded, :played_as...).
    • Relationship Properties (Metadata từ SRL): temporal (ARGM-TMP), manner (ARGM-MNR), location (ARGM-LOC), purpose (ARGM-PRP), comitative (ARGM-COM), confidence_score.

Phương pháp nghiên cứu (Methodology)

Quy trình phát triển được xây dựng theo mô hình lặp (Iterative Agile Development) với 4 mốc phát triển chính:

  1. Giai đoạn 1 - Xây dựng lõi NLP: Tích hợp và tinh chỉnh các pre-trained models từ AllenNLP và SpaCy; xây dựng module chuyển đổi cấu trúc khung vị ngữ (Predicate-Argument Frame) sang định dạng thuộc tính.
  2. Giai đoạn 2 - Thiết kế schema và nạp dữ liệu Neo4j: Tối ưu hóa các mẫu truy vấn Cypher để thực hiện thao tác Create/Merge idempotent, loại bỏ trùng lặp đồ thị và tích hợp Wikidata ID.
  3. Giai đoạn 3 - Xây dựng downstream tasks: Phát triển giải thuật sinh câu hỏi tự động dựa trên mẫu câu hỏi tương ứng với từng vai nghĩa PropBank; xây dựng cơ chế tìm kiếm câu trả lời.
  4. Giai đoạn 4 - Đánh giá và kiểm thử: Đánh giá độ chính xác trích xuất trên OIE-2016, CaRB và chất lượng câu hỏi trên SQuAD.

Implementation và kết quả

Quy trình phát triển (Development Process)

1. Cơ chế bóc tách ngữ nghĩa dựa trên BERT-SRL

Mô hình sử dụng cấu trúc BERT mã hóa 2 chiều kết hợp với lớp chỉ thị vị ngữ (predicate indicator). Khi nhận một câu, chuỗi đầu vào được định dạng: $$\text{Input} = \text{[CLS]} \circ \text{Sentence} \circ \text{[SEP]} \circ \text{Predicate} \circ \text{[SEP]}$$

Biểu diễn ngữ cảnh từ BERT sau đó được đưa qua lớp BiLSTM và MLP để phân loại từng token theo lược đồ BIO (Begin, Inside, Outside) tương ứng với các đối số PropBank (ARG0 - Tác nhân, ARG1 - Bị tác động, ARG2 - Thuộc tính/Mục tiêu, ARGM-* - Bổ ngữ).

# Trích xuất cấu trúc vị ngữ - đối số sử dụng AllenNLP Predictor
from allennlp.predictors.predictor import Predictor

srl_predictor = Predictor.from_path(
    "https://storage.googleapis.com/allennlp-public-models/bert-base-srl-2020.03.24.tar.gz"
)

sentence = "John went to California with Tim in 2010 by airplane in order to travel."
srl_result = srl_predictor.predict(sentence=sentence)

# Output dạng vai nghĩa:
# [ARG0: John] [V: went] [ARG4: to California] [ARGM-COM: with Tim] 
# [ARGM-TMP: in 2010] [ARGM-MNR: by airplane] [ARGM-PRP: in order to travel]

2. Cấu trúc Property Triples dưới dạng JSON

Từ kết quả SRL và NER, hệ thống sinh ra cấu trúc dữ liệu JSON đóng gói toàn diện thông tin sự kiện:

{
  "subject": {
    "text": "John",
    "type": "PERSON",
    "wikidata_id": "Q12345"
  },
  "predicate": "went_to",
  "object": {
    "text": "California",
    "type": "GPE",
    "wikidata_id": "Q99"
  },
  "properties": {
    "comitative": "with Tim",
    "temporal": "in 2010",
    "manner": "by airplane",
    "purpose": "in order to travel"
  }
}

3. Chuyển hóa và nạp vào Neo4j bằng ngôn ngữ Cypher

Hệ thống sử dụng các mẫu truy vấn Cypher tối ưu hóa để khởi tạo thực thể và quan hệ kèm siêu dữ liệu:

// Nạp nút Subject và Object, thiết lập quan hệ kèm các thuộc tính vai nghĩa
MERGE (s:Person {name: "John"})
ON CREATE SET s.wikidata_id = "Q12345"
MERGE (o:Place {name: "California"})
ON CREATE SET o.wikidata_id = "Q99"
MERGE (s)-[r:went_to]->(o)
SET r.comitative = "with Tim",
    r.temporal = "in 2010",
    r.manner = "by airplane",
    r.purpose = "in order to travel";

4. Giải thuật sinh câu hỏi tự động (Question-Answer Generation)

Hệ thống xác định loại câu hỏi dựa trên ánh xạ trực tiếp từ các vai nghĩa ngữ pháp:

  • ARG0 / ARG1 $\rightarrow$ Câu hỏi Who / What (Subject/Object-based).
  • ARGM-LOC $\rightarrow$ Câu hỏi Where (Địa điểm).
  • ARGM-TMP $\rightarrow$ Câu hỏi When (Thời gian).
  • ARGM-MNR $\rightarrow$ Câu hỏi How (Cách thức/Phương tiện).
  • ARGM-PRP / ARGM-CAU $\rightarrow$ Câu hỏi Why (Mục đích/Nguyên nhân).
def generate_qa_pairs(triple_data):
    qa_list = []
    subj = triple_data["subject"]["text"]
    obj = triple_data["object"]["text"]
    rel = triple_data["predicate"]
    props = triple_data["properties"]

    # Sinh câu hỏi theo Modifier
    if "manner" in props:
        qa_list.append({
            "question": f"How did {subj} {rel} {obj}?",
            "answer": props["manner"]
        })
    if "temporal" in props:
        qa_list.append({
            "question": f"When did {subj} {rel} {obj}?",
            "answer": props["temporal"]
        })
    if "purpose" in props:
        qa_list.append({
            "question": f"Why did {subj} {rel} {obj}?",
            "answer": props["purpose"]
        })
    return qa_list

Kiểm thử và đánh giá (Testing và Validation)

Hệ thống được kiểm thử toàn diện trên các bộ benchmark tiêu chuẩn:

1. Đánh giá hiệu năng trích xuất bộ ba trên OIE-2016 và CaRB

Hiệu năng của mô hình trích xuất SRL-KG được đo lường so sánh với các hệ thống OpenIE hàng đầu:

Mô hình Precision (%) Recall (%) F1-Score (%) trên OIE-2016 F1-Score (%) trên CaRB
OpenIE-4 54.2 48.6 51.2 46.8
MinIE 61.5 45.3 52.2 47.5
RnnOIE 58.7 52.1 55.2 50.4
IMoJIE 64.8 62.1 63.4 53.5
SRL-KG (Thesis Proposal) 68.2 64.7 66.4 56.8

Ghi chú: Trên tập dữ liệu benchmark OIE-2016 (3.200 câu) và CaRB (641 câu), mô hình đề xuất đạt F1-score vượt trội nhờ khả năng bóc tách chính xác ranh giới của các thực thể và đưa các thành phần phụ ngữ vào thuộc tính của cạnh thay vì nhồi nhét vào đối số.

2. Độ chính xác của mô hình SRL và sinh câu hỏi

  • Mô hình BERT-SRL (Ontonotes 5.0): Đạt F1-score kiểm thử 86.49%, chứng minh độ tin cậy vượt trội trong việc phân định các nhãn ARG0-ARG5ARGM-*.
  • Chất lượng sinh câu hỏi (BLEU Score trên SQuAD): Đạt điểm BLEU-4 là 21.4, vượt mức trung bình của các mô hình sinh câu hỏi dựa trên mẫu rule-based truyền thống (~15.2) nhờ khai thác triệt để các bổ ngữ sự kiện trên đồ thị tri thức.

Kết quả đạt được

  • Xây dựng thành công pipeline trích xuất tri thức tự động từ văn bản hoàn chỉnh từ End-to-End.
  • Trực quan hóa đồ thị động với khả năng lọc thực thể, quan hệ và tra cứu nhanh các thông số thống kê đồ thị (Degree distribution, Entity types).
  • Hoàn thiện công cụ Semantic QA Engine cho phép nhập văn bản thô, tự động dựng đồ thị và trả về danh sách câu hỏi - đáp hoàn chỉnh phục vụ đánh giá năng lực đọc hiểu văn bản của máy tính.

Đổi mới và đóng góp

  1. Khắc phục triệt để vấn đề mất mát thông tin (Information Loss): Thay vì loại bỏ hoặc gộp thô các cụm từ chỉ thời gian, địa điểm, phương tiện như các hệ thống OpenIE truyền thống, giải pháp sử dụng SRL để cấu trúc hóa chúng thành các trường siêu dữ liệu (Properties) trên quan hệ của Labeled Property Graph.
  2. Cải tiến cơ chế xử lý đồng tham chiếu (Intelligent Coreference Mapping): Thay vì ghi đè thô bạo (naive replacement) làm biến dạng văn bản gốc, hệ thống xây dựng bảng ánh xạ thực thể (Coreference Cluster Table), bảo toàn mọi biến thể đề cập (mentions) và liên kết chúng về một thực thể trung tâm duy nhất trên đồ thị.
  3. Mô hình sinh câu hỏi ngữ nghĩa toàn diện (Semantic-driven Question Generation): Đóng góp giải thuật sinh câu hỏi đa dạng (Who, What, Where, When, Why, How) dựa trên cấu trúc vai nghĩa ngữ pháp, tạo bước đệm hoàn hảo cho các hệ sinh thái EdTech và hệ thống hỏi đáp tự động (Automated QA Systems).
  4. Mã nguồn mở và khả năng tái sử dụng: Cung cấp toàn bộ mã nguồn pipeline tích hợp Python, AllenNLP, SpaCy và Neo4j, đóng góp cho cộng đồng nghiên cứu NLP và ứng dụng hệ thống thông tin.

Ứng dụng thực tế và triển khai

Trường hợp sử dụng thực tế (Use Cases)

[ Unstructured Documents / News / Reports ]
                    │
                    ▼
      ┌───────────────────────────┐
      │ SRL-KG Processing Engine  │
      └─────────────┬─────────────┘
                    │
       ┌────────────┼────────────┐
       ▼            ▼            ▼
 ┌───────────┐┌───────────┐┌───────────┐
 │ Enterprise││  EdTech   ││Bio-Medical│
 │ Knowledge ││  Auto-Quiz││& Legal Doc│
 │Discovery  ││ Generation││ Analysis  │
 └───────────┘└───────────┘└───────────┘
  1. Hệ thống quản trị tri thức doanh nghiệp (Enterprise Knowledge Management): Tự động phân tích hợp đồng, email, biên bản cuộc họp và báo cáo tài chính thành đồ thị tri thức tập trung; cho phép lãnh đạo truy vấn quan hệ đối tác, dòng tiền và sự kiện theo trục thời gian.
  2. Hệ thống tạo đề thi và ôn tập tự động (EdTech Automated Quiz Generation): Tự động đọc sách giáo khoa, tài liệu học tập để sinh bộ câu hỏi trắc nghiệm/tự luận đa dạng phục vụ đào tạo trực tuyến.
  3. Phân tích văn bản pháp lý và y sinh (Legal & Biomedical Intelligence): Trích xuất mạng lưới quan hệ giữa điều luật - hành vi - chế tài hoặc giữa triệu chứng - hoạt chất - phác đồ điều trị với độ chính xác thuộc tính cao.

Yêu cầu triển khai và khả năng mở rộng

  • Hạ tầng đề xuất:
    • CPU: Intel Xeon / AMD EPYC (tối thiểu 8 cores).
    • RAM: 32 GB trở lên (đáp ứng nạp mô hình ngôn ngữ và buffer Neo4j).
    • GPU: NVIDIA Tesla T4 / RTX 2080Ti trở lên (VRAM $\ge$ 11GB) để tăng tốc độ inference của BERT.
    • Lưu trữ: 100 GB SSD NVMe.
  • Hiệu quả đầu tư (Cost-Benefit & ROI): Giảm 75% thời gian gán nhãn và cấu trúc hóa dữ liệu thủ công của chuyên viên phân tích; tăng tốc độ truy xuất thông tin liên ngành từ hàng giờ xuống vài mili-giây qua truy vấn Cypher.

Hạn chế và hướng phát triển

Hạn chế kỹ thuật

  • Tốc độ xử lý trên CPU: Mô hình BERT-SRL và Neural Coreference của AllenNLP yêu cầu năng lực tính toán lớn, tốc độ xử lý trên CPU thông thường còn chậm (~1.5 - 2.5 giây/câu).
  • Phụ thuộc vào ngôn ngữ tiếng Anh: Pipeline hiện tại dựa trên các mô hình ngôn ngữ và tập dữ liệu chuẩn tiếng Anh (PropBank, OntoNotes 5.0).
  • Câu có cấu trúc lồng nhau quá phức tạp: Đối với các câu có nhiều tầng mệnh đề quan hệ phụ thuộc chéo, module phân tách câu có thể gặp sai sót trong việc gán nhãn ranh giới vị ngữ.

Hướng phát triển trong tương lai

  • Hỗ trợ tiếng Việt: Huấn luyện mô hình PhoBERT-SRL trên tập ngữ liệu tiếng Việt (Vietnamese PropBank) để ứng dụng trực tiếp cho các hệ thống thông tin trong nước.
  • Tích hợp Graph Neural Networks (GNN): Áp dụng mô hình đồ thị tích chập (GCN/GAT) trên Neo4j để thực hiện bài toán dự đoán liên kết còn thiếu (Link Prediction) và suy diễn tri thức mới (Knowledge Reasoning).
  • Tối ưu hóa thời gian thực (Real-time Processing): Chuyển đổi mô hình sang định dạng ONNX/TensorRT và áp dụng kỹ thuật chưng cất tri thức (Knowledge Distillation) với DistilBERT/MobileBERT để triển khai trên môi trường microservices chịu tải cao.

Đối tượng hưởng lợi

┌─────────────────────────────────────────────────────────────────────────┐
│                           ĐỐI TƯỢNG HƯỞNG LỢI                           │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │
     ┌──────────────────┬────────────┴───────┬──────────────────┐
     ▼                  ▼                    ▼                  ▼
┌──────────────┐ ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│  SINH VIÊN   │ │  LẬP TRÌNH   │    │ DOANH NGHIỆP │    │  NHÀ NGHIÊN  │
│              │ │     VIÊN     │    │              │    │     CỨU      │
│ Tài liệu mẫu │ │ Source code  │    │ Tự động hóa  │    │ Nền tảng     │
│ chuẩn mực về │ │ & Pipeline   │    │ 75% cấu trúc │    │ benchmark    │
│ NLP & Neo4j  │ │ tích hợp     │    │ dữ liệu thô  │    │ SRL + LPG    │
└──────────────┘ └──────────────┘    └──────────────┘    └──────────────┘
  • Sinh viên & Học viên cao học: Cung cấp tài liệu tham khảo bài bản, chi tiết từ lý thuyết ngôn ngữ học hình thức (PropBank, FrameNet) đến cách thức triển khai thực tế đồ thị tri thức với cơ sở dữ liệu Neo4j.
  • Kỹ sư phần mềm & AI Engineers: Nắm vững mã nguồn mẫu, cách tích hợp các thư viện NLP hiện đại (AllenNLP, SpaCy) với Graph Database qua chuẩn LPG.
  • Doanh nghiệp & Tổ chức: Sở hữu giải pháp kiến trúc có khả năng chuyển đổi kho dữ liệu văn bản phi cấu trúc thành tài sản tri thức có thể khai phá và sinh lời.
  • Cộng đồng nghiên cứu khoa học: Cung cấp phương pháp luận và dữ liệu thực nghiệm so sánh chi tiết giữa các giải pháp OpenIE và tiếp cận SRL trên các benchmark chuẩn.

Câu hỏi thường gặp

1. Yêu cầu hệ thống tối thiểu để triển khai pipeline này là gì?

Để chạy thử nghiệm (testing), hệ thống cần tối thiểu 8GB RAM, CPU 4-core và cài đặt sẵn Python 3.7+, Java Runtime Environment 11+ (cho Neo4j Server). Để chạy triển khai thực tế (production) với tốc độ cao, khuyến nghị sử dụng máy chủ có GPU NVIDIA (VRAM tối thiểu 8GB - 16GB) để tối ưu hóa thời gian inference của các mô hình BERT.

2. Sự khác biệt cốt lõi giữa mô hình RDF và Labeled Property Graph (LPG) trong đề tài là gì?

Mô hình RDF biểu diễn dữ liệu bằng các bộ ba $(s, p, o)$ thuần túy; khi muốn gán thêm thuộc tính (ví dụ: ngày đi, phương tiện) cho một mối quan hệ, RDF buộc phải dùng kỹ thuật reification (tạo thêm node ảo trung gian), làm tăng độ phức tạp của đồ thị. Ngược lại, mô hình LPG của Neo4j cho phép lưu trữ trực tiếp các cặp key-value lên chính cạnh nối, giúp việc truy vấn ngữ nghĩa bằng Cypher trở nên ngắn gọn, tự nhiên và tối ưu hiệu năng bộ nhớ hơn rất nhiều.

3. Hệ thống xử lý thế nào khi gặp các thực thể mới không có trong Wikidata?

Khi phát hiện thực thể mới, module NER vẫn nhận diện và gán nhãn thực thể dựa trên ngữ cảnh văn bản (ví dụ: PERSON, ORG, GPE). Hệ thống sẽ khởi tạo một nút mới trong Neo4j với trường wikidata_id: null và lưu trữ toàn bộ các thuộc tính ngữ cảnh bóc tách được từ SRL. Đồ thị vẫn đảm bảo tính toàn vẹn và có thể liên kết bù (entity linking update) trong tương lai.

4. Chi phí duy trì và khả năng mở rộng hệ thống như thế nào?

Neo4j Community Edition là mã nguồn mở (hoàn toàn miễn phí bản quyền). Pipeline trích xuất bằng Python có thể đóng gói thành các Docker container chạy phi tập trung (stateless workers). Khi khối lượng văn bản tăng cao, hệ thống có thể mở rộng theo chiều ngang (scale-out) bằng cách kết hợp hàng đợi tin nhắn (RabbitMQ/Kafka) để phân phối tác vụ trích xuất cho nhiều GPU worker trước khi nạp batch vào cụm Neo4j.

5. Làm thế nào để điều chỉnh hệ thống cho một miền tri thức chuyên biệt (ví dụ: Y tế, Luật)?

Người dùng chỉ cần thực hiện 2 bước tùy biến:

  1. Thay thế hoặc fine-tune mô hình SpaCy NER trên tập dữ liệu thực thể chuyên ngành (ví dụ: bệnh học, điều luật).
  2. Bổ sung hoặc ánh xạ các khung vị ngữ chuyên ngành vào danh mục PropBank Frame files để module SRL nhận diện chính xác các quan hệ đặc thù của miền nghiệp vụ đó.

Kết luận

Khóa luận tốt nghiệp "Xây Dựng Đồ Thị Tri Thức Trong Hệ Thống Thông Tin" của tác giả Nguyễn Minh Hiếu đã giải quyết thành công bài toán chuyển đổi văn bản phi cấu trúc thành Đồ thị tri thức dạng thuộc tính có nhãn (LPG) một cách tự động và chuẩn xác. Bằng việc tiên phong kết hợp kỹ thuật Gán nhãn vai nghĩa (SRL) trên nền tảng BERT với Nhận dạng thực thể tên riêng và Khử đồng tham chiếu, công trình đã khắc phục triệt để hiện tượng mất mát thông tin ngữ cảnh – vốn là yếu điểm cố hữu của các phương pháp OpenIE truyền thống.

Kết quả kiểm nghiệm ấn tượng trên các tập dữ liệu OIE-2016, CaRB và OntoNotes 5.0 cùng các ứng dụng mở rộng như sinh câu hỏi tự động và tìm kiếm ngữ nghĩa đã khẳng định giá trị khoa học và tính ứng dụng thực tiễn cao của đề tài. Đây là nguồn tài liệu tham khảo chất lượng cao và là nền tảng kỹ thuật vững chắc cho các nhà nghiên cứu, kỹ sư và doanh nghiệp đang trên hành trình khai phá giá trị từ dữ liệu văn bản lớn.