# 打造會記憶的 AI Codebase 理解引擎：從 AST 到語意圖譜 - 後端里長伯

{%hackmd @JSDC-tw/B1loEcwJZl %}
###### tags: `JSDC2025`

Slido：https://app.sli.do/event/1uQNvh462Y1xXiziQbjwVT

> 開始做筆記

今天分享實作一個有長期記憶的 AI 系統

## 用 PostgreSQL 撐起 AI 程式碼引擎

## 上下文長度爆炸的時候，記憶必須做一些取捨

我們可以：
- Summary：容易忘記細部的規則
- 使用 RAG 處理：無法舉一反三
- Agentic RAG：無法避免過長的 context

## 人類如何系統性管理龐大的知識量

- 綿密的神經網路

## 知識圖譜

1972 年就有這個概念
把一些知識點（節點）用關係（連結）接起來

## 知識圖譜 + LLM = Graph RAG

透過下 prompt 的方式來分解知識點

流程：
1. 命名實體識別
2. 關係抽起
3. 指定輸出格式
4. 警告：不要亂編故事

### 命名實體識別
實體 - 關係

黃董愛吃豆花 ->
「黃董」"豆花"

### 關係抽起
「愛吃」

### Graph RAG：建立圖譜、合併、抽象
萃取出知識節點，合併抽象，一路往上精煉

### 知識點 -> 資料庫
不用全部丟到 LLM, reduce context size (context length explosion)

### Codebase 該怎麼做？

為什麼不把所有的 code 丟進去問 LLM？
-> 因為上下文會長到爆炸
程式碼 10000+

#### 剖析 source code

eq. 有這堆 code：
class + import export + implements, callee, caller

用 AST （Abstract syntax tree）把各種程式語言解析成樹

- Tree-sitter
- LSP

Compiler 已經可以生成語法樹了 為何要用？
講者回: 因為實務上一個專案常同時包含多種語言（TS / YAML / Shell 等），一語言一個 compiler 整合與維護成本很高。
Tree-sitter 能用同一套架構解析多語言，且解析速度快、適合結構分析，某些場景甚至比原生 compiler 還快，所以更適合多語言 codebase。

Tree-sitter
- 多語言支援
- 精準切割
- 高效能（20~30ms 比 compiler 還快）

Symbol Graph - 知識圖譜
- Node / Symbol
- function / method
- class / interface
- constant / variable
- module / file / packageSymbol Graph
- Edge
- calls: function A 呼叫function B
- imports：檔案A匯入檔案B
- defines: class 定義某method
- extends/implements：繼承或實作關係
- references：變數使用
- assigned-to：賦值關係

形成一張語意圖譜（semantic graph）或知識圖譜。
- 圖可以表現出：
- 誰依賴誰
- 誰被誰呼叫
- 哪段程式是孤立的
- 那些地方會受某個改動影響(Impact analysis)

Symbol-based Lookup
- 用點找連結，用連結找另一個點

讓 AI re-ranking 更加精準
- 使用自然語言

LSP

## 檢索 Retrieval
Embedding Model - Biencoder
存入向量資料庫

### Bi-Encorder 的缺點

similar search 比較高的不是最接近的答案

例如問人口
回答裡有「人口」最相似
但最好的答案是回答例如「20 萬人」

請 LLM 幫忙排序（re-ranking）
輸入：最耗時耗資源

取出 encoder

Bi Encoder 是取出向量部分再針對輸出加工

Cross Encoder
我們把標記好的語句放入 encoder, 建立出概念的關聯性

Bi-encoder
只是單純的標示連結

Cross Encoder
算出其他因素

## 串起來！
Retrieval 流程

1. Top K : 取出K個symbol node
2. 找出檢索的起點 : Re-Ranking : K個symbol node做
3. 延伸關聯 : 從symbol node 找 (CTE) 延伸關聯 symbol
4. 生成 : symbol的摘要+原始碼組成prompt丟給LLM

LLM 快，但答案不一定正確
為 Agent 加上思考框架
但為什麼答案還是會錯呢？

[Is Chain-of-Thought Reasoning of LLMs a Mirage? A Data Distribution Lens](https://arxiv.org/abs/2508.01191)

因為思維練並非真正抽象推理能力
而是根據訓練資料進行模式匹配

Thinking Models (Reasoning models)
- 算乘法的具體步驟，切成小塊匹配
- Process Supervision
- 自我反思，步步監督

但本質上還是特徵匹配，不是真正的計算，頂多解決淺層的問題
記憶有限

## 工具使用
（MCP 就是為了這個？）

講者回: 是的，在實作 agent 前，必須先界定 LLM 的能力邊界：LLM 負責理解、推理與決策；
計算、狀態管理與長期記憶則必須交由外部系統處理。

即使使用 Thinking Models，這些限制仍然存在，因此需要透過 function calling、MCP 或 A2A，將不擅長且需要可驗證性的工作外包給工具，否則 agent 無法穩定達成工程需求。

> 聊天區

---

{%hackmd @JSDC-tw/jsdc2025_sponsor %}