NLWeb 自然語言部落格搜尋

專案構想（2025.11 更新）

實作完整的 NLWeb (Natural Language Web) instance，讓使用者和 AI agents 可以透過自然語言查詢部落格內容，而非傳統的關鍵字搜尋。

核心問題： 傳統搜尋無法理解語意，使用者需要精準的關鍵字才能找到相關文章。

解決方案： 使用 NLWeb 協議，結合向量搜尋和 LLM，提供語意理解的自然語言查詢。

🆕 2025.11 最新發現

NLWeb 已進入早期生產階段：

✅ Microsoft Build 2025 正式宣布（2025-05-19）
✅ 12+ 企業已採用：Shopify, Snowflake, O’Reilly Media, Tripadvisor, Eventbrite, Chicago Public Media, Common Sense Media, DDM, Hearst, Milvus, Qdrant, Inception Labs
⚠️ 安全性警示：NLWeb 參考實作發現 critical security flaw（已修補但無 CVE），生產部署需審慎評估

影響評估：

✅ 技術可行性已驗證（12+ 企業生產環境）
⚠️ 安全性需額外注意（需最新版本 + 安全審計）
🔮 生態系快速成長中（預期 2026 年達 50+ 企業）

技術架構

前端

Astro SSG（保持靜態生成）
搜尋介面（可選）
MCP client integration

後端（新增）

Vercel Edge Functions - 處理自然語言查詢
Pinecone / Qdrant - 向量資料庫
OpenAI Embeddings API - 文章向量化
OpenAI GPT-4 - 查詢理解與回答生成

資料流程

1. Build Time:
   Blog Posts (Markdown)
   → Extract content & metadata
   → Generate embeddings (OpenAI)
   → Store in vector DB (Pinecone)

2. Query Time:
   User: "有關於 Astro Content Collections 的文章嗎？"
   → Edge Function
   → Convert query to embedding
   → Vector similarity search
   → Return relevant articles + AI-generated summary

功能規劃

Phase 1: 基礎自然語言查詢

實作 NLWeb ask method
向量搜尋整合
回傳相關文章列表

Phase 2: 語意理解增強

查詢意圖識別（尋找文章 vs. 回答問題）
多輪對話支援
上下文記憶

Phase 3: MCP Server 暴露

建立公開 MCP server
實作 agent authentication
Rate limiting

技術挑戰

1. 違背 Full SSG 原則

問題： 需要 serverless functions，無法純靜態
影響： 增加運行成本、維護複雜度
可能解決： 使用免費方案（Vercel Hobby Plan），限制呼叫次數

2. Embeddings 成本

問題： 每次 build 需要重新生成 embeddings
成本估算： 假設 50 篇文章，每篇 1000 tokens
- Embeddings: 50 * 1000 * $0.0001/1K tokens = $0.005/build
- 月成本（假設每天 1 build）: $0.15
優化策略：
- 只對新文章或修改的文章生成 embeddings
- Cache embeddings in git

3. 向量資料庫選擇

選項	優點	缺點
Pinecone	簡單易用、免費方案	需要註冊、有配額限制
Qdrant	開源、self-hosted	需要維護伺服器
Cloudflare Vectorize	與 Vercel 整合好	較新、文件較少

建議： 使用 Pinecone 免費方案（100K vectors, 1 pod）

4. 冷啟動延遲

問題： Edge Functions 冷啟動可能需要 1-2 秒
解決： 使用 warm-up 策略，或改用 Cloudflare Workers（更快）

投資報酬率分析

成本

開發時間： 20-30 小時
- Vector DB 整合：6-8h
- Edge Functions 實作：4-6h
- NLWeb 協議實作：4-6h
- 測試與優化：6-10h
月運行成本： $0-5（免費方案範圍內）
維護成本： 中等（需要監控、更新 embeddings）

效益

實用性： 🟡 中等（目前沒有 AI agents 會使用）
技術展示： ⭐⭐⭐⭐⭐（非常適合撰寫技術文章）
使用者體驗： ⭐⭐⭐⭐（語意搜尋優於關鍵字搜尋）
SEO 影響： 無

建議（2025.11 更新）

考量 NLWeb 最新發展後的建議：

⏸️ 仍建議暫緩完整實作，原因：
1. 違背 Full SSG 架構原則
2. 開發成本 vs. 實際效益不符（個人部落格規模）
3. 安全性風險需要專業審計
4. 12+ 企業採用案例多為大型內容平台（Shopify, O’Reilly 等）
✅ 但價值大幅提升：
1. 技術可行性已被 12+ 企業驗證
2. 可撰寫「為什麼 Shopify 選擇 NLWeb」分析文章
3. 生態系快速成長，未來實作價值可能提升
✅ 替代方案：先做 NLWeb 語意層增強
1. 增強 RSS, llms.txt, Schema.org JSON-LD（零後端）
2. 與 12+ 企業同路徑，但保持 Full SSG
3. 為未來 NLWeb 整合預留接口

替代方案

簡化版：Client-side 向量搜尋

在 build time 生成所有文章的 embeddings
將 embeddings 打包到靜態 JSON 檔案
使用 browser-side vector search library（如 vectra）
優點： 保持 Full SSG
缺點： Embeddings 檔案可能過大（影響載入速度）

參考資源

NLWeb GitHub: https://github.com/nlweb-ai/NLWeb
Pinecone Docs: https://docs.pinecone.io/
OpenAI Embeddings: https://platform.openai.com/docs/guides/embeddings
Vercel Edge Functions: https://vercel.com/docs/functions/edge-functions

附錄：技術文章大綱

如果不完整實作，可撰寫以下文章：

文章：《NLWeb vs 傳統搜尋：為什麼我選擇不實作》

大綱：

NLWeb 的願景與承諾
技術可行性分析
成本效益評估
為什麼 Full SSG + 傳統搜尋仍是最佳選擇
什麼情況下值得實作 NLWeb？

專案狀態： 💡 Idea（AI 協助發想） 建議行動： 撰寫研究分析文章，暫不執行完整實作

NLWeb-Powered 自然語言部落格搜尋