本文介紹如何利用AnalyticDB for PostgreSQLGraphRAG能力產生高品質QA對。
傳統方式產生QA對
當前問答類智能客服系統主要依賴於QA知識庫構建其對話能力，但傳統的知識庫構建方式存在明顯局限。現有知識體系通常基於人工客服的歷史應答記錄，通過周期性的人工篩選將高頻、優質的QA對納入知識庫。這種以經驗為主導的構建模式存在以下問題：
知識更新滯後，響應機制被動。當產品文檔或商務規則發生變更時，知識庫的更新完全依賴使用者的提問觸發，形成“需求倒逼知識更新”的被動響應機制。這種滯後不僅削弱了知識庫的時效性和服務效率，還可能因資訊不一致導致客戶誤解甚至引發服務風險。
內容品質不穩定，依賴人力篩選。由於人工應答受個體認知水平和表達習慣影響較大，答案品質參差不齊，需耗費大量人力資源做後期整理與品質把控，方可滿足知識庫收錄標準，顯著增加了維護成本。
冷啟動階段效果受限，依賴人工介入頻繁。在知識庫初期建設階段，由於缺乏足夠的高品質問答資料，系統服務能力較弱，使用者互動過程中頻繁需要人工客服介入，造成較大的人力負擔，也限制了智能客服系統的快速部署與應用。
LLM產生QA對
為彌補傳統依賴人工經驗構建QA知識庫所帶來的效率低下與品質不穩等問題，業界引入了大語言模型（LLM）技術，實現QA對的自動化批量產生。然而，在實際應用中發現，通過Dify等低代碼開發平台構建的工作流程在產生QA對時仍存在一系列系統性缺陷。實證研究表明，當前基於文檔資訊抽取的自動化流程主要面臨以下問題：
產生品質不穩定，細節把控不足。 實際測試表明，通過Dify工作流程產生的QA對品質參差不齊，尤其在處理複雜或專業性強的文檔時，容易忽略文本中隱含的知識點和語義細節，導致產生的QA對缺乏準確性與完整性，難以滿足業務情境下的精準服務需求。
跨文檔知識整合能力薄弱。 Dify工作流程僅支援單文檔維度資訊抽取，無法實現多文檔之間的知識關聯與融合，也難以構建具備語義關聯性的知識圖譜網路。這導致產生的QA對僅局限於局部語境，缺乏全域視角，限制了問答系統的綜合推理與泛化能力。
提示詞依賴人工調優，流程自動化程度有限。 為提升產生效果，需頻繁進行提示詞（prompt）的調整與最佳化，依賴大量人工幹預。這種方式不僅增加了使用門檻，也降低了整個流程的自動化水平，影響了大規模部署與持續迭代的可行性。
利用GraphRAG產生QA對
GraphRAG服務是AnalyticDB for PostgreSQL推出的一套可快速部署的檢索增強產生（RAG）解決方案，深度融合了知識圖譜能力。相比傳統基於向量的RAG方法，GraphRAG在處理多文檔情境下的複雜關係建模、多跳推理與知識關聯方面具有顯著優勢。
該服務整體流程分為三個核心階段：
索引：通過知識抽模數型，對文檔進行知識抽取，產生知識圖譜，儲存到圖分析引擎。
檢索：通過知識抽模數型，對Query進行關鍵詞提取，在AnalyticDB for PostgreSQL圖分析引擎中遍曆子圖，搜尋關聯子圖。
產生：將Query和關聯子圖上下文提交給大模型，並產生結果。
前提條件
已上傳相關文檔至GraphRAG應用。
產生高品質Query
GraphRAG服務支援將使用者上傳的文檔內容，自動抽取為向量表示及結構化的知識圖譜，並儲存於 AnalyticDB for PostgreSQL圖分析引擎中。在該體系下，使用者僅需輸入自然語言問題（Query），即可擷取高品質的回答（Answer）。因此，構建高品質QA樣本的核心，已從“如何產生答案”轉變為“如何產生高品質Query”。
由於AnalyticDB for PostgreSQL已整合多份文檔中抽取的知識圖譜資訊，具備跨文檔的關係建模能力，因此只需提供合適的語義引導，即可啟用圖譜中的實體與關係網路，從而產生具有上下文關聯性與跨文檔特性的高品質Query。
基於該功能，阿里雲提出一種基於“元Query”的方法，通過指令引導大模型從多個文檔和功能模組中自動產生多樣化、語義豐富的Query。
元Query樣本：
在GraphRAG應用Retrieval頁面的對話方塊輸入以下文字，使其產生Query。
請根據文檔1、文檔2、文檔3等內容，從 模組1、模組2、模組3等維度出發，提取出50 個高品質的問題，用於回答使用者在使用該產品過程中可能提出的各類疑問。
產生高品質Answer
將產生的Query依次通過AnalyticDB for PostgreSQLGraphRAG應用的檢索功能提問，系統將基於向量與知識圖譜的融合能力，返回跨文檔、結構化的高品質回答。在確認產生的QA對符合知識庫品質要求後，即可將其匯入知識庫，完成問答資料的自動化構建。
業務案例
以下展示了某頭部電商客戶在分別使用Dify工作流程和AnalyticDB for PostgreSQLGraphRAG能力產生QA對的實際輸出對比，體現了兩種方法在問答品質、資訊完整性與跨文檔理解能力方面的差異。
產生Query
Dify工作流程產生的Query | GraphRAG產生的Query |
| 產品名稱相關問題：
主要功能相關問題：
功能路徑相關問題：
使用情境相關問題：
關鍵計量相關問題：
口徑說明相關問題：
售後服務相關問題：
銷售業績相關問題：
其他相關問題：
綜合性問題：
|
通過對比基於Dify產生的Query與GraphRAG產生的Query可以看出：
Dify產生的Query多為結構簡單、範圍局部的問題，通常聚焦於單一功能或文檔關鍵詞，使用者可通過關鍵字直接在文檔中尋找到對應答案。
GraphRAG產生的Query則呈現出更高的複雜度和實用性，覆蓋從局部到全域的知識維度，更貼近真實使用者的提問方式，往往涉及跨文檔理解與多跳推理，具有更強的語義表達能力和實際應用價值。
產生Answer
Dify工作流程產生的Answer | GraphRAG產生的Answer |
如何組建循環性的業績報告用於複盤和考核？ 銷售業績報告中的業績報告模組提供了日報、周報、月報等不同時間周期的報表，並分為匯總、平台/分銷、店鋪/分銷商、店鋪分組四個維度，其中月報還融入了業績目標和完成進度，方便營運人員快速組建循環性業績報告。 | 銷售業績報告如何支援銷售團隊的業績評估？ 銷售業績報告是銷售團隊進行業績評估的重要工具。它提供了多維度資料分析和目標監控功能，協助團隊高效地評估銷售表現、發現問題並最佳化策略。以下是銷售業績報告支援銷售團隊業績評估的主要方式。
總結 銷售業績報告通過目標設定、多維度資料分析、趨勢分析、退款與售後評估、快捷查詢以及即時資料支援等功能，為銷售團隊提供了全面且高效的業績評估工具。這些功能不僅協助團隊精準定位業績增長或下降的原因，還能指導團隊最佳化營運策略，提升整體銷售表現。 References [KG] 銷售業績報告新版本.pdf [KG] 資料門戶.pdf [DC] 銷售業績報告新版本.pdf [KG] relation.txt [KG] 即時商品分析.pdf |
在相同Query輸入條件下，Dify工作流程的回答局限於對單一文檔內容的引用與重複，缺乏上下文理解與資訊整合能力。而GraphRAG則依託知識圖譜與向量檢索機制，有效整合多文檔中的相關知識，輸出更具邏輯性和資訊密度的回答，顯著提升了問答結果的品質與實用性。