AI Chatbot 的設計核心理念：從單輪問答到具備上下文的站內知識助理

這個 AI Chatbot 的設計目標，不是做一個泛用型、無邊界的聊天機器人，而是建立一個**以網站內
容為知識來源、能理解對話延續關係、並保持回答可控性**的站內 AI 助理。

換句話說，它的核心任務不是「什麼都回答」，而是「根據站內資料，把使用者的問題轉譯成可被檢
索與回答的知識需求」。

---

## 1. 問題定義：一般聊天機器人為什麼不夠用

如果只把使用者當前輸入的一句話直接丟給模型，最常見的問題有三個：

1. 缺乏知識邊界
模型容易根據語言習慣補全答案，產生看似合理但其實不在網站內容中的資訊。

2. 缺乏上下文延續
使用者很少每一輪都完整描述問題，常見問法會是：
- 「那他做過哪些 AI 專案？」
- 「上一篇文章有提到嗎？」
- 「那這個經驗跟前面那個有什麼差別？」

如果系統只看單輪輸入，這些句子其實都是不完整的。

3. 回答風格不穩定
沒有約束的模型可能在簡單問題上講太長，在模糊問題上講太滿，導致使用體驗不穩定。

因此，這個 chatbot 的設計重點不是單純串接 LLM API，而是處理三件事：

- 如何限制回答來源
- 如何補足對話上下文
- 如何讓回答在長度、風格與可靠性上更穩定

---

## 2. 核心理念一：以站內知識為中心，而不是以模型為中心

這個系統的第一原則是：模型不是知識本體，網站內容才是知識本體。

也就是說，AI 的角色不是自由生成資訊，而是對既有內容進行以下操作：

- 檢索
- 重組
- 摘要
- 回答
- 導航

在實作上，後端會先把網站中的結構化資料整理成可搜尋的知識項目，例如：

- 個人 profile
- 工作經驗
- 專案
- 出版與研究成果
- 部落格文章

接著進一步轉成 `SkillCard` / `KnowledgeItem` 這類可搜尋資料結構，讓每一段內容都具備：

- `title`
- `summary`
- `search_text`
- `tags`
- `questions`
- `evidence`
- `url`

這樣做的好處是，系統不是直接把整個資料庫丟給模型，而是先在應用層完成一輪**可控的知識選取
**，再把最相關的內容傳給模型回答。

這種設計比起純粹依賴 prompt 更穩定，因為「哪些內容有資格進入回答上下文」是在系統層決定
的，而不是讓模型自己猜。

---

## 3. 核心理念二：上下文記憶不是裝飾，而是對話成立的必要條件

一個真正可用的 chatbot，不能把每句話都當成孤立事件。

使用者在多輪對話中的提問，常常包含：

- 代名詞引用，例如「他」、「這篇」、「那個專案」
- 主題延續，例如「那這個經驗跟 AI 有關嗎」
- 省略資訊，例如「還有別的嗎」

如果沒有上下文記憶，模型只能根據當前一句話做推測，結果通常會變得模糊或答非所問。

因此，這次設計中加入了一層短期對話記憶：

- 前端保留最近幾輪已完成對話
- 每次送出新問題時，會把最近的 `history` 一起送到後端
- 後端會先正規化這段對話，再將其用於：
- 檢索強化
- 回答生成

3.1 記憶如何參與檢索 這裡有一個重要設計點：上下文不只影響回答，也影響檢索。 如果使用者先問： > Vincent 做過哪些 AI 專案？ 下一句又問： > 哪一個比較偏產品化？ 第二句如果單獨檢索，關鍵詞其實很弱；但如果把最近幾個 user turn 和當前問題拼接成 contextual question，檢索效果就會明顯提升。 也就是說，系統不是只把 history 當成 prompt 附件，而是把它當成查詢語義補全機制。 這背後的想法是： > 多輪對話的上下文，應該先幫助系統「找到正確內容」，再幫助模型「說出正確答案」。 --- ## 4. 核心理念三：檢索與生成必須分工 這個 chatbot 的設計並不是「直接把問題丟給模型」，而是遵循一個比較清楚的 pipeline： 1. 使用者輸入問題 2. 系統收集最近幾輪對話歷史 3. 後端建立 contextual query 4. 針對站內知識卡片進行排序 5. 選出最相關的 skill cards 6. 將問題與知識卡片一起送進模型 7. 模型負責自然語言生成 8. 前端以串流方式顯示答案 這裡的分工很重要：

- 檢索層處理「該看哪些內容」
- 生成層處理「該怎麼表達這些內容」

如果把這兩件事混在一起，模型就會同時負責找資料和回答，可靠性會下降。相反地，當檢索層先收
斂出候選知識後，生成層就能更專注於語意組織、摘要和語氣控制。

這也是為什麼系統 prompt 明確要求：

- answer using only the provided site knowledge
- do not invent details
- keep replies short by default

本質上，這不是單純的語氣設定，而是整個系統架構對模型行為的約束延伸。

---

## 5. 核心理念四：回答應該預設簡潔，但不是資訊不足

在網站場景中，AI chatbot 的用途通常不是長篇對談，而是快速協助使用者：

- 了解一個人做過什麼
- 找到某篇文章或某個專案
- 判斷是否值得繼續深入閱讀

所以回答的設計原則是：預設簡潔、必要時展開。

系統 prompt 會引導模型：

- 簡單問題用一小段或 2-4 個 bullets 回答
- 打招呼或模糊寒暄時，只回一句短句並引導具體提問
- 只有在問題本身有足夠深度時，才生成較完整回答

這樣的好處有兩個：

1. 降低認知負擔
使用者不用先讀完一大段內容才能知道重點。

2. 減少幻覺空間
回答越長、越自由，模型越容易補出不必要的內容。簡潔本身也是一種穩定性設計。

---

## 6. 核心理念五：記憶要有限制，不能無限制堆疊

「有記憶」不等於「把所有歷史都丟進 prompt」。

如果無限制累積對話，會出現幾個問題：

- token 成本變高
- prompt 噪音增加
- 早期對話污染後續判斷
- 相關性下降

所以目前的設計是短期、有上限的記憶模型：

- schema 限制 `history` 最大長度
- 前端只送最近幾輪對話
- 後端也會做 normalize 與裁切
- 只保留對目前語義最可能有幫助的上下文

這是一個很務實的取捨。因為對網站型助理來說，大多數有效上下文其實只來自最近幾輪，而不是整
段長對話。

未來如果需要擴充，也可以分成兩層：

- 短期記憶：最近幾輪對話，放在 request context
- 長期記憶：使用者偏好、常問主題、已看過內容，存進後端或資料庫

但在現階段，短期記憶已經足以明顯改善對話自然度與準確性。

---

## 7. 技術設計上的幾個關鍵決策

### 7.1 在前端保存對話歷史
前端目前保留最近幾則已完成訊息，避免把尚未完成的串流輸出或空白 placeholder 一起送進去。這
樣可以確保 history 是乾淨、可用的。

### 7.2 在後端重新正規化 history
即使前端有做過整理，後端仍然需要再次清洗與裁切。這是因為 API 層不能完全信任客戶端輸入，應
該由服務端確保：

- role 合法
- text 不為空
- 長度受控
- history 數量受控

### 7.3 把 history 同時用在 retrieval 與 generation
很多系統只在生成 prompt 階段加入歷史對話，但這樣不夠。因為如果檢索本身就找錯內容，後面的
生成再聰明也只是基於錯誤上下文回答。

### 7.4 fallback 機制仍然存在
即使 OpenAI API 不可用，系統還是能根據檢索結果生成 fallback answer。這讓 chatbot 不會因為
模型服務暫時不可用就完全失效。

### 7.5 串流回應提升互動感
使用 `/ask/stream` 讓前端逐步顯示 token delta，這不是單純為了炫技，而是改善等待體驗。使用
者能更早看到系統正在回答，也會感覺回應更即時。

---

## 8. 這個 chatbot 的本質：不是聊天玩具，而是知識介面

我比較傾向把這個 AI Chatbot 看成一種新的知識介面（knowledge interface），而不是網站上
的裝飾性聊天元件。

傳統網站的知識介面通常是：

- 導覽列
- 分類頁
- 搜尋框
- 文章列表

AI chatbot 提供的是另一種互動方式：使用者不再需要先理解網站結構，而是可以直接用自然語言提
問。系統的責任，就是把這個自然語言問題映射到站內知識，再用更容易理解的方式回傳答案。

從這個角度看，這個設計的重點從來不是「模型有多厲害」，而是：

- 能不能理解問題其實在問什麼
- 能不能找到真正相關的站內內容
- 能不能在不過度生成的前提下，把答案表達清楚

---

## 9. 總結

這個 AI Chatbot 的設計核心，可以濃縮成一句話：

> 讓 AI 成為有根據、能延續上下文、且可控的站內知識助理，而不是無邊界的自由生成器。

具體來說，這個理念落在幾個技術決策上：

- 以網站內容作為唯一可信知識來源
- 先檢索、再生成，而不是直接問模型
- 讓對話歷史同時參與檢索與回答
- 回答預設簡潔，降低認知負擔
- 用有限的短期記憶換取更穩定的多輪互動
正有用的 chatbot」。