概要
hanparse 是一個規則式韓語語法分析器（parser）。在本文撰寫時，已完成 詞法分析器（lexer） 的實作。主程式以 JavaScript 開發。
目的
最初的目標是開發一個可部署於 edge function 的韓語語法分析器。
隨著設計演進，專案逐步轉型為 引導分析器（bootstrap parser），用以建立後續語法處理的基礎。
演算法
從語法特性來看，韓語具有以下特徵：
- 格驅動：語序並非最重要，句子功能主要由助詞（josa）決定。
- 謂語優先：句子的核心概念位於謂語（predicate）。
- 後序修飾：助詞與謂語皆位於詞彙之後。
例如，以下韓語句子：
저는 학생입니다.
可拆解為：
(저, Pronoun, "I")
(는, Particle, "topic marker")
(학생, Noun, "student")
(입니다, Predicate, "copula")
(., Punctuation, "statement marker")
由此可知，韓語句子可視為一種 「內容詞 + 文法詞」 的組合。
基於此結構，斷詞演算法設計如下：
- 反向掃描：由後向前進行掃描。
- 最長詞優先：當模式相同時，優先匹配較長的詞。
- 內建優先順序：依照內建規則匹配，初始設定為 文法詞優先於內容詞。
結果
在本文撰寫時，hanparse 已實作超過 30 條規則，皆針對文法詞。
此外，系統內嵌了一個小型 專有名詞詞典，規模不到 10 個詞條，僅作為 PoC（proof of concept）。
目前，hanparse 能夠分析基本韓語句子，但 coverage 仍然不足：
- 多數韓語句型尚未實作。
- 「內容詞 + 文法詞」的假設並非總是成立。
例如，以下句子：
저는 대만 사람이에요.
其中的 대만（Taiwan）屬於專有名詞，因此不符合「內容詞 + 文法詞」的分析假設。
內嵌字典
最初的設計理念是僅處理 文法詞，完全依靠規則來掃描韓語句子。
然而，實際使用 hanparse 後發現，內嵌字典 仍然是必要的。
例如，在本文撰寫時，hanparse 完全無法分析以下名詞片語：
커피 한 잔（a cup of coffee）
因此，分析順序應調整為字典優先於文法詞。
雖然兩者不會同時成立，但若先用字典拆解句子，就能避免誤用文法詞而造成斷詞錯誤。
歧義處理
規則式分析器在 歧義處理 上的表現普遍不佳。
往往需要撰寫大量判斷式，但面對各種 極端案例（corner case） 仍難以妥善處理。
隨著 機械學習 與 深度學習 庫的成熟，規則式分析器的最佳定位逐漸轉向 引導分析器（bootstrap parser）。
其任務在於提供初步結構，待機械學習或深度學習模型完成後續分析，規則式分析器便完成其階段性任務，不再介入句子解析。
使用 JavaScript
這部分算是 技術棧的誤用。
原本的目標是將 hanparse 部署於 edge function 上。
然而，經過實際測試後確認，規則式分析器並不適合作為直接產品，因此以 JavaScript 撰寫並無必要。
由於 hanparse 的定位僅是 前導分析器（bootstrap parser），並非長期使用的程式，重寫也沒有意義。
因此，決定保留現有程式碼，不更換技術棧。
結論
hanparse 作為規則式韓語語法分析器，目前已完成詞法分析器並累積了基本規則。
雖然能處理部分句型，但在 coverage 與 歧義處理 上仍有明顯限制。
因此，hanparse 的最佳定位是 前導分析器（bootstrap parser），用於建立初步結構，後續再交由 機械學習 或 深度學習 模型完成更精確的分析。
未來方向可能包括：
- 擴充 內嵌字典，提升名詞片語的處理能力。
- 增加更多 句型規則，改善 coverage。
- 與 ML/DL 模型結合，讓 hanparse 成為語法分析的前置階段工具。