前言

昨天梳理了 RAG 的三大環節，今天在正式動手之前，先來決定「工具箱」——這次系列會用哪些技術來實作。

選型考量一：LLM

常見選擇大致分三類：

對一個 30 天的鐵人賽專案來說，優先考量「能快速迭代、專注在 RAG 邏輯本身」，所以這次系列會採用 API 服務型的 LLM，把心力放在檢索與資料處理的細節上，而不是模型部署。

選型考量二：向量資料庫

這次系列會選擇 Postgres + pgvector，原因是：

• 大部分團隊/實驗室都已經有 Postgres 使用經驗，學習曲線低
• 可以把向量資料跟一般結構化資料（如 metadata、使用者紀錄）放在同一個資料庫，方便做複合查詢
• 從小規模開始，之後要擴展到專用向量資料庫也有明確的遷移路徑

選型考量三：開發框架

要不要用 LangChain / LlamaIndex 這類 RAG 框架，還是自己手刻？

用框架的優點：開發速度快、社群資源多、有現成的 Loader、Splitter 元件
自己刻的優點：對每個環節的細節掌握度高、方便深入理解與客製化、不受框架版本更新影響

由於這個系列的目的是「搞懂 RAG 的每個環節」，我們會採取「框架輔助 + 關鍵環節手動實作」的策略：用框架處理繁瑣的文件載入，但 Chunking、檢索邏輯等核心環節會手寫，方便之後做實驗比較。

環境準備清單

# 建立虛擬環境
python -m venv rag-env
source rag-env/bin/activate  # Windows: rag-env\Scripts\activate

# 安裝基礎套件
pip install openai anthropic          # LLM API SDK（依實際選用）
pip install psycopg2-binary pgvector  # Postgres + pgvector
pip install langchain langchain-community  # 框架輔助
pip install pypdf beautifulsoup4      # 文件解析

小結

技術選型沒有標準答案，重點是要符合團隊現況與專案目標。這次系列選擇「API LLM + Postgres/pgvector + 框架輔助手動實作」的組合，兼顧開發效率與學習深度。明天會進入專案規劃，明確定義這次要解決的問題。