# Vì sao Pattern không thể bỏ qua Semantic khi phân tích ngữ pháp?
**Canonical:** https://wiki.quizzman.com/wiki/vi-sao-pattern-khong-the-bo-qua-semantic-khi-phan-tich-ngu-phap
**Author:** virgoricomp_102605  |  **Published:** 2026-09-27  |  **Updated:** 2026-09-27
**Tags:** Giáo dục, Khoa học, Ngôn ngữ

> Trong phân tích ngữ pháp, một Pattern (mẫu cấu trúc) có thể giúp nhận ra những cấu trúc có khả năng xuất hiện. Tuy nhiên, sự tương đồng về hình thức không đủ để chứng minh rằng hai biểu thức có cùng cấu trúc cú pháp. Một Pattern trước hết chỉ cung cấp một Candidate Parse (cách phân tích ứng viên).

# Vì sao Pattern không thể bỏ qua Semantic khi phân tích ngữ pháp?

Trong phân tích ngữ pháp, một **Pattern (mẫu cấu trúc)** có thể giúp nhận ra những cấu trúc có khả năng xuất hiện. Tuy nhiên, sự tương đồng về hình thức không đủ để chứng minh rằng hai biểu thức có cùng cấu trúc cú pháp.

Một Pattern trước hết chỉ cung cấp một **Candidate Parse (cách phân tích ứng viên)**.

Ví dụ, từ chuỗi:

A + B + C


có thể đề xuất:

A + [B + C]


Nhưng cách phân tầng này đặt ra những câu hỏi tiếp theo:

B và C có thực sự tạo thành một constituent?

B và C có quan hệ cú pháp gì?

Quan hệ ngữ nghĩa giữa chúng là gì?

C đang predicated về B hay về một thành phần khác?


Nếu những câu hỏi này chưa được giải quyết, `[B + C]` vẫn chỉ là một cấu trúc ứng viên.

Đây là điểm mà **Semantic Analysis (phân tích ngữ nghĩa)** trở thành một phần quan trọng của quá trình phân tích.



## 1. Pattern nhận diện hình thức, không tự chứng minh cấu trúc

Giả sử đã biết một cấu trúc:

A + [B + C]


và gặp một biểu thức mới có cùng hình thức tuyến tính:

X + Y + Z


Không thể chỉ từ sự tương đồng đó suy ra:

X + [Y + Z]


hay:

Relation(Y, Z)
=
Relation(B, C)


Hai biểu thức có thể giống nhau ở bề mặt nhưng khác nhau về:

**Constituency (quan hệ thành tố)**;
**Syntactic Relations (quan hệ cú pháp)**;
**Semantic Roles (vai nghĩa)**;
**Semantic Relations (quan hệ ngữ nghĩa)**.

Do đó:

Same Surface Pattern
≠
Same Structure


Pattern có giá trị như một phương tiện phát hiện khả năng phân tích, không phải bằng chứng cuối cùng cho cấu trúc.



## 2. Góc nhìn Compiler: Parser chấp nhận chưa có nghĩa chương trình hợp lệ

Trong **Compiler (trình biên dịch)**, sự khác biệt giữa cấu trúc và ngữ nghĩa thể hiện rất rõ.

Xét biểu thức giả định:

"hello" - 5


Nếu Grammar (ngữ pháp hình thức) cho phép phép trừ nhận hai biểu thức ở hai phía:

Expression
→ Expression "-" Expression


thì **Parser (bộ phân tích cú pháp)** vẫn có thể xây dựng một **Abstract Syntax Tree – AST (cây cú pháp trừu tượng)**:

Subtract
├── String("hello")
└── Integer(5)


Ở tầng cú pháp, cấu trúc đã được xác định:

Operator: -
Left:  String("hello")
Right: Integer(5)


Nhưng quá trình phân tích chưa kết thúc.

**Semantic Analysis (phân tích ngữ nghĩa)** và **Type Checking (kiểm tra kiểu)** tiếp tục kiểm tra liệu các thành phần có đáp ứng những ràng buộc của phép toán hay không.

Nếu toán tử `-` chỉ được định nghĩa cho các kiểu số:

Subtract(Number, Number) → Number


thì:

Subtract(String, Integer)


không đáp ứng điều kiện đó.

Parser có thể dựng được cây.

Nhưng cây cú pháp đó không tạo thành một biểu thức hợp lệ theo hệ thống kiểu của ngôn ngữ.

Có thể tóm tắt:

Tokens
↓
Parser
↓
AST
↓
Semantic Analysis
↓
Type Checking
↓
Valid / Invalid


Do đó:

Syntactically Constructible
≠
Semantically Valid




## 3. Tại sao phép đối chiếu này hữu ích với ngôn ngữ tự nhiên?

Ngôn ngữ tự nhiên không phải ngôn ngữ lập trình và không vận hành bằng một Type System (hệ thống kiểu) được đặc tả chính thức.

Tuy nhiên, hai lĩnh vực có chung một vấn đề phương pháp:

Từ một chuỗi tuyến tính, cần xác định những thành phần nào kết hợp với nhau và các thành phần đó có quan hệ gì.

Một câu tự nhiên có thể cho phép nhiều **Candidate Parses (cách phân tích ứng viên)**:

Input
│
├── Parse A
│
├── Parse B
│
└── Parse C


Việc một Parse phù hợp với một Pattern đã biết chỉ chứng minh:

Có lý do để xem xét cách phân tích này.

Nó chưa chứng minh:

Đây là cấu trúc của câu.

Cần tiếp tục kiểm tra:

Constituency
↓
Syntactic Relations
↓
Semantic Relations


Đặc biệt, nếu một cách phân tầng làm mất hoặc thay đổi những quan hệ ngữ nghĩa cơ bản của câu, đó là dấu hiệu cần xem xét lại cách phân tích.



## 4. Một ví dụ: 我送他回国

Xét câu:

我送他回国。
Tôi tiễn anh ấy về nước.


Trên bề mặt, có thể nhận ra chuỗi:

他 + 回国


và `他回国` tự thân có thể tạo thành một cấu trúc chủ-vị:

他回国。
Anh ấy về nước.


Nếu chỉ dựa vào Pattern, một cách phân tích có thể được đề xuất:

我 + 送 + [他回国]


tức:

Subject
├── 我
└── Predicate
├── Verb: 送
└── Object: 他回国


Về mặt hình thức, cách phân tích này có vẻ khả thi.

Nhưng Semantic Relations của câu cho thấy một vấn đề.



## 5. Ai được 送? Ai 回国?

Có thể kiểm tra bằng hai quan hệ đơn giản.

### 送谁？

送谁？
Tiễn ai?

→ 他


Quan hệ thứ nhất:

送(我, 他)


Trong đó:

我 = 施事
他 = 受事 / đối tượng của 送


### 谁回国？

谁回国？
Ai về nước?

→ 他


Quan hệ thứ hai:

回国(他)


`他` đồng thời là thành phần mang quan hệ chủ thể ngữ nghĩa với `回国`.

Như vậy, cấu trúc ngữ nghĩa không đơn giản là:

送(我, 他回国)


mà tồn tại hai dependency:

送
├── 我
└── 他
│
└── 回国


Hay biểu diễn bằng quan hệ:

送(我, 他)
回国(他)


`他` đồng thời tham gia vào hai quan hệ.



## 6. 兼语: khi một thành phần tham gia hai quan hệ

Trong cách phân tích truyền thống của ngữ pháp tiếng Hán, hiện tượng trên liên quan đến **兼语 (kiêm ngữ; pivot)**.

Có thể biểu diễn:

我送他回国
│ │  │ │
│ │  │ └── Predicate
│ │  └──── 兼语
│ └─────── Verb
└───────── Subject


Quan trọng nhất là vị trí của `他`:

他
/  \
/    \
ObjectOf  SubjectOf
↓         ↓
送        回国


Hay:

Sentence
├── Subject: 我
└── Predicate
├── Verb: 送
├── 兼语: 他
│   ├── ObjectOf → 送
│   └── SubjectOf → 回国
└── Predicate: 回国


Tên gọi `兼语` phản ánh chính đặc điểm này: một thành phần đồng thời tham gia vào hai quan hệ cú pháp-ngữ nghĩa trong cấu trúc.

Điểm quan trọng ở đây không phải việc phải sử dụng chính thuật ngữ `兼语`.

Điểm quan trọng là:

Một cách phân tích phải bảo toàn và giải thích được những quan hệ thực sự tồn tại giữa các thành phần.



## 7. Vì sao `[他回国]` chưa đủ để giải thích câu?

`他回国` hoàn toàn có thể là một cấu trúc chủ-vị trong:

他回国。


Điều đó không có nghĩa mọi lần chuỗi:

他 + 回国


xuất hiện liên tiếp đều phải được đóng thành cùng một constituent:

[他回国]


Trong:

我送他回国。


`他` còn có quan hệ trực tiếp với `送`.

Nếu chỉ dựng:

我 + 送 + [他回国]


và coi toàn bộ `[他回国]` đơn giản là tân ngữ của `送`, phân tích đó có nguy cơ che khuất quan hệ:

送谁？
→ 他


Đây là một ví dụ rõ của nguyên tắc:

Possible Constituent
≠
Correct Constituent in Every Context


Một chuỗi có thể tạo thành constituent trong môi trường A nhưng không vì vậy mà tự động có cùng cấu trúc trong môi trường B.



## 8. Semantic Relations có thể ràng buộc Candidate Parse

Có thể xem quá trình phân tích như một chuỗi kiểm tra:

Input
↓
Pattern Recognition
↓
Candidate Parse
↓
Constituency
↓
Syntactic Relations
↓
Semantic Relations
↓
Interpretation


Giả sử Candidate Parse đưa ra:

[A + B]


nhưng Semantic Analysis cho thấy:

Relation(A, C)
Relation(B, D)


hoặc một thành phần bên trong `[A + B]` còn phụ thuộc trực tiếp vào thành phần nằm ngoài constituent được đề xuất.

Khi đó cần kiểm tra lại:

boundary của constituent;
loại cấu trúc;
dependency;
hoặc chính mô hình phân tích đang sử dụng.

Semantic không thay thế Syntax.

Semantic **ràng buộc việc lựa chọn giữa các phân tích cú pháp có khả năng cạnh tranh**.



## 9. Semantic Constraints và Type Constraints

Ở đây có thể sử dụng thêm một phép đối chiếu với khoa học máy tính.

Trong một ngôn ngữ lập trình có kiểu:

Function : InputType → OutputType


một hàm có thể đặt điều kiện lên loại đối số mà nó nhận.

Ví dụ giả định:

sqrt(Number) → Number


thì:

sqrt(25)


phù hợp với constraint.

Trong khi:

sqrt("hello")


không phù hợp.

Ngôn ngữ tự nhiên cũng có những **Semantic Constraints (ràng buộc ngữ nghĩa)**, dù chúng không tạo thành một Type System cứng như trong programming language.

Ví dụ ở mức khái quát:

重要(Event / Proposition) ✓
important(event / proposition)

好听(Auditory Entity) ✓
pleasant-to-hear(auditory entity)


Một predicate không kết hợp hoàn toàn tùy ý với mọi loại semantic argument.

Vì vậy, khi một phân tích đề xuất:

Predicate(X)


ta có thể hỏi:

X có phải loại thực thể mà Predicate này thông thường có thể predicated about hay không?

Đây là **Selectional Restriction / Selectional Preference (hạn chế hoặc khuynh hướng lựa chọn ngữ nghĩa)**.

Nó cung cấp thêm bằng chứng để đánh giá một Candidate Parse.



## 10. Nhưng ngôn ngữ tự nhiên không phải một Type System cứng

Phép đối chiếu với compiler có giới hạn.

Trong programming language, nếu đặc tả quy định:

Number - Number


thì:

String - Number


có thể bị từ chối một cách tuyệt đối.

Ngôn ngữ tự nhiên linh hoạt hơn nhiều.

Con người có thể sử dụng:

**Metaphor (ẩn dụ)**;
**Metonymy (hoán dụ)**;
**Semantic Coercion (cưỡng ép/chuyển đổi cách diễn giải ngữ nghĩa)**;
**Ellipsis (tỉnh lược)**;
ngữ cảnh;
tri thức thế giới;
ngữ điệu.

Ví dụ một Predicate vốn thường áp dụng cho một loại thực thể vẫn có thể được sử dụng với một biểu thức thuộc loại khác nếu người nghe có thể suy ra một interpretation thích hợp.

Do đó:

Semantic Mismatch


trong natural language không nhất thiết dẫn tới:

INVALID


như compiler.

Nó có thể dẫn tới:

Semantic Mismatch
↓
Context / Coercion / Metonymy
↓
Alternative Interpretation


Đây là giới hạn quan trọng của phép đối chiếu.



## 11. Semantic không thay thế Syntax

Nếu Pattern không đủ, điều đó cũng không có nghĩa có thể bỏ Syntax và chỉ dựa vào nghĩa.

Một câu “có vẻ hiểu được” không chứng minh bất kỳ cách phân tầng nào cũng đúng.

Ví dụ, từ một interpretation:

Meaning M


không thể tùy ý suy ngược:

Meaning M
→
Structure X


nếu không có bằng chứng cấu trúc.

Phân tích cần đồng thời thỏa mãn:

Surface Evidence
+
Structural Evidence
+
Syntactic Relations
+
Semantic Relations


Do đó, quan hệ đúng hơn là:

Syntax ↔ Semantics


chứ không phải:

Syntax → Semantics only


hay:

Semantics → Syntax only


Hai tầng cung cấp những loại bằng chứng khác nhau cho cùng một phân tích.



## 12. Một Parse tốt phải bảo toàn các quan hệ

Có thể đặt một tiêu chí thực dụng:

Nếu thay đổi cách phân tầng, những quan hệ cú pháp và ngữ nghĩa quan trọng của câu có còn được giải thích hay không?

Với:

我送他回国。


ta biết ít nhất:

送(我, 他)
回国(他)


Một phân tích tốt phải giải thích được cả hai.

Nếu một Parse chỉ giải thích:

回国(他)


nhưng làm mất:

送(我, 他)


thì Parse đó chưa giải thích đầy đủ câu.

Ngược lại, nếu chỉ nhận ra:

送(我, 他)


mà không giải thích tại sao `他` lại liên hệ với `回国`, phân tích cũng chưa hoàn chỉnh.

Có thể hình thức hóa yêu cầu:

Candidate Parse
↓
Preserve Syntactic Relations?
↓
Preserve Semantic Relations?
↓
Explain the Interpretation?




## 13. Pattern vẫn rất quan trọng

Việc Pattern không đủ không có nghĩa Pattern vô ích.

Pattern giúp:

nhận diện cấu trúc có khả năng xuất hiện;
tìm các câu tương tự;
hình thành Candidate Parse;
xây dựng quy tắc;
phát hiện bất thường;
so sánh phân bố trong corpus.

Trong compiler, Grammar Rule cũng cực kỳ quan trọng.

Không có Grammar, Parser thậm chí không biết phải dựng cây nào.

Nhưng:

Grammar
↓
Parse


không phải toàn bộ pipeline.

Tương tự, trong phân tích ngôn ngữ tự nhiên:

Pattern
↓
Candidate Structure


chỉ là một phần của quá trình.

Sai lầm xảy ra khi:

Pattern
=
Proof


thay vì:

Pattern
=
Evidence for a Candidate Analysis




## 14. Từ Pattern Matching đến Grammatical Analysis

Có thể tổng hợp quá trình thành một pipeline:

Linguistic Data
↓
Pattern Recognition
↓
Candidate Structures
↓
Hierarchical Analysis
↓
Syntactic Relations
↓
Semantic Relations
↓
Context / Prosody
↓
Grammatical Analysis


Không phải mọi trường hợp đều cần thực hiện tuần tự từng bước theo đúng thứ tự này.

Đây là một **mô hình phương pháp luận**, không phải một thuật toán chính thức của ngôn ngữ tự nhiên.

Giá trị của nó nằm ở việc ngăn một bước suy luận quá nhanh:

Tôi đã thấy Pattern này trước đây
↓
Tôi biết cấu trúc của câu


Thay vào đó:

Tôi đã thấy Pattern này trước đây
↓
Tôi có một Candidate Parse
↓
Bây giờ cần kiểm tra nó




## 15. Ba mệnh đề cần phân biệt

Có thể rút gọn toàn bộ vấn đề thành ba mệnh đề:

Pattern ≠ Structure


Một mẫu bề mặt không tự xác định cấu trúc tầng bậc.

Structure ≠ Semantic Validity


Một cấu trúc có thể dựng được không có nghĩa mọi quan hệ ngữ nghĩa mà nó tạo ra đều phù hợp.

Possible Parse ≠ Established Analysis


Một cách phân tích khả thi không tự động trở thành cách phân tích đã được chứng minh.

Ba distinction này đặc biệt quan trọng khi một câu có nhiều cách phân tầng cạnh tranh.



## 16. Từ Compiler trở lại ngữ pháp tự nhiên

Compiler cung cấp một phép đối chiếu hữu ích vì nó buộc các tầng phân tích phải được biểu diễn rõ ràng:

Source
↓
Lexer
↓
Tokens
↓
Parser
↓
AST
↓
Semantic Analysis
↓
Type Checking


Trong nghiên cứu ngôn ngữ tự nhiên, không tồn tại một pipeline cứng hoàn toàn tương đương.

Tuy nhiên, cách tư duy phân tầng vẫn hữu ích:

Utterance
↓
Units
↓
Patterns
↓
Candidate Structures
↓
Syntactic Relations
↓
Semantic Relations
↓
Interpretation


Điểm chung không phải là:

Natural language hoạt động giống programming language.

Mà là:

**Một cấu trúc hình thức cần được kiểm tra bằng các quan hệ mà nó tạo ra.**

Compiler khiến nguyên tắc này dễ nhìn thấy hơn vì nếu AST đúng hình thức nhưng operand sai type, hệ thống có thể báo lỗi ngay.

Natural language không đơn giản như vậy, nhưng câu hỏi phương pháp vẫn còn nguyên:

Cây này dựng được.

Nhưng các quan hệ bên trong cây
có thực sự giải thích câu hay không?




## 17. Kết luận

Pattern là một công cụ quan trọng trong phân tích ngữ pháp. Nó giúp nhận diện những cấu trúc có khả năng tồn tại và tạo ra các Candidate Parses để kiểm tra.

Nhưng Pattern không tự chứng minh Structure.

Structure cũng không thể được đánh giá hoàn toàn độc lập với Semantic Relations.

Ví dụ:

我送他回国。


cho thấy vì sao điều này quan trọng.

Chỉ nhận ra:

他 + 回国


là một Pattern chủ-vị có thể khiến ta đề xuất:

[他回国]


như một constituent.

Nhưng quan hệ:

送(我, 他)
回国(他)


cho thấy `他` đồng thời liên hệ với cả `送` và `回国`. Chính quan hệ này là cơ sở để hiểu cấu trúc 兼语 và cho thấy tại sao Pattern bề mặt không thể thay thế phân tích quan hệ.

Quy trình hợp lý hơn là:

Pattern
↓
Candidate Structure
↓
Hierarchical Structure
↓
Syntactic Relations
↓
Semantic Relations
↓
Interpretation


Vì vậy:

Pattern ≠ Structure

Structure ≠ Semantic Validity

Possible Parse ≠ Established Analysis


Bài tiếp theo sẽ áp dụng trực tiếp phương pháp này vào `他学习很好` và `他唱歌很好听`: hai biểu thức có bề mặt tưởng như tương tự, nhưng `学习` và `唱歌` có thực sự có cùng tính chất cú pháp hay không, `很好` và `很好听` đang predicated về thành phần nào, và liệu một Pattern giống nhau có đủ để đưa cả hai vào cùng một phân tích ngữ pháp hay không.