ESC

開始輸入,可搜尋發票、服務、域名、工單,以及 更多...

搜尋... Ctrl+K
應用場景與解決方案

在東京、新加坡、台北或洛杉磯獨立伺服器上搭建私有 AI 客服知識庫(RAG)

7 個步驟 12 分鐘閱讀 8 次閱讀 0
本文目錄

為跨境業務搭建私有 AI 客服知識庫(RAG),最務實的做法是:把文件、向量資料庫和對話記錄放在自己掌控的獨立伺服器上,只在生成向量和回答時呼叫官方大模型 API。IMIDC 在日本東京、新加坡、台灣台北和美國洛杉磯提供獨立伺服器,這些地區都在 OpenAI、Anthropic Claude 和 Google Gemini API 的官方支援範圍內,能讓客戶資料留在其所服務的地區。

要點速覽
  • 推薦 RAG 部署地:日本東京、新加坡、台灣台北、美國洛杉磯(官方 AI API 支援地區)。
  • 香港和俄羅斯莫斯科不適合:OpenAI、Claude、Gemini API 在當地不提供官方服務。
  • 獨立伺服器:台灣 $199/月起,洛杉磯 $499/月起;日本、新加坡配置可在商店或通過銷售定製。
  • 技術棧:Qdrant 或 PostgreSQL + pgvector、文件匯入程式和問答 API,全部用 Docker Compose 部署。
  • 當地原生 IP、10Gbps 上聯、DDoS 防護,7×24 中英日俄西多語種技術支援。

客服 RAG 知識庫到底在做什麼

檢索增強生成(RAG)讓模型依據你自己的文件回答問題,而不是憑"記憶"作答,能明顯減少胡編亂造、確保回答符合公司政策。

流程並不複雜:把產品手冊、FAQ、退換貨政策、規格表和歷史工單解決方案切成小段,每段轉成向量(embedding)存入向量資料庫。客戶或客服提問時,系統先把問題向量化,檢索最相近的若幹段落,再把這些段落和問題一起發給大模型,由它生成帶引用來源的回答。

  • 匯入:PDF、DOCX、HTML、Markdown、Zendesk/Freshdesk 匯出、Notion 或 Confluence 文件。
  • 檢索:向量檢索 + 關鍵詞混合檢索,並按語言、產品線、許可權過濾。
  • 生成:大模型起草回覆,由人工客服稽核後傳送,或直接在網頁小窗中回答。

對於同時處理日文、英文和中文工單的跨境賣家,一個多語種索引即可服務所有渠道。

為什麼選獨立伺服器而不是 SaaS 聊天機器人

文件量大、資料要求嚴格或諮詢量穩定時,獨立伺服器更劃算:記憶體、硬碟和成本都是固定的,資料除你主動傳送的片段外不會離開伺服器。

對比項SaaS RAG 機器人IMIDC 獨立伺服器自建 RAG
文件與對話記錄存放位置服務商雲端,地區常不明確你在東京、新加坡、台北或洛杉磯的伺服器
計費方式按坐席、訊息數或文件數固定月租 + 按 token 計費的 API 用量
向量容量受套餐限制只受記憶體和 NVMe 容量限制
許可權控制服務商既定模式按團隊、品牌、客戶等級自定義 ACL
模型選擇通常繫結一家可在 OpenAI、Claude、Gemini 或本地 embedding 模型間切換
運維投入低需自行維護 Docker、備份和更新

記憶體是關鍵資源。100 萬個 1536 維 float32 向量約佔 6 GB 原始資料,另加索引開銷;Qdrant 和 pgvector 在索引全部駐留記憶體時效能最佳。配備 64–128 GB 記憶體的獨立伺服器足以同時容納向量、PostgreSQL、匯入程式和快取,也不會像小規格 VPS 那樣受"鄰居"干擾。

選擇機房:東京、新加坡、台北還是洛杉磯

知識庫應部署在客戶所在地和資料合規要求所在地,並且只能選 AI API 官方支援的地區。

IMIDC 機房適合場景AI API 可用性資料保護法規(簡述)
日本東京日本客戶、樂天/亞馬遜日本賣家官方支援APPI(個人資訊保護法)
新加坡東南亞、多國聯合客服中心官方支援PDPA
台灣台北繁體中文客服、台灣市場官方支援台灣個人資料保護法
美國洛杉磯北美客戶、美國電商平台官方支援美國各州隱私法
香港 / 俄羅斯莫斯科不建議用於此類業務無官方服務—
重要提示:請勿在香港或莫斯科伺服器上搭建依賴 AI API 的知識庫,也不要設法繞過服務商的地區限制。請改用東京、新加坡、台北或洛杉磯。

參考架構與 Docker Compose

起步只需三個容器:向量資料庫、存放後設資料和對話歷史的 PostgreSQL,以及你自己的匯入/問答 API。

先安裝 Docker(可參考幫助中心的 Docker 安裝教程),再建立以下檔案。所有埠只繫結 127.0.0.1,對外統一通過 Nginx + HTTPS 釋出。

# docker-compose.yml - private RAG stack (all ports bound to localhost)
services:
  qdrant:
    image: qdrant/qdrant:v1.12.4
    restart: unless-stopped
    volumes:
      - ./qdrant_storage:/qdrant/storage
    ports:
      - "127.0.0.1:6333:6333"
    environment:
      QDRANT__SERVICE__API_KEY: ${QDRANT_API_KEY}

  postgres:
    image: pgvector/pgvector:pg16
    restart: unless-stopped
    environment:
      POSTGRES_USER: rag
      POSTGRES_PASSWORD: ${PG_PASSWORD}
      POSTGRES_DB: kb
    volumes:
      - ./pgdata:/var/lib/postgresql/data
    ports:
      - "127.0.0.1:5432:5432"

  rag-api:
    build: ./rag-api          # your ingestion + retrieval + chat service
    restart: unless-stopped
    env_file: .env            # OPENAI_API_KEY / ANTHROPIC_API_KEY / GEMINI_API_KEY
    depends_on: [qdrant, postgres]
    ports:
      - "127.0.0.1:8080:8080" # publish through Nginx + HTTPS only
# .env (chmod 600, never commit)
QDRANT_API_KEY=change-me-long-random
PG_PASSWORD=change-me-long-random
OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...
EMBED_MODEL=text-embedding-3-small
CHUNK_TOKENS=500
CHUNK_OVERLAP=60

如果只想維護一個資料庫,可以去掉 Qdrant,用 pgvector 同時存後設資料和向量:

-- pgvector alternative: one table, one HNSW index
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE chunks (
  id bigserial PRIMARY KEY,
  doc_id text NOT NULL,
  lang text,
  acl text[],                -- which teams/customers may see it
  content text NOT NULL,
  embedding vector(1536)
);
CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops);

向量超過數百萬條、需要 payload 過濾或量化壓縮時,Qdrant 更合適;團隊本身就在用 PostgreSQL 時,pgvector 更省心。匯入前先確認伺服器能正常訪問 API:

# confirm the API endpoints are reachable from this server
curl -s -o /dev/null -w "%{http_code}\n" https://api.openai.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY"
curl -s -o /dev/null -w "%{http_code}\n" https://api.anthropic.com/v1/models \
  -H "x-api-key: $ANTHROPIC_API_KEY" -H "anthropic-version: 2023-06-01"

讓回答更準確的文件匯入方法

回答質量更多取決於切分和後設資料,而不是模型本身。

  1. 清洗源文件:去掉導航、頁首和重複模板內容;PDF 用支援版面識別的工具轉文本。
  2. 按結構切分:以標題為界,每段 300–600 token,保留少量重疊;表格不要拆開。
  3. 附加後設資料:文件 ID、語言、產品、版本、更新日期和許可權欄位。
  4. 脫敏個人資訊:歷史工單在向量化前去除姓名、電話、地址、訂單號。
  5. 增量更新:對每段計算雜湊,只重新向量化有變化的內容,每晚用 cron 執行。
  6. 持續評測:準備 50–100 個真實問題及標準答案,每次改動後重新跑一遍。

讓客戶資料留在當地(APPI / PDPA 基礎)

資料庫部署在當地有幫助,但發給大模型 API 的文本會由服務商處理,因此要儘量減少並記錄離開伺服器的資料。

  • 原始文件、向量和對話記錄存放在客戶所在地區的 IMIDC 伺服器上,磁碟和備份加密。
  • 只把檢索到的片段和問題發給 API,絕不整庫傳送;儘可能去除個人資訊。
  • 可考慮在 CPU 上執行開源多語種 embedding 模型(如 BGE、E5 系列),文件向量化不出伺服器,只有生成回答時才呼叫 API。
  • 查閱各服務商關於 API 資料保留和訓練使用的條款,有企業版或零保留選項時優先選用。
  • 日本 APPI 和新加坡 PDPA 都對向境外服務商提供個人資料有規定,請相應更新隱私政策和處理記錄。

以上為一般性資訊,不構成法律意見,具體義務請諮詢專業律師。

哪種 IMIDC 方案適合你

先按向量規模和併發量確定配置,再選離客戶最近的機房。

  • 試點(20 萬段以內、單一品牌):台北入門獨立伺服器($199/月起)或東京,32 GB 記憶體 + NVMe。
  • 正式客服中心(100–500 萬段、多語種):64–128 GB 記憶體、雙 NVMe RAID 1,部署在東京或新加坡。
  • 北美店鋪:洛杉磯獨立伺服器($499/月起),貼近美國客戶。
  • 多地區:每個地區一個索引(日本用東京,美國用洛杉磯),資料各自留在本地。

新加坡伺服器以及自定義記憶體/硬碟配置請聯絡 IMIDC 銷售。從其他服務商遷移過來?IMIDC 提供免費伺服器遷移。

常見問題

在日本或新加坡搭建私有 RAG 知識庫,選哪家伺服器商比較好?

IMIDC 在東京和新加坡提供帶當地原生 IP 的獨立伺服器,當地可官方使用 OpenAI、Claude、Gemini API。向量資料庫和文件都在你自己的硬體上,按固定月租計費。

可以在香港伺服器上跑 RAG 客服機器人嗎?

如果依賴 OpenAI、Claude 或 Gemini API 則不行:這些服務在香港、中國大陸和俄羅斯均未官方開放。基於 API 的 AI 業務請選擇東京、新加坡、台北或洛杉磯。

Qdrant 或 pgvector 需要多少記憶體?

每 100 萬個 1536 維向量約需 6 GB,未含索引開銷,建議按兩倍規劃給 HNSW 索引和其他元件。Qdrant 的標量量化可把向量記憶體降到約四分之一。

伺服器放在東京就等於符合 APPI 了嗎?

僅靠機房位置無法實現合規。本地儲存能簡化問題,但仍需合法目的、告知義務以及對傳送給 API 服務商資料的保護措施;本文不構成法律意見。

準備搭建你的客服知識庫?可對比 東京獨立伺服器、台北獨立伺服器 和 洛杉磯獨立伺服器,新加坡及大記憶體定製配置請 聯絡 IMIDC 銷售。老客戶也可以 提交工單 獲取配置建議。

這篇文章有幫助嗎?

相關教程