若銷售人員必須在內部文件、媒體資料庫、CRM 與公開網站之間反覆查找資訊，AI 銷售助理可將檢索、摘要、客戶問題回覆與銷售資料查詢集中到同一個對話介面。此案例顯示，成效不只取決於大語言模型，還取決於文件標準化、多來源檢索、查詢路由、引用追溯與資料更新機制是否能共同運作。
適用情境與方案目標
此方案適合產品組合廣、知識分散且銷售問題變化快的團隊。例如，使用者可能要詢問產品在特定產業的適用方式、彙整近期 CRM 更新，或要求根據客戶情境撰寫回覆。來源案例中的助理使用 LLM 與檢索增強生成（RAG），結合內部專有資料及外部公開資訊，提供統一的聊天式入口。
除了問答，來源描述該系統可支援文件摘要、編輯、校對，以及透過 Text2SQL 對 CRM 結構化資料提出查詢。專案初期應先明確界定哪些問題可由文件 RAG 回答、哪些問題必須查詢 CRM，避免模型以不適合的資料來源產生回答。
架構路徑：從資料擷取到回答生成
來源中的架構可拆成四個相互依賴的層次：
- 文件擷取與前處理：將 PDF、簡報、音訊與影片等輸入轉成可檢索內容。案例提到 NVIDIA Multimodal PDF Ingestion Blueprint 用於 PDF 解析、NVIDIA Parakeet NIM 用於音訊轉錄，並以 Llama 3.1 70B 進行編輯與翻譯。
- 知識標準化與索引：文字被處理為標準化 Markdown，再儲存至 Milvus。產品名稱可依查找表補充簡短說明，以改善後續檢索內容的可讀性。
- Wide RAG 與資料路由：系統結合 Milvus 向量檢索、限定 NVIDIA 網站範圍的網路搜尋及 Perplexity API 結果；CRM 類問題則導向 Text2SQL 路徑。
- 事件驅動對話流程：案例使用 LlamaIndex 工作流程管理步驟狀態，並透過 Chainlit 在介面呈現進度，讓使用者知道檢索或長時間查詢是否仍在進行。
這種分層設計的核心，不是讓所有問題都交給單一模型，而是先判斷問題類型、選擇資料來源，再以適當流程產生可追溯的結果。
實作檢查點與使用者體驗
- 盤點內部文件、CRM 欄位、通話紀錄與公開內容，釐清資料擁有者、更新頻率與可使用範圍。
- 針對多語言、版面不一致與掃描式 PDF 建立可重複的前處理測試；僅有向量資料庫並不能保證原始內容已被正確擷取。
- 設計查詢路由規則與失敗處理。CRM 問題應檢查選表、SQL 產生與結果範圍；文件問題則應確認檢索片段是否真正支持答案。
- 保留來源追溯。案例以簡短英數鍵暫代生成階段的冗長引用，再於後處理還原完整引用，以降低內嵌引用出錯的機率。
- 在介面顯示階段性進度與已找到的來源摘要。對需要較長時間的網路檢索或 SQL 查詢，這比只顯示等待狀態更有助於判斷系統是否正常運作。
來源案例對網頁檢索與解析設定最長 8 秒，對 Perplexity API 結果設定最長 15 秒。這些數值是該案例的設計取捨，並非通用服務等級；實際門檻應依資料量、併發量、模型部署位置及使用者可接受等待時間進行專案測試。
風險、取捨與驗證邊界
資料時效是此類系統的持續風險。來源案例提到以每日更新內部銷售文件與媒體資料庫項目，並採用一年回顧期，同時探索識別與清除過時內容的方法。每日更新不等於每一筆內容都正確、完整或仍適用，因此高風險的產品、商務或客戶資訊仍應由資料責任人確認。
整合複雜度也不可低估：不同格式需要不同擷取流程，分散式長任務可能需要訊息佇列，而多條回答路徑會增加可觀測性需求。專案驗收應以代表性問題集測試檢索命中、引用正確性、SQL 結果、失敗回覆、延遲與權限邊界；模型名稱、API 行為及元件相容性則須以有日期的官方文件與完整 SKU/BOM 或部署清單確認。
常見問題
AI 銷售助理是否只需要部署 LLM？
不是。來源案例把 LLM 放在文件處理、回答生成與結構化輸出等環節，但回答品質同時受到文件解析、索引品質、資料路由、CRM 結構、引用後處理及資料更新策略影響。若原始資料不完整或過期，模型無法自行修正其事實基礎。
何時應使用 RAG，何時應使用 Text2SQL？
需要解釋、摘要或綜合非結構化文件時，RAG 較適合；需要彙總 CRM 中的結構化銷售資料時，應走 Text2SQL 路徑。實際路由規則應以團隊資料模型、欄位定義與測試問題集驗證，並為無法判定的查詢提供澄清或人工處理機制。
結論
AI 銷售助理可將分散的銷售知識與資料查詢整合為可操作的工作流程，但可靠性來自完整的資料治理與流程設計，而非單一模型。以文件標準化、分流檢索、可追溯引用、進度回饋與持續測試為基礎，才能評估此架構是否適合特定銷售環境。
圍繞「建置 AI 銷售助理：RAG、CRM 與文件處理的實作要點」繼續瞭解 相關解決方案。
WeChat
Profile