目錄

本文適合誰閱讀?
這篇文章同時適合企業決策者、IT 主管、系統工程師與開發人員閱讀。若您正在評估如何把公司內部 SOP、技術文件、產品規格、客服 FAQ 或維護手冊整理成可查詢的 AI 知識庫,可以依照角色選擇閱讀重點。
| 讀者角色 | 建議閱讀重點 | 可獲得的價值 |
|---|---|---|
| 企業決策者 / 老闆 | 架構設計、導入階段、GPU Server 選型、TAKI Cloud 協助項目 | 了解企業導入私有化 AI 知識庫需要哪些資源與成本 |
| IT 主管 / 技術主管 | PoC、MVP、Scale、Integration、權限控管、安全設計 | 評估內部系統如何逐步導入 RAG 與本地 LLM |
| 系統工程師 | Ollama 安裝、Open WebUI、Qdrant、API、安全設定 | 依照指令完成第一版可測試的 RAG 知識庫 |
| 開發人員 | Embedding、Qdrant 寫入、查詢腳本、SQL 串接邏輯 | 建立可擴充的企業知識庫後端架構 |
| 客服 / 業務主管 | SOP 查詢、客服 FAQ、產品規格助理、銷售知識庫 | 評估 AI 如何減少人工查資料與重複回覆時間 |
如果只是想快速驗證公司文件能不能被 AI 查詢,可以先閱讀「實作一」到「實作三」。
如果目標是正式商用部署,建議重點閱讀 Qdrant、Hybrid Search、SQL 串接、權限控管與 GPU Server 選型章節。
企業導入 AI 時,最常見的第一個問題通常不是「模型要多大」,而是:
公司已經有很多 SOP、技術文件、產品規格、客服 FAQ、Excel 報價表與內部維護手冊,能不能讓 AI 直接查這些資料,並回答員工或客戶的問題?
答案是可以,但關鍵不是單純安裝 Ollama。
正確做法是建立一套 Ollama + RAG 的企業知識庫架構。
Ollama 負責在本地或企業伺服器上執行大型語言模型;RAG 則負責從企業文件中找出正確資料,再交給模型整理成答案。
這種架構特別適合用於:
- SOP 查詢
- 技術文件搜尋
- 客服回覆草稿
- 產品規格比對
- 內部工程知識管理
- 私有化 AI 知識庫部署
什麼是 Ollama?為什麼適合企業知識庫?
Ollama 是一套可以在本機或伺服器上執行大型語言模型的工具。安裝後,它可以透過 API 被應用程式呼叫;Ollama 官方文件說明,預設 API 位址為 http://localhost:11434/api。
對企業來說,Ollama 的價值不只是「可以本地跑模型」,而是它能成為企業私有化 AI 應用的基礎元件。
對於需要私有化部署、內部文件處理或本地 LLM 應用的企業,穩定的 GPU Server 服務 會是 AI 知識庫能否長期運作的基礎。
應用場景 | 說明 |
|---|---|
SOP 查詢 | 讓客服或工程師快速查找標準作業流程 |
技術文件查詢 | 查 Linux、Plesk、Cloudflare、GPU Server、WordPress 等技術文件 |
客服知識庫 | 根據 FAQ 與過去案例產生客服回覆草稿 |
產品規格助理 | 協助業務查詢 GPU、CPU、RAM、頻寬、價格與適用場景 |
私有化 AI 助理 | 在企業內部環境處理敏感文件,降低資料外流與跨境傳輸風險 |
不過,Ollama 本身不是完整的知識庫系統。
它比較像是「本地 AI 模型的大腦」。如果要讓 AI 查 SOP、技術文件、產品規格與客服知識庫,還需要搭配 RAG、Embedding、向量資料庫、SQL 與權限管理。
為什麼不能只用 Ollama?RAG 才是查文件的核心
很多人以為,只要安裝 Ollama,然後問模型問題,它就能回答企業內部文件內容。這是錯誤觀念。
大型語言模型本身不會自動讀取公司內部 SOP、PDF、Excel、客服紀錄或技術文件。
如果沒有把企業資料整理成可檢索的知識庫,模型只能根據既有訓練知識與 prompt 內容回答,這很容易出現過時、錯誤或編造答案。
這就是為什麼企業知識庫需要 RAG。
RAG 的全名是 Retrieval-Augmented Generation,檢索增強生成。

一句話說:
Ollama 負責回答,RAG 負責找資料。企業知識庫要準確,兩者缺一不可。
Ollama 企業知識庫的標準架構:PoC 與正式商用差在哪?
一套完整的企業 AI 知識庫,大致可以設計成這樣:

如果只是 PoC 測試,可以先用:
Ollama + Open WebUI
如果要正式商用,建議升級成:
Ollama + Qdrant + SQL / ERP + API Gateway + 權限控管 + Reranker
Ollama + RAG 企業知識庫架構圖

傳統關鍵字查詢 vs Ollama + RAG 知識庫
企業以前查 SOP 或客服 FAQ,通常是靠關鍵字搜尋、內部 Wiki、Excel 或資料夾分類。
這種方式可以用,但遇到文件量變大、問題變複雜時,效率會明顯下降。
比較項目 | 傳統關鍵字查詢 | Ollama + RAG 知識庫 |
|---|---|---|
查詢方式 | 必須輸入精準關鍵字 | 可用自然語言提問 |
搜尋能力 | 找文件 | 找答案並整理重點 |
語意理解 | 弱 | 強 |
多文件彙整 | 需要人工閱讀 | 可整理多份文件內容 |
客服回覆 | 需人工改寫 | 可產生回覆草稿 |
SOP 查詢 | 只能找到文件 | 可整理成處理步驟 |
產品規格 | 容易漏掉相近型號 | 結合 SQL 與文件說明 |
適合場景 | 文件少、問題簡單 | 文件多、問題複雜、客服量大 |
對企業來說,Ollama + RAG 的價值不是取代所有系統,而是把分散在 SOP、技術文件、客服紀錄與產品資料中的知識,變成可以被自然語言查詢的 AI 助理。
適合放進企業知識庫的資料類型
企業不要一開始就把所有資料混在一起。
比較好的做法,是依照使用者與場景分類。
知識庫類型 | 適合內容 | 使用者 |
|---|---|---|
SOP 知識庫 | 開通流程、備份還原、SSL 設定、DNS 操作、故障排除流程 | 客服、工程師 |
技術文件庫 | Linux、Plesk、LiteSpeed、Cloudflare、WordPress、GPU Server、Ollama 部署文件 | 工程師 |
產品規格庫 | GPU 型號、CPU、RAM、SSD、頻寬、價格、適用場景 | 業務、售前顧問 |
客服知識庫 | FAQ、標準回覆、常見 ticket、客訴處理流程 | 客服、業務 |
銷售知識庫 | 方案比較、報價邏輯、競品比較、ROI 說明 | 業務、主管 |
工程經驗庫 | 錯誤訊息、log 案例、排錯紀錄、維護手冊 | 工程師、技術主管 |
這樣分類後,AI 比較不會把不同用途的資料混在一起。
例如客服問 SSL 問題,就不應該抓到 GPU Server 規格;業務問 H200 和 A100 差異,也不應該抓到內部維護手冊或客戶 ticket。
實作前準備:建議環境
在正式開始前,建議先準備一台 Linux 主機作為測試環境。
PoC 階段可以先用單機部署,把 Ollama、Open WebUI 與 Qdrant 放在同一台主機上;正式商用時,再拆成前端服務、模型服務、向量資料庫與產品資料庫。
項目 | 建議 |
|---|---|
作業系統 | Ubuntu 22.04 / 24.04、AlmaLinux 8 / 9 |
CPU | 8 核心以上 |
RAM | 32GB 以上,正式環境建議 64GB+ |
GPU | 測試可用 16GB VRAM;企業知識庫建議 24GB VRAM 以上 |
硬碟 | NVMe SSD,至少 200GB 起跳 |
軟體 | Docker、Docker Compose、Ollama |
用途 | SOP、FAQ、技術文件、客服知識庫測試 |
如果只是做第一階段 MVP,可以先使用:
Ollama + Open WebUI
如果要做正式商用架構,則建議升級為:
Ollama + Open WebUI / 自建前端 + Qdrant + SQL + API Gateway + 權限控管
實作一:安裝與驗證 Ollama
Ollama 是本地 LLM 的執行核心。安裝後,Ollama 會提供 API,讓 Open WebUI、後端程式或 RAG 系統呼叫模型。
1. 安裝 Ollama
curl -fsSL https://ollama.com/install.sh | sh
#安裝完成後,確認服務狀態:
systemctl status ollama
#如果服務尚未啟動,可以手動啟動:
sudo systemctl start ollama
sudo systemctl enable ollama
#確認 Ollama 版本:
ollama -v
2. 檢查 API 是否可用
#先確認 Ollama API 是否有回應:
curl http://localhost:11434/api/version
#列出本機已安裝的模型:
curl http://localhost:11434/api/tags
3. 下載並測試第一個模型
#可以先下載一個模型測試,例如:
ollama pull qwen3:14b
#確認模型已存在:
ollama list
#測試聊天 API:
curl http://localhost:11434/api/chat -d '{
"model": "qwen3:14b",
"messages": [
{
"role": "user",
"content": "請用繁體中文解釋什麼是 RAG。"
}
],
"stream": false
}'
4. 重要安全設定:不要直接開放 11434 到外網
正式環境不建議把 Ollama API 直接開到 Internet。
如果只是本機使用,建議維持預設 localhost。
如果要讓內網其他服務連線,可以改成內網 IP,但不要直接暴露到公網。
範例:只允許內網服務連線。
sudo systemctl edit ollama.service
加入:
[Service]
Environment="OLLAMA_HOST=192.168.1.10:11434"
重新載入並重啟:
sudo systemctl daemon-reload
sudo systemctl restart ollama
#確認監聽狀態:
ss -lntp | grep 11434
正式環境建議讓外部系統透過以下方式存取:
- Nginx Reverse Proxy
- API Gateway
- VPN
- Zero Trust Access
- 內網專線
不要直接開放 Ollama API。
實作二:下載 LLM 與 Embedding 模型
企業 RAG 知識庫通常需要兩種模型。
模型類型 | 用途 |
|---|---|
LLM 語言模型 | 負責理解問題、整理內容、產生回答 |
Embedding 模型 | 負責把文件轉成向量,用於語意搜尋 |
1. 下載語言模型
#中文企業知識庫建議先從 Qwen 系列測試:
ollama pull qwen3:14b
#如果 GPU VRAM 足夠,可以再測:
ollama pull qwen3:32b
#如果只是小型 FAQ 測試,也可以先用 8B 等級模型:
ollama pull qwen3:8b
#確認模型已下載:
ollama list
模型名稱與 tag 可能會隨 Ollama 模型庫更新而調整,正式部署前建議以 Ollama library 目前提供的 tag 為準。
2. 下載 Embedding 模型
Embedding 模型負責把文件與問題轉成向量。
可以先下載:
ollama pull nomic-embed-text
#或是
ollama pull mxbai-embed-large
#如果想測多語言或較輕量的 embedding,也可以測:
ollama pull embeddinggemma
3. 測試 Embedding API
用 /api/embed 測試文字是否能轉成向量:
curl http://localhost:11434/api/embed -d '{
"model": "nomic-embed-text",
"input": "這是一段 Plesk SSL 憑證排查 SOP。"
}'
正常情況下,回傳會包含一組很長的數字陣列,例如:
{
"embeddings": [
[0.0123, -0.0456, 0.0789]
]
}
4. 建議模型選擇方式
使用情境 | 建議 LLM | 建議 Embedding | 備註 |
|---|---|---|---|
小型 FAQ 測試 | 8B 等級 | nomic-embed-text | 負責理解問題、整理內容、產生回答 |
一般客服知識庫 | 14B 等級 | nomic-embed-text / mxbai-embed-large | 成本與品質平衡 |
技術文件 / SOP | 14B / 32B 等級 | mxbai-embed-large | 較適合複雜語意 |
多語言資料 | 14B / 32B 等級 | 多語言 embedding | 視資料語言測試 |
正式企業部署 | 32B 以上依需求評估 | 固定一種 embedding 模型 | 避免後續向量維度混亂 |
這裡要特別注意:
Embedding 模型一旦選定,不要隨便更換。
因為不同 embedding 模型產生的向量維度與語意空間不同。
如果中途更換 embedding 模型,通常需要重新把整個知識庫建立 embedding。
實作三:用 Open WebUI 建立第一版知識庫
Open WebUI 適合做第一階段 MVP。
它提供類似 ChatGPT 的操作介面,也支援 Ollama 連線與知識庫功能。
這一階段的目標不是做最完整的企業系統,而是先驗證:
- AI 是否能讀懂公司 SOP?
- AI 是否能根據文件回答?
- AI 是否能附上來源?
- 客服或工程師是否覺得有幫助?
1. 安裝 Open WebUI
假設 Ollama 已經安裝在主機上,可以用 Docker 啟動 Open WebUI:
docker run -d \
-p 3000:8080 \
--add-host=host.docker.internal:host-gateway \
-v open-webui:/app/backend/data \
--name open-webui \
--restart always \
ghcr.io/open-webui/open-webui:main
2. 進入 Open WebUI
瀏覽器開啟:
http://伺服器IP:3000
第一次進入時建立管理員帳號。
接著到:
Admin Settings → Connections → Ollama
設定 Ollama API:
http://host.docker.internal:11434
如果是 Linux Docker 環境,前面的 --add-host=host.docker.internal:host-gateway 很重要,否則 Open WebUI 容器可能找不到 host 上的 Ollama。
3. 建立測試 SOP 文件
先不要用真實客戶資料。
建議先建立一份測試用 Markdown 文件,例如:
sop-plesk-ssl.md
內容範例:
# Plesk SSL 憑證排查 SOP
## 適用情境
當客戶反映網站顯示 SSL 不安全、Let's Encrypt 申請失敗,或 HTTPS 無法正常開啟時,可依照本 SOP 排查。
## 常見原因
1. DNS A 記錄未指向正確主機。
2. DNS AAAA 記錄存在,但主機未設定 IPv6。
3. Plesk Hosting Settings 未正確套用 SSL 憑證。
4. Cloudflare SSL 模式與主機端憑證不一致。
5. 網站存在 mixed content。
## 排查步驟
### 步驟一:檢查 DNS
使用以下指令檢查 A 記錄:
```bash
dig example.com A +short
```
使用以下指令檢查 AAAA 記錄:
```bash
dig example.com AAAA +short
```
如果有 AAAA 記錄,但主機沒有設定 IPv6,建議先移除 AAAA 記錄後重新申請憑證。
### 步驟二:檢查憑證回應
```bash
curl -Iv https://example.com/
```
### 步驟三:檢查 Plesk SSL 設定
進入 Plesk → Hosting Settings,確認 SSL/TLS support 已啟用,且選擇正確憑證。
## 風險提醒
如果網站使用 Cloudflare,修改 SSL 模式前需確認主機端憑證是否有效,避免造成 HTTPS 中斷。
這種 Markdown 結構很適合後續 Chunking,因為標題、章節、步驟都很清楚。
4. 上傳文件到 Knowledge
在 Open WebUI 中建立 Knowledge:
Workspace / Knowledge → Create Knowledge
建議命名:
TAKI Cloud – Plesk SOP Knowledge
上傳:
sop-plesk-ssl.md
接著建立一個測試用 Assistant,或直接在聊天中引用該 Knowledge。
5. 測試問題
可以用以下問題測試:
客戶反映 Plesk Let’s Encrypt 申請失敗,而且 DNS 有 AAAA 記錄,應該怎麼排查?
理想回答應該包含:
- 問題判斷
- 可能原因
- DNS A / AAAA 檢查
- curl 憑證檢查
- Plesk Hosting Settings 檢查
- Cloudflare 風險提醒
- 來源文件
如果 AI 回答有引用到 SOP 內容,代表第一階段 MVP 成功。
6. Open WebUI MVP 的限制
Open WebUI 很適合快速驗證,但正式企業部署仍然會遇到幾個限制:
- 權限控管需要更細
- 文件版本需要管理
- 產品價格與庫存不適合只靠文件上傳
- 大量文件需要更完整的向量資料庫
- 需要查詢紀錄與品質評分
- 需要與 WHMCS / CRM / ERP / SQL 整合
所以 Open WebUI 可以作為 PoC,但如果要變成正式企業知識庫,建議進一步導入 Qdrant、SQL 與後端 API。
實作四:正式版導入 Qdrant 向量資料庫
當文件量增加後,建議使用專門的向量資料庫管理 embedding,例如 Qdrant。
Qdrant 適合用來儲存與搜尋大量文件向量,可用於非結構化資料的語意搜尋與 RAG 檢索。
1. 啟動 Qdrant
建立資料目錄:
mkdir -p /opt/qdrant_storage
啟動 Qdrant:
docker run -d \
--name qdrant \
-p 6333:6333 \
-p 6334:6334 \
-v /opt/qdrant_storage:/qdrant/storage \
--restart always \
qdrant/qdrant
確認服務:
curl http://localhost:6333
正常會看到 Qdrant 回應。
正式環境請不要直接把 6333 / 6334 開到公網,應放在內網、VPN、Reverse Proxy 或 API Gateway 後面。
2. 安裝 Python 套件
建立一個簡單的 ingestion 測試環境:
mkdir -p /opt/rag-demo/docs
cd /opt/rag-demo
python3 -m venv venv
source venv/bin/activate
pip install qdrant-client requests markdown
把剛剛的 SOP 文件放進:
/opt/rag-demo/docs/sop-plesk-ssl.md
3. 最小可跑的文件匯入腳本
建立:
nano ingest.py
內容如下。以下是最小可跑版本,會將 docs/ 目錄中的 Markdown / TXT 文件切分成 chunks,透過 Ollama 產生 embedding,並寫入 Qdrant 向量資料庫。
import os
import re
import uuid
import requests
from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct
QDRANT_URL = "http://localhost:6333"
COLLECTION_NAME = "taki_sop_knowledge"
OLLAMA_EMBED_URL = "http://localhost:11434/api/embed"
EMBED_MODEL = "nomic-embed-text"
DOCS_DIR = "./docs"
def embed_text(text: str) -> list[float]:
response = requests.post(
OLLAMA_EMBED_URL,
json={
"model": EMBED_MODEL,
"input": text
},
timeout=120
)
response.raise_for_status()
data = response.json()
if "embeddings" in data:
return data["embeddings"][0]
if "embedding" in data:
return data["embedding"]
raise RuntimeError(f"無法取得 embedding:{data}")
def split_markdown_by_heading(text: str, max_chars: int = 1200) -> list[str]:
parts = re.split(r"\n(?=#{1,6}\s)", text)
chunks = []
for part in parts:
part = part.strip()
if len(part) < 50:
continue
if len(part) <= max_chars:
chunks.append(part)
continue
paragraphs = part.split("\n\n")
buffer = ""
for paragraph in paragraphs:
if len(buffer) + len(paragraph) + 2 > max_chars:
if len(buffer.strip()) >= 50:
chunks.append(buffer.strip())
buffer = paragraph
else:
buffer = f"{buffer}\n\n{paragraph}".strip()
if len(buffer.strip()) >= 50:
chunks.append(buffer.strip())
return chunks
def load_documents() -> list[dict]:
documents = []
for filename in os.listdir(DOCS_DIR):
if not filename.endswith((".md", ".txt")):
continue
path = os.path.join(DOCS_DIR, filename)
with open(path, "r", encoding="utf-8") as f:
content = f.read()
chunks = split_markdown_by_heading(content)
for index, chunk in enumerate(chunks):
documents.append({
"id": str(uuid.uuid4()),
"text": chunk,
"metadata": {
"source": filename,
"chunk_index": index,
"category": "SOP",
"department": "Engineering",
"permission": "internal",
"version": "2026-05"
}
})
return documents
def main():
client = QdrantClient(url=QDRANT_URL)
docs = load_documents()
if not docs:
raise RuntimeError("沒有找到可匯入的文件,請確認 ./docs 目錄中有 .md 或 .txt 檔案")
sample_vector = embed_text(docs[0]["text"])
vector_size = len(sample_vector)
if client.collection_exists(COLLECTION_NAME):
client.delete_collection(COLLECTION_NAME)
client.create_collection(
collection_name=COLLECTION_NAME,
vectors_config=VectorParams(
size=vector_size,
distance=Distance.COSINE
)
)
points = []
for doc in docs:
vector = embed_text(doc["text"])
points.append(
PointStruct(
id=doc["id"],
vector=vector,
payload={
"text": doc["text"],
**doc["metadata"]
}
)
)
client.upsert(
collection_name=COLLECTION_NAME,
points=points,
wait=True
)
print(f"匯入完成:{len(points)} 個 chunks")
print(f"Collection:{COLLECTION_NAME}")
print(f"Embedding model:{EMBED_MODEL}")
print(f"Vector size:{vector_size}")
if __name__ == "__main__":
main()
執行:
python ingest.py
成功後會看到類似:
匯入完成:6 個 chunks
Collection:taki_sop_knowledge
Embedding model:nomic-embed-text
Vector size:768
若看到 匯入完成:X 個 chunks,代表文件已成功切分、轉成 embedding,並寫入 Qdrant collection。若出現連線錯誤,請先確認 Ollama 是否在 11434 正常運作,以及 Qdrant 是否在 6333 正常回應。
這代表 SOP 文件已經被切分、轉成 embedding,並成功寫入 Qdrant 向量資料庫。
4. 建立查詢腳本
建立:nano ask.py
內容如下:
import requests
from qdrant_client import QdrantClient
QDRANT_URL = "http://localhost:6333"
COLLECTION_NAME = "taki_sop_knowledge"
OLLAMA_EMBED_URL = "http://localhost:11434/api/embed"
OLLAMA_CHAT_URL = "http://localhost:11434/api/chat"
EMBED_MODEL = "nomic-embed-text"
CHAT_MODEL = "qwen3:14b"
def embed_text(text: str) -> list[float]:
response = requests.post(
OLLAMA_EMBED_URL,
json={
"model": EMBED_MODEL,
"input": text
},
timeout=120
)
response.raise_for_status()
data = response.json()
if "embeddings" in data:
return data["embeddings"][0]
if "embedding" in data:
return data["embedding"]
raise RuntimeError(f"無法取得 embedding:{data}")
def search_context(question: str, limit: int = 5) -> list[dict]:
client = QdrantClient(url=QDRANT_URL)
query_vector = embed_text(question)
results = client.query_points(
collection_name=COLLECTION_NAME,
query=query_vector,
with_payload=True,
limit=limit
).points
contexts = []
for item in results:
payload = item.payload or {}
contexts.append({
"score": round(float(item.score), 4),
"text": payload.get("text", ""),
"source": payload.get("source", "unknown"),
"version": payload.get("version", "unknown"),
"category": payload.get("category", "unknown"),
"department": payload.get("department", "unknown")
})
return contexts
def ask_ollama(question: str, contexts: list[dict]) -> str:
reference_text = "\n\n---\n\n".join(
[
f"[來源: {c['source']} / 版本: {c['version']} / 分數: {c['score']}]\n{c['text']}"
for c in contexts
]
)
system_prompt = f"""
你是企業內部 AI 知識庫助理。
請只根據「參考文件」回答問題。
如果參考文件沒有足夠資訊,請回答:
「目前知識庫沒有足夠資料,建議轉交人工確認。」
請不要自行編造價格、SLA、產品規格、合約條款或處理流程。
回答格式:
1. 問題判斷
2. 可能原因
3. 建議處理步驟
4. 風險提醒
5. 參考來源
參考文件:
{reference_text}
"""
response = requests.post(
OLLAMA_CHAT_URL,
json={
"model": CHAT_MODEL,
"messages": [
{
"role": "system",
"content": system_prompt
},
{
"role": "user",
"content": question
}
],
"stream": False
},
timeout=180
)
response.raise_for_status()
return response.json()["message"]["content"]
def main():
question = "客戶的 Plesk Let's Encrypt 申請失敗,而且 DNS 有 AAAA 記錄,應該怎麼排查?"
contexts = search_context(question)
print("=== 檢索到的文件 ===")
for c in contexts:
print(f"- {c['source']} / score={c['score']} / version={c['version']}")
print("\n=== AI 回答 ===")
answer = ask_ollama(question, contexts)
print(answer)
if __name__ == "__main__":
main()
執行:python ask.py
這個腳本完成了最小版 RAG 流程:
問題 → embedding → Qdrant 搜尋 → 取回文件 → Ollama 回答 → 附來源
這個查詢流程會先把問題轉成 embedding,再到 Qdrant 找出最相關的文件 chunks,最後交給 Ollama 根據參考文件回答。這就是最小可跑版的 RAG 流程。
5. 這個 MVP 還缺什麼?
上面的程式是最小可跑版本,但還不是正式商用系統。
正式企業版至少還要補上:
- 使用者登入與權限控管
- Metadata filter,例如客服只能查 external / internal 文件
- Hybrid Search,例如錯誤碼、型號、版本號用 keyword 搜尋
- Reranking,把最相關文件排前面
- SQL / ERP / WHMCS 串接,用來查價格、庫存、客戶方案
- 查詢紀錄與回答評分
- 文件版本控管
- 敏感資料脫敏
- API Gateway 或 Reverse Proxy
- 備份與監控
因此,上面這套適合做 MVP,用來驗證 Ollama + RAG 是否能讀懂企業 SOP。正式商用時,必須進一步加入權限、Hybrid Search、Reranking、SQL 與安全控管。
Hybrid Search:為什麼型號、價格與錯誤碼不能只靠向量搜尋?
企業知識庫不能只靠向量搜尋。
向量搜尋擅長找「語意接近」的內容,但不一定適合所有場景。
例如以下查詢,往往需要精確匹配:
- RTX 5090
- A100 80GB
- H200 141GB
- Plesk Obsidian
- HTTP 403
- HTTP 500
- ModSecurity Rule ID 210492
- AAAA DNS 記錄
- PHP 8.3
- MariaDB 10.11
這些是產品型號、錯誤碼、版本號、規格數字與專有名詞。如果只靠向量搜尋,AI 可能找到「看起來相關」但不完全正確的段落。
因此正式企業 RAG 知識庫應採用 Hybrid Search。
檢索方式 | 適合內容 |
|---|---|
向量搜尋 | 語意相近的 SOP、FAQ、技術說明 |
關鍵字搜尋 / BM25 | 型號、錯誤碼、版本號、特殊術語 |
SQL / ERP 查詢 | 價格、庫存、規格、合約條件 |
Reranking | 重新排序候選段落,提升最終答案品質 |
Reranking:如何讓 AI 優先使用最正確的 SOP?
RAG 不是把所有搜尋到的文件都丟給模型。
如果第一次檢索回來 20 段內容,其中有 8 段只是「看起來相關」,LLM 就可能被雜訊干擾,產生不精準的回答。
這時就需要 Reranking。

對企業來說,Reranking 特別適合以下情境:
- SOP 版本很多
- FAQ 超過數百篇
- 產品規格常更新
- 客服問題容易相似但答案不同
- 工程文件包含大量錯誤碼與 log
初期 PoC 可以先不導入 Reranker;但只要知識庫變大,Reranking 就會成為提升準確率的重要步驟。
Chunking 策略:SOP、PDF、Excel、客服紀錄該怎麼切?
RAG 準不準,不只取決於模型,也取決於文件怎麼切。
如果 chunk 太大,檢索結果會不精準;如果 chunk 太小,模型又可能失去上下文。企業應依照文件類型設計不同的切分策略。
文件類型 | 建議切分方式 | 注意事項 |
|---|---|---|
SOP 文件 | 依 H2 / H3 標題與完整流程切分 | 不要把步驟切斷 |
技術文件 | 依章節、錯誤類型、指令區塊切分 | 保留指令與錯誤訊息 |
PDF 文件 | 先轉成文字,再依標題與段落切分 | 注意表格與圖片內容 |
產品規格 | 以單一產品或單一方案為單位 | 保留型號、價格、版本 |
客服 FAQ | 一個問題 + 一個標準答案為單位 | 保留適用情境 |
Ticket 紀錄 | 一個問題、排查過程、解法為單位 | 先移除敏感資料 |
SOP 類文件最適合使用 Markdown 標題切分法。
例如每個 H2 是一個主要流程,每個 H3 是操作步驟,這樣可以保留完整的處理邏輯,避免 AI 只看到片段資訊。
Metadata Enrichment:企業知識庫不能只切段,還要加標籤
企業級 RAG 不能只做 Chunking,還要做 Metadata Enrichment。
也就是說,每個文件段落不只是文字,還要標註它的來源、部門、權限、版本與適用範圍。
{
"title": "Plesk SSL 憑證更新 SOP",
"category": "SOP",
"product": "Plesk Hosting",
"department": "Engineering",
"permission": "internal-engineering",
"version": "2026-05",
"owner": "TAKI Cloud 技術部",
"source": "sop-plesk-ssl.md"
}
Metadata 的價值包括:
- 權限控管
- 版本控管
- 部門分流
- 文件來源追蹤
- 避免客服查到工程內部機密資料
- 避免業務查到內部成本或未公開報價
- 避免 AI 引用過期 SOP
例如客服只能查詢對外 FAQ 與標準回覆,工程師可以查內部維護手冊,主管才能查內部成本、合約條款或敏感 ticket。
Excel 產品規格表可以直接丟進 RAG 嗎?
不建議直接把 Excel 當成一般文件丟進向量資料庫。
Excel 常見內容包含:
- 產品型號
- CPU / RAM / SSD / GPU 規格
- 價格
- 庫存
- 頻寬
- 合約條件
- 備註與限制
這些資料屬於「精確資料」,不適合只靠語意搜尋。
比較好的做法是:
- Excel 每一列 → 轉成一筆產品資料
- GPU 型號 / VRAM / 價格 / 庫存 / 頻寬 → 放 SQL 欄位
- 產品說明 / 適用場景 / FAQ → 放向量資料庫
- 查詢時 → SQL 查精確資料,RAG 補充說明

例如使用者問:
我要部署 70B 模型,預算 15 萬/月,適合哪一台 GPU 主機?
系統應該先查產品資料庫,找出符合預算與 VRAM 條件的方案,再從技術知識庫補充部署建議,而不是只靠向量搜尋猜答案。
這一點非常重要,因為價格、庫存、GPU 規格與合約條款一旦被 AI 講錯,就可能造成商業風險。
產品價格與規格應放 SQL,不要只放向量資料庫
企業知識庫可以分成兩種資料。
資料類型 | 建議儲存方式 |
|---|---|
SOP、FAQ、技術文件、說明文章 | 向量資料庫 |
價格、庫存、GPU 規格、合約條件、客戶方案 | SQL / ERP / CRM / WHMCS |
產品規格、價格、庫存這些資料需要精確查詢,不應只靠向量搜尋。
正確流程應該是:

這種設計可以降低 AI 編造價格、混淆型號、引用舊版方案的風險。
Prompt 範本:讓 AI 只根據企業文件回答
企業知識庫最怕 AI 一本正經地胡說八道。
因此 Prompt 必須明確限制 AI 的回答範圍。
你是企業內部 AI 知識庫助理。
請只根據「參考文件」回答問題。
如果參考文件沒有足夠資訊,請回答:
「目前知識庫沒有足夠資料,建議轉交人工確認。」
請不要根據常識自行推論。
請不要編造文件中沒有提到的價格、SLA、合約條款、產品規格或處理流程。
回答時請包含:
1. 問題判斷
2. 處理步驟
3. 需要檢查的指令或資料
4. 風險提醒
5. 文件來源
參考文件:
{retrieved_chunks}
使用者問題:
{question}
客服版 Prompt:
你是客服助理,請根據公司知識庫產生一段可以回覆客戶的內容。
語氣要專業、清楚、有禮貌。
不要承諾知識庫沒有寫到的內容。
如果涉及價格、SLA、合約、退款、資料安全或技術保證,請提醒需由業務或工程師確認。
工程師版 Prompt:
你是資深 Linux / Plesk / GPU Server 工程師。
請根據內部技術文件回答。
回答時優先提供:
1. 判斷方向
2. 檢查指令
3. 可能原因
4. 修復步驟
5. 回滾方式
6. 風險提醒
拒答機制:避免 AI 一本正經胡說八道
企業級 AI 知識庫一定要允許 AI 說「不知道」。
很多 RAG 系統失敗,不是因為 AI 不會回答,而是因為 AI 在文件沒有答案時仍然硬答。
如果參考文件沒有明確答案,請直接回答:「目前知識庫沒有足夠資料,建議轉交人工確認。」
拒答機制對以下內容尤其重要:
- 產品價格
- SLA 承諾
- 退款條款
- 合約內容
- 客戶資料
- 資安事件
- 法律或合規問題
- 工程維護操作
對企業來說,一個會拒答的 AI,通常比一個什麼都敢回答的 AI 更可靠。
Human-in-the-Loop:讓 AI 成為客服助理,而不是直接取代客服
企業導入 AI 知識庫,初期不要直接讓 AI 面對客戶。
比較安全的做法是 Human-in-the-Loop,人機協作流程。
角色 | 負責工作 |
|---|---|
AI | 檢索 SOP、找出相關技術文件、整理客服回覆草稿、標註引用來源、提醒風險 |
真人 | 確認答案是否符合實際情況、修正語氣、檢查價格與 SLA、判斷是否需要工程師介入、決定是否送出給客戶 |
這樣 AI 的定位不是「取代客服」,而是幫客服、業務與工程師縮短查資料與整理回覆的時間。
權限控管:不是每個人都該看到所有知識
企業知識庫通常包含不同敏感程度的資料,因此不能讓所有人共用同一套資料權限。
建議至少分成三層。
權限層級 | 適合內容 | 使用者 |
|---|---|---|
Public / External | 對外 FAQ、產品介紹、基本教學 | 客戶、網站客服 |
Internal | 內部 SOP、客服標準回覆、產品比較 | 客服、業務 |
Confidential | 維護手冊、內部成本、伺服器資訊、客戶 Ticket | 工程師、主管 |
透過 Metadata 標籤,系統可以根據使用者身份決定能檢索哪些文件。
- 客服帳號 → 只能查 External + Internal
- 工程師帳號 → 可查 Internal + Engineering Confidential
- 主管帳號 → 可查 Internal + Confidential + 成本資料
這對主機代管商、系統整合商、金融、製造業尤其重要,因為客服紀錄與技術文件中可能包含 IP、帳號、錯誤紀錄、客戶環境與合約資訊。
安全性:不要把 Ollama API 直接開到外網
Ollama 預設適合本機或內網使用。正式部署時,不建議直接把 11434 port 開到 Internet。
建議做法:
- Ollama 只綁定 localhost 或內網 IP
- 對外服務透過 API Gateway 或 Nginx Reverse Proxy
- 前端系統必須有登入驗證
- 不同部門設定不同知識庫權限
- 查詢紀錄保留 log
- 敏感資料先做脫敏處理
- 回答需附上來源,方便人工追查
如果企業要跨辦公室或跨機房使用,建議走:
- VPN
- WireGuard
- 內網專線
- Zero Trust Access
- API Gateway + 身份驗證
不要直接開放 Ollama API 給外部網路。
如何測試 RAG 知識庫是否準確?
企業導入 RAG 後,不能只看 AI 回答順不順,而要建立測試題庫。
建議準備 50~100 題真實問題,例如:
- 客服最常遇到的 SSL 問題
- Plesk 常見錯誤
- WordPress 搬家流程
- GPU Server 規格比較
- 客戶常問的價格與方案問題
- 工程師常查的排錯 SOP
每題應該檢查:
- AI 是否找到正確文件
- AI 是否引用正確來源
- 回答是否有編造內容
- 是否能拒絕回答知識庫沒有的問題
- 是否能區分對外 FAQ 與內部 SOP
- 是否需要轉交人工確認
RAG 評測三指標
指標 | 意義 |
|---|---|
Faithfulness 忠實度 | AI 回答是否真的來自參考文件 |
Answer Relevance 回答相關性 | AI 是否真的回答了使用者問題 |
Context Precision 檢索精確度 | 系統找出的文件段落是否真的包含答案 |
初期不一定要馬上自動化評測。
比較務實的做法,是先由客服主管與資深工程師做人工盲測,確認 AI 是否能找到正確文件、是否有胡亂推論、是否適合導入日常流程。
Ollama 模型與 GPU Server 怎麼選?
如果只是小型 FAQ 或 PoC 測試,可以先用單台 GPU 主機驗證流程;但如果要支援較大的語言模型、更多文件量、更長上下文或多人同時查詢,就需要評估 [專用 GPU Server]、GPU Cloud 或私有化 AI 主機架構。
模型與硬體沒有絕對答案,會受到以下因素影響:
- 模型大小
- 量化格式
- 上下文長度
- 文件量
- 併發人數
- 回覆速度要求
- 是否需要多部門同時使用
使用情境 | 建議模型等級 | 適合用途 | 硬體方向 |
|---|---|---|---|
小型 FAQ 測試 | 7B / 8B | 簡單客服問答、內部測試 | 16GB VRAM 等級 GPU 可測試 |
一般企業知識庫 | 14B 等級 | SOP 查詢、客服草稿、技術文件摘要 | 24GB VRAM 以上較適合 |
複雜技術推理 | 32B 等級 | 多文件整理、技術排錯、售前方案分析 | 48GB VRAM 以上或多 GPU |
高品質企業部署 | 70B 等級 | 複雜推理、大型知識庫、多部門使用 | A100 / H100 / H200 等級 GPU Server |
高併發客服系統 | 依併發與延遲目標評估 | 多名客服同時查詢 | 建議使用專用 GPU Server 或 GPU Cluster |
企業正式導入前,建議使用實際文件與真實客服問題做壓力測試,不要只看模型參數大小或單次問答效果。
如果您正在評估不同 GPU 架構的月租成本,可參考 TAKI Cloud 的 GPU Server 與 GPU Cloud 價格方案,再依模型大小、文件量與併發需求選擇合適配置。
企業導入案例:健鼎科技如何用 GPU Server 處理 SOP、技術文件與文件翻譯
TAKI Cloud 曾協助健鼎科技股份有限公司建置文件型語言模型應用,主要應用場景包含 SOP 查詢、技術文件整理與文件翻譯。
在初期導入階段,客戶先採用 RTX 4090 多卡 GPU Server 進行模型測試與文件處理流程驗證。隨著應用需求增加,後續調整為多台 RTX 4090 8 卡主機,提升文件處理量與服務穩定性。
在進一步擴大使用情境後,客戶再升級至 H200 等級 GPU Server,以支援更高階的模型推論需求、更大的記憶體容量與更穩定的企業級 AI 應用環境。
這個案例說明,企業導入 Ollama / RAG / 文件語言模型時,通常不是一次到位,而是會經歷三個階段:
階段 | 目標 | GPU 架構 |
|---|---|---|
PoC 測試 | 驗證 SOP、技術文件與翻譯流程是否可行 | RTX 4090 多卡主機 |
MVP 擴充 | 支援更多文件量與內部使用者 | RTX 4090 8 卡主機多台 |
正式營運 | 支援更高品質推論、更大模型與更穩定服務 | H200 GPU Server |
對企業來說,這也代表 GPU Server 選型不應只看單次模型能不能跑,而要同時評估文件量、模型大小、併發人數、上下文長度、穩定性與未來擴充需求。
常見避坑指南:企業導入 Ollama 知識庫前要注意什麼?
1. 不要把整份 PDF 直接塞進 Prompt
大型 PDF 應先轉成文字、清洗、切段、建立 embedding,再交給 RAG 系統檢索。直接把整份文件塞給模型,不只效率差,也容易讓模型抓不到重點。
2. 不要只靠向量搜尋查產品規格
價格、庫存、GPU 型號、RAM、頻寬、SLA 屬於精確資料,應該放在 SQL、ERP 或產品資料庫中,再由 AI 整合回答。
3. 不要忽略文件版本
企業 SOP 經常更新。如果知識庫沒有版本控管,AI 可能引用舊版流程。每份文件都應標示版本、日期、負責部門與適用範圍。
4. 不要直接讓 AI 面對客戶
初期應先做內部客服助理,由 AI 產生回覆草稿,再由真人確認。等準確率穩定後,再逐步開放給網站客服或客戶入口。
5. 不要把 Ollama API 直接開到外網
Ollama API 應放在內網、VPN 或 API Gateway 後面,並加上登入、權限控管與查詢紀錄。
6. 不要讓 AI 回答它不知道的問題
正式知識庫一定要有拒答機制。當文件沒有答案時,AI 應回答「目前知識庫沒有足夠資料」,而不是自行推論。
企業導入階段:PoC、MVP、Scale、Integration
企業導入 Ollama 知識庫,建議分階段進行,不要一開始就追求全自動。
階段 | 目標 | 技術組合 | 預期成效 |
|---|---|---|---|
實驗期 PoC | 內部測試、驗證可行性 | Ollama + Open WebUI | 驗證 AI 是否能讀懂公司 SOP |
成長期 MVP | 支援單一部門,例如客服 | Ollama + Qdrant + 簡易 API | 減少人工翻找文件時間,建立標準回覆流程 |
營運期 Scale | 多部門、高併發、權限控管 | GPU Server + Hybrid Search + Reranker | 建立公司級中央知識助理 |
整合期 Integration | 串接 WHMCS / CRM / ERP | RAG + SQL + API Gateway | 讓 AI 同時查文件、產品資料與客戶狀態 |
這樣的導入方式風險比較低,也比較容易讓客服、業務、工程師與主管逐步建立信任。
TAKI Cloud 如何協助企業部署 Ollama 私有化 AI 知識庫?
企業導入 Ollama / RAG 知識庫時,底層 GPU Server 服務 會直接影響模型回應速度、文件處理效率、多人查詢穩定性與資料安全控管。
TAKI Cloud 可協助企業依照文件量、模型大小、併發人數、資料敏感度與預算,規劃適合的私有化 AI 知識庫架構,包括:
- GPU Server 規格選型
- Ollama / Open WebUI / Qdrant 部署
- Hybrid Search 與 Reranker 架構規劃
- SOP、FAQ、產品規格與客服資料整理
- 權限控管與內網安全設計
- RAG 準確率測試與使用流程導入
想建立企業私有化 AI 知識庫?
TAKI Cloud 可協助企業規劃 GPU Server、Ollama、RAG、Qdrant、SQL 串接與權限控管架構,適合客服知識庫、SOP 查詢、技術文件管理與產品規格助理等應用。
結論:Ollama 不是知識庫,但它可以成為企業 AI 知識庫的大腦
Ollama 的定位不是文件搜尋工具,而是本地 LLM 的執行核心。
如果企業想用 AI 查 SOP、技術文件、產品規格與客服知識庫,正確架構應該是:
Ollama + Embedding + RAG + Hybrid Search + SQL + 權限控管
快速測試可以先用:
Ollama + Open WebUI
正式商用則建議:
Ollama + Qdrant + SQL / ERP + Reranking + API Gateway + GPU Server
企業導入 AI 知識庫的重點,不是讓 AI 憑空回答,而是讓 AI 根據企業自己的文件、產品資料、SOP 與客服紀錄回答。
當企業把分散在 PDF、Excel、Wiki、Ticket 與內部文件中的知識整理成可檢索、可控權限、可追蹤來源的知識庫後,AI 才能真正成為客服、工程師、業務與主管都能信任的內部智慧助理。
FAQ
Ollama 本身主要負責模型推論,不是完整的文件管理系統。若要查 PDF,通常需要先將 PDF 內容轉成文字,切段後建立 embedding,再放入向量資料庫或 Open WebUI Knowledge 這類知識庫功能中。
可以,但建議先從客服助理開始。讓 AI 根據知識庫產生回覆草稿,再由真人確認。等準確率穩定後,再逐步接到網站客服、WHMCS、CRM 或 LINE 客服。
如果文件量很少,可以先用 Open WebUI 測試。如果 SOP、技術文件、FAQ、ticket 數量很多,建議使用 Qdrant、Chroma 或 PostgreSQL pgvector 這類向量資料庫。
不建議只靠 RAG。價格、庫存、GPU 型號、CPU、RAM、頻寬、合約條件屬於精確資料,應放在 SQL、ERP 或產品資料庫中,再讓 AI 結合文件說明回答。
向量搜尋擅長找語意相近內容,Hybrid Search 則結合向量搜尋、關鍵字搜尋與結構化資料查詢。對產品型號、錯誤碼、版本號、價格與庫存這類資料,Hybrid Search 通常比單純向量搜尋更適合。
Reranking 是在初步檢索後,重新排序候選文件段落,讓最相關的內容排在前面。初期 PoC 可以先不導入,但當文件量變大、SOP 版本變多或客服問題高度相似時,Reranking 會明顯提升回答品質。
適合。Ollama 可以部署在企業內部伺服器或專屬 GPU Server 上,搭配 RAG、權限控管與內網安全設計,用於建立私有化 AI 知識庫。但正式部署時,不建議直接把 Ollama API 開放到外網。
