# rag-search-answer

## 解決什麼問題
最經典 RAG：用戶問問題 → KBDB semantic search 找相關 blocks → 餵 claude 回答。
比直接問 claude 強：claude 有了實際 context，不會編、可引用、回答跟你的資料一致。

## 怎麼觸發
```bash
curl -X POST https://cypher.arcrun.dev/webhooks/named/rag_search_answer/trigger \
  -H "X-Arcrun-API-Key: ak_xxx" \
  -d '{
    "api_key":"ak_xxx",
    "question":"如何避免 CF self-fetch 死鎖?",
    "user_id":"inkstone_mira_tools"
  }'
```

## 改成你自己的
- `search_kbdb.topK` 改 N（取多少 context，3-10 常見）
- `search_kbdb.user_id` 改為 query 該用戶下的 blocks，或拿掉撈全庫
- prompt 改為你的 domain（客服 / 法律 / 醫療 / 技術文件）
- 進階：加 `_recipe_output_format: json` 讓 claude 回結構化 {answer, citations[]}

## 為什麼這 pattern 重要
RAG 是 LLM 真正派上用場的場景。沒 RAG，LLM 在你私有資料上的回答是猜的。

## 變體
- **多輪 RAG**：先 claude 改寫 question → KBDB search → claude 答（query rewriting）
- **多源**：KBDB + web search + DB query → merge → claude
- **filter**：claude 先判斷 "需要 RAG 嗎？" → 不需要直接回（省 search latency）
- **followup**：把 claude 答案 + 用戶 question 一起存 KBDB，下次同問題直接 cache hit

## 學到什麼
- `kbdb_search` 走 semantic（embedding），不是字面比對 — query 不用打對關鍵字
- `{{search_kbdb.results}}` 自動展開為 markdown 列表（component contract）
- claude prompt 內注入 context 是 RAG 的核心，不需要 vector DB 之外的額外組件