一、商業信息查詢介紹

首先來介紹一下商業信息查詢的應用場景。

• 商務合作：評估合作伙伴的資質和規模，判斷合作潛力。
• 銷售展業：快速獲取目標企業的有效聯系方式，加速業務推進。
• 成本控制：通過了解供應商的成本結構和心理底價，運用博弈策略優化采購價格，實現成本節約。
• 消費決策：“職業閉店人”泛濫，如何在辦理各種消費卡時避免踩雷。
• 投資理財：如何選擇股票，避免被“割韭菜”。

以上場景中，有些是現代商業決策的關鍵，有些則與我們個人生活息息相關。要解決這些問題，方案之一就是去查詢這些企業的信息，其投資關系、供應鏈關系，這就是商業信息查詢。

商業信息查詢是一個職場多邊手，能夠助力我們的一些重要決策。

大部分商業信息查詢服務，如天眼查、企查查、愛企查等，主要通過整合來自公開渠道、第三方平臺和官方記錄的海量數據，為用戶提供全面、精準的信息服務。這些平臺收集包括企業注冊信息、財務數據、法律訴訟、行業動態等多元信息，將其產品化，以滿足不同用戶需求。

服務對象廣泛，既面向 B 端企業，幫助企業進行市場調研、競爭對手分析、風險評估等，也惠及 C 端個人用戶，在消費決策、投資理財、職業規劃等方面提供數據支持。以百度旗下愛企查為例，其效果顯著，為用戶提供了高效、便捷的商業信息查詢體驗。通過這些平臺，用戶能夠快速獲取所需信息，做出更明智的商業和生活決策。

我們在去年底開始利用 Copilot 來助力愛企查轉型升級，革新交互體驗，提升商業效率。Copilot 的核心功能在于精準匹配供需雙方，既滿足買家的采購需求，又確保賣家的優質供給，通過高效撮合，促進了雙方的深度交流與合作。

至今年 3 月，Copilot 系統展現出顯著成效，具體表現為：

• 對話滿意度提升 52%：通過智能匹配，對話質量顯著提高，用戶反饋更加積極。
• 對話開口率提升 54%：系統精準推薦，有效提高了雙方溝通的針對性和效率。
• 日均留資量提升 329%：這一商業指標的大幅提升，意味著系統能夠顯著增加用戶的活躍度和粘性，對于愛企查這樣的通用平臺而言，這意味著從免費用戶到付費用戶的轉化率得到了顯著提升。

Copilot 通過優化匹配機制，不僅提升了用戶對話的滿意度和效率，還直接促進了企業的收益增長，增強了用戶體驗。這一成果證明，Copilot 是企業數字化轉型的有效工具。通過 Compiler，企業能夠更加精準地觸達目標客戶，提高轉化率，實現商業目標的同時，也為用戶創造更多價值。

二、文心大模型構建商業智能助手的幾種模式

接下來介紹我們如何利用文心大模型構建商業智能助手。

1. 檢索增強技術（RAG）

第一種模式就是利用檢索增強技術，即檢索一些文檔用做知識增強。然而，單純依賴 RAG 在商業場景下的局限性逐漸顯現，尤其是在面對龐大商業知識庫和復雜企業關系時，直接的網絡文檔檢索往往無法提供準確、深入的信息。這正是愛企查等商業信息查詢平臺存在的價值，它們擁有數億條企業數據和數十億條商業知識，遠超普通搜索引擎的覆蓋范圍。

挑戰與局限在于：

• 理解深度與廣度的缺失：例如查詢企業聯系方式，RAG 往往返回客服電話，而對于銷售或商務合作，這顯然不夠精準。再如騰訊投資案例，RAG 可能列出美團、拼多多，卻忽略了這些公司與騰訊的間接投資關系，以及騰訊內部復雜的投資架構。
• 推理能力的局限：查詢騰訊老板投資的公司，RAG 給出的仍是騰訊直接投資的企業，未能理解“騰訊老板”指代的是馬化騰，且馬化騰的個人投資與騰訊公司投資存在差異。

為克服上述挑戰，我們提出了一種融合企業自建知識庫與文心大模型的解決方案。

首先，對用戶查詢進行深度意圖識別，明確查詢目標是特定企業及所需屬性（如電話、法人等）接著，利用企業知識庫進行精準查詢，將查詢結果反饋給文心大模型，由其生成最終的、高度個性化的回答。

例如，查詢騰訊的聯系電話時，我們先識別出查詢意圖，然后在知識庫中以“騰訊”為 key，“電話”為 value 進行查詢，將結果交由文心大模型處理，生成精確回答。對于騰訊投資的公司，模型不再局限于表面關聯，而是揭示了如華誼兄弟等與騰訊有實際持股比例的復雜關系。

又如，查詢騰訊的法人投資了哪些公司。這時的意圖識別變得更加復雜。為了解決這類復雜查詢，我們提出了知識圖譜檢索方案。

在查詢時，不再是簡單地通過寫一些規則去查，而是利用大模型的代碼生成能力，生成 SQL 查詢語句。然而直接生成代碼的準確率初時較低，大約在 10% 左右，這主要是由于模型對具體數據庫結構理解的不足。

為提高代碼生成的準確率，我們采取了以下兩步優化策略：

• 注入表結構知識：首先，我們向模型中注入數據庫的表結構（schema）信息，幫助模型理解數據庫字段，減少字段匹配錯誤。這一舉措顯著提升了代碼的正確性，準確率可提升至 40% 左右。
• 樣例學習：進一步，我們利用大模型的學習能力，通過提供具體場景下的樣例查詢，讓模型在實際應用中學習和優化。這種 in-context learning（上下文學習）策略使得模型能夠根據樣例調整生成策略，準確率可進一步提升至 70% 到 80%，實現了質的飛躍。

然而，大模型上下文窗口是有限制的，當查詢涉及多表、多字段的復雜數據庫時，直接將所有表結構（schema）信息嵌入 prompt 中變得不切實際。為解決這一問題，我們采用了 schema linking 策略：

• 動態 schema 提取：首先，根據用戶查詢內容，動態識別所需查詢的表及字段，避免一次性加載全部表結構。
• 縮減與優化：通過分析查詢需求，僅將相關表的 schema 信息嵌入 prompt，實現對上下文窗口的有效利用。

最終，這一策略不僅解決了上下文窗口限制，還提升了查詢效率，確保了大模型在復雜數據庫查詢場景下的實際可用性。

去年項目啟動時，我們對零樣本（zero-shot）和少量樣本（few-shot）學習的效果進行了初步調研，比較了文心 ErnieBot、ChatGLM、ChatGLM 精調和 LLaMA-Chinese-alpaca 精調的表現。調研結果表明，盡管這些模型在服務效率上表現出了初步的實用性，但與實際應用落地的高要求相比，仍有不小差距。這一發現促使我們深入研究模型優化策略，特別是如何通過樣例學習（in-context learning）和大模型的反思能力提升模型性能。

我們發現，通過給定特定場景下的樣例，模型能夠學習到更具體的查詢模式，從而顯著提升查詢準確性。然而，模型在生成代碼（如圖數據庫的查詢語句）時，仍可能出現錯誤，這引發了外界對大模型能力的質疑。值得注意的是，大模型具備自我反思與修正的能力，這一特性為提升整體準確率提供了新的途徑。

我們讓模型在生成查詢語句后，進行自我檢查與修正。以圖數據庫為例，模型生成的圖查詢語句（GQL）可能包含邊向性（in/out）錯誤，或存在點與邊的匹配錯誤。通過讓模型反思并修正這些錯誤，查詢的準確性得到了顯著提升。例如，查詢“騰訊有哪些高管？”時，模型能夠識別并修正邊的向性錯誤，將錯誤的“out”改為正確的“in”。同樣，對于“查詢馬化騰在騰訊的職位？”這一問題，模型能夠識別并修正點到點、邊到點的匹配錯誤，確保查詢的準確性。

這一策略的應用，使得模型在復雜查詢場景下的表現大幅提升，最終線上準確率超過 90%。

對于間接投資關系的查詢，模型展現了強大的通用性。例如，查詢“小米公司間接投資了哪些公司？”時，模型能夠追蹤復雜的多層投資鏈，揭示小米通過 A 公司間接投資 B 公司的關系，而無需依賴特定模板。這一能力僅通過大模型的代碼生成與反思能力即可實現，展現了在復雜知識圖譜游走與查詢方面的強大潛力。

三、文心大模型構建商業智能助手進階

在很多場景中，我希望答案通過圖形可視化地呈現。

我們采用了開源工具 Apache ECharts。這一工具提供了很多不同種類的圖表，其中的關系圖非常契合商業信息查詢的場景。

我們設計了一套利用大模型生成可視化圖表的方案。首先，模型被定位為圖表專家，而非傳統的數據庫工程師。用戶提出需求，模型接收查詢結果數據，最后生成圖表。這一方案取得了非常令人滿意的效果。

我們正在探索大模型在更深層次的應用——企業風險分析。這一領域關注企業的可靠性，評估其是否會突然終止運營。通過收集目標公司及其法定代表人的信息，結合關聯公司狀態，我們能夠進行綜合風險分析，為用戶提供全面的公司評估。這一分析過程不僅涉及企業基本信息，還深入考察法定代表人的信用狀況，包括是否被列入失信名單，以及其名下其他公司運營情況。通過整合這些數據，我們能夠提供一個綜合風險評分，幫助用戶判斷企業合作風險。

由于此類深度分析涉及高級商業數據，通常屬于 VIP 服務范疇，我們當前產品的定位為服務于所有用戶，因此這一高級功能尚未正式推出。盡管如此，我們已成功在其他場景中應用了這套風險評估系統，驗證了其有效性和實用性。

四、商業智能助手的未來展望

展望未來，大模型的最終價值在于應用，尤其是如何切實提升我們的工作效率。

以會議場景為例，未來的智能助手將在會議上實現即時數據分析與市場調研，為決策提供數據支持。同時，它能主動思考會議中提出的問題，識別潛在商業機會，評估風險，為討論提供詳實數據，顯著提升會議效率。

這一愿景展現了大模型在日常生活與生產中的最大作用——幫助企業提效。通過智能助手的介入，我們能將更多精力投入創新與決策，讓技術真正服務于人，推動企業與社會的持續進步。

以上就是本次分享的內容，謝謝大家。

五、問答環節

Q1：剛才介紹的應用，除了在愛企查，還有拓展到其它場景嗎？

A1：除了愛企查這一場景，大模型的應用在企業內部數據管理中也展現出廣闊前景。基礎工作圍繞關系數據庫展開，通過 SQL 查詢，實現對內部復雜數據的高效管理。這一工具在公司內部得到廣泛使用，無論是產品經理（PM）還是研發人員（RD），在面對臨時的數據查詢需求時，都頻繁依賴這一工具。然而，由于涉及內部敏感數據，無法公開演示，但其背后的方法論與愛企查場景相似，即通過將自然語言查詢轉化為 SQL 代碼，實現精確的數據檢索。

Q2：Prompt 是依靠特定的模版嗎？

A2：大模型的高效應用依賴于專業的 Prompt 工程。百度強調，未來的工作將從直接編寫代碼轉向設計 Prompt，即如何將自然語言轉化為大模型能理解的輸入格式。這要求工程師具備將專業領域知識融入 Prompt 的能力，以確保大模型能夠準確執行復雜任務，如數據分析、市場調研等。Prompt 設計成為連接人類需求與大模型能力的關鍵橋梁。

Q3：內部應用的效果如何？

A3：在企業內部使用大模型進行數據管理，效果顯著。用戶反饋表明，對于企業用戶而言，問答體驗的提升達到了 50% 以上，顯著增強了數據查詢的效率和準確性。此外，這一工具的應用還為企業帶來了實質性的商業轉化提升，轉化率增長超過 30%，體現了大模型在企業內部數據管理與決策支持中的巨大價值。

大模型在企業內部的應用不僅限于愛企查等公開場景，其在內部數據管理與決策支持中展現出的強大能力，為企業帶來了顯著的效率提升和商業價值。通過專業的 Prompt 工程，大模型能夠理解并執行復雜的數據查詢任務，實現與知識圖譜的深度融合，為企業內部數據的高效管理提供了全新的解決方案。

Q4：我們最開始在去同步整個數據效果的時候提到了對話滿意度是 52%，這個滿意度是怎么算出來的？通過什么方式監測出來的？

A4：滿意度評估基于用戶體驗，如查詢結果的準確性，無法回答的查詢被視為不滿意。目前，評估大模型效果主要依賴人工，通過隨機抽樣數據進行人工檢查，以標簽形式給出滿意度指標。盡管自動化評估是研究方向，使用大模型評估大模型的效果存在可靠性爭議，人依然是最可靠的評估者。當前的評估指標雖嘗試利用大模型進行自我評估，但這種方法的自動化實現面臨挑戰，可靠性尚待驗證。人工評估仍為確保大模型性能和服務質量的關鍵手段。

Q5：對話開口率是什么樣的一個指標？反映的是什么問題？

A5：對話開口率反映用戶與機器人互動的意愿，被視為用戶留存的指標。百度研究院與愛企查平臺合作，采用此指標評估用戶滿意度。若用戶初次查詢獲得滿意回答，次日可能再次互動；反之，不滿意體驗將降低再次提問的可能。通過量化對話開口率，可側面反映問答效果，作為人工評估的補充，間接衡量大模型的性能與用戶接受度。

Q6：如果把樣例放到 prompt 里面，會不會造成提示詞特別臃腫？

A6：大模型處理能力受限于長度，schema linking 成為關鍵，旨在優化內容，避免超長問題。樣例選擇與排序對結果影響重大，需精心挑選與布局。這深入到模型應用的復雜層面，遠超簡單操作，如 APP 構建工具的直覺使用。尤其在數據科學領域，如代碼生成，精準查找要求極高，需大量工作優化樣例與 schema 鏈接，確保模型在長度限制下仍能高效、準確地執行任務。這要求深入理解模型機制，精心設計以應對復雜查詢需求。

Q7：微調的形式和注入樣例的形式對比，有明顯的差距嗎？

A7：微調展現更優效果，因其能全面學習樣本，克服樣例過多導致的注意力分散問題。相比之下，樣例注入雖便捷，但在效果上略遜一籌。微調雖效果顯著，但開發周期與部署成本高昂，需重新部署模型，遠超直接調用 API 的經濟性。我們曾對比 400 條樣例的 schema linking 與微調，微調效果更佳，但成本控制是關鍵考量。在性能提升與成本效益間找到平衡，是優化模型應用的核心。

Q8：Open AI V3.5 為它所有的大模型提供了微調的接口，百度有類似的嗎？

A8：這個微調接口我們肯定是也有的。

百度千帆平臺，作為百度的模型開發與微調平臺，不僅支持自研的文獻模型，還兼容多種開源模型，如 Lama 3，廣泛應用于遷移學習等領域。平臺提供從模型訓練到評估，再到應用程序開發的全套服務，包括數據集管理、數據清洗、數據增強等功能。

用戶可在千帆平臺上進行模型微調、部署及應用程序開發，如構建 APP、模型部署或編寫自定義 Agent。平臺還支持模型評估，允許用戶構建固定集合進行性能檢驗，確保模型質量。總之，千帆平臺為開發者提供了一站式解決方案，覆蓋模型開發全流程，全面助力 AI 模型的高效構建與應用。

Q9：微調用的樣例，包括我們整個微調的過程，上就可以理解為是一種讓大模型預學習，讓他具備某個領域的能力，然后前置地去具備這樣的能力，是這樣嗎？

A9：稍微有點不太準確。

在千帆平臺中，模型層級被定義為 L0、L1、L2 三個階段。L0 代表大模型預訓練階段，即基礎的通用大模型。L1 則為領域對齊模型，通過將特定行業的文檔納入訓練，使模型理解并掌握領域內的專有名詞，提升行業知識理解能力。L2 階段專注于特定任務的微調，如 SQL 生成、代碼撰寫、文檔編寫、續寫或問答，這一階段稱為 task-specific fine-tuning（SFT），旨在讓模型在理解領域知識的基礎上，進一步精煉特定任務的執行能力。