前言

系統整合完成後，今天要來談上線之後最實際的兩個問題：回應速度夠不夠快？運行成本能不能負擔？

拆解一次查詢的延遲來源

一次完整的 RAG 查詢，延遲通常來自以下幾個環節：

問題改寫（LLM）      ~0.5-1s
    │
向量檢索              ~0.05-0.2s
    │
Rerank                ~0.1-0.5s
    │
LLM 生成答案          ~2-5s（通常是最大的瓶頸）

可以看出，LLM 生成階段通常是延遲的主要來源，其次是需要額外呼叫 LLM 的問題改寫步驟。

優化方向一：減少不必要的 LLM 呼叫

• Day 19 提到的「判斷是否需要重新檢索」機制，可以避免每輪對話都做完整的問題改寫與檢索
• 對於簡單、明確的問題，可以考慮跳過 Query Rewriting 步驟，直接檢索

優化方向二：串流輸出改善「體感」速度

即使總生成時間沒有縮短，透過 Day 27 提到的串流輸出（Streaming），使用者可以馬上看到文字逐步出現，體感等待時間會大幅降低。

優化方向三：快取機制

問題層級的快取

如果知識庫更新不頻繁，許多使用者可能會問類似或重複的問題，可以針對「問題」做快取：

import hashlib
import redis

cache = redis.Redis()

def get_cached_answer(question):
    key = hashlib.md5(question.encode()).hexdigest()
    cached = cache.get(key)
    return cached.decode() if cached else None

def set_cached_answer(question, answer, ttl=3600):
    key = hashlib.md5(question.encode()).hexdigest()
    cache.set(key, answer, ex=ttl)

要注意：完全相同字串的問題在真實使用情境中比例可能不高，可以考慮用「語意相似度」判斷是否命中快取（例如問題向量跟快取中的問題向量相似度超過某個門檻，就直接回傳快取的答案），但這樣做要更謹慎，避免誤判導致答非所問。

Embedding 層級的快取

如果同一份文件的內容沒有變化，不需要重複計算 Embedding：

def get_or_compute_embedding(content, cache_store):
    content_hash = hashlib.md5(content.encode()).hexdigest()
    if content_hash in cache_store:
        return cache_store[content_hash]
    embedding = get_embedding(content)
    cache_store[content_hash] = embedding
    return embedding

成本控制的考量

RAG 系統的主要成本來源：

降低成本的常見做法：

• 精簡 Prompt 長度：避免塞入過多不必要的檢索結果
• 選用合適大小的模型：不是所有任務都需要最強、最貴的模型，簡單的問題改寫可以用較小的模型處理
• 善用快取，避免重複計算

小結

效能與成本優化，往往需要在「回答品質」與「速度/成本」之間找到平衡點——不是所有優化技巧都要用到極致，而是依照實際使用情境（使用人數、預算、對即時性的要求）做取捨。明天我們要討論系統上線後的監控與維運機制。