Google Notebooklm 是 Google AI 系列產品的一個強項。
他所生成的資訊圖表，是使用 YAML 語法來描述，但，為什麼不使用 JSON 呢？
NotebookLM 的「資訊圖表」（或是其生成的視覺化架構），我們可以從幾個層面來解析它的技術邏輯：
- 內部處理：YAML 的優勢
- 階層清晰：
- Token 效率：
- 易於修正：
- 前端呈現：從 YAML 到視覺化
- 結構化描述：
- 渲染引擎：
- 視覺化：
雖然 Google 沒有公開 NotebookLM 生成圖表的完整原始碼，但在大型語言模型（LLM）的開發實務中，YAML 確實是描述結構化資訊的首選。原因如下：
資訊圖表本質上是「節點」與「關係」的組合。YAML 的縮排結構非常適合描述這種父子層級。
對於 AI 模型來說，YAML 不需要像 JSON 那樣寫大量的引號和花括號，這能節省 Token 消耗，提高生成速度。
如果 AI 生成的結構有誤，YAML 的格式讓開發者或系統更容易進行微調。
雖然模型可能用 YAML 或 Markdown 來「思考」架構，但你在螢幕上看到的漂亮圖表，通常是經過以下轉換過程：
AI 生成結構化文字（可能是 YAML、JSON 或類似 Mermaid.js 的語法）。
系統將這些文字丟進前端渲染引擎（如 React 繪圖庫、D3.js 或 Canvas）。
最終轉化為你看到的圓圈、方塊與連接線。
為什麼不是 JSON？
在這種「生成式」的場景下，JSON 有一個致命傷：遺失結尾括號。
如果 AI 在生成過程中被中斷，JSON 只要少了一個 } 就會導致整個檔案解析失敗；而 YAML 即使不完整，通常也能解析出前面的部分內容，這對 AI 應用的容錯性更高。
常見的描述語法對比
在自動化生成圖表時，目前的趨勢如下：
| 格式 | 用途 |
|---|---|
| Mermaid | 最常用於 Markdown 內的流程圖與甘特圖。 |
| YAML | 常用於定義複雜的知識圖譜（Knowledge Graph）屬性。 |
| JSON | 常用於系統後端與資料庫之間的資料交換。 |
實例比較：
以一個典型的「知識圖譜（Knowledge Graph）」場景來進行對比。
假設我們要描述「人工智慧（AI）」的幾個核心分支，看看 JSON 與 YAML 在描述這種「圖表結構」時的差異。
- YAML 格式（NotebookLM 偏好的描述方式）
- JSON 格式（API 傳輸的標準方式）
YAML 的結構非常像我們平常做的「大綱筆記」，層級一目了然。
YAML
AI_Knowledge_Graph:
核心領域:
- 機器學習:
定義: 透過數據讓系統自我學習
關鍵技術: [線性回歸, 決策樹, 神經網路]
- 自然語言處理:
定義: 讓機器理解人類語言
應用案例:
- 聊天機器人 (Gemini)
- 翻譯工具
發展趨勢:
- 多模態 AI: 處理文字、圖片與影片
- 邊緣運算: 在本地設備執行 AI
# 註解：這段結構非常適合直接餵給繪圖引擎
JSON 則顯得非常「嚴謹」，每一個細節都被括號保護著，適合程式讀取，但人類閱讀時容易被引號干擾。
JSON
{
"AI_Knowledge_Graph": {
"核心領域": [
{
"名稱": "機器學習",
"定義": "透過數據讓系統自我學習",
"關鍵技術": ["線性回歸", "決策樹", "神經網路"]
},
{
"名稱": "自然語言處理",
"定義": "讓機器理解人類語言",
"應用案例": ["聊天機器人", "翻譯工具"]
}
]
}
}
為什麼說 YAML 更像「資訊圖表」？
從例子可以發現幾個有趣的點：
- 視覺直覺性：
- 清爽度：
- Markdown 友好：
在 YAML 中，你一眼就能看出「機器學習」屬於「核心領域」，因為它縮排在下面。在 JSON 中，你必須找到對應的花括號 { } 才能確定層級。
YAML 節省了大量的雙引號與逗號。對於像 NotebookLM 這種需要處理大量文字的 AI 來說，YAML 的資訊密度更高。
YAML 常被嵌入在 Markdown 檔案的頂部（稱為 Front Matter），這讓它在處理筆記與文件時有天然的優勢。