大模型現在已經在各行各業都有廣泛的應用，但是其幻覺問題一直困擾著大家。一方面是廠家在想辦法消除幻覺問題，另一方面，在流程和方法上，我們也可以掌握一些技巧。

現在大模型to C的場景，在chat bot的場景上還是非常不錯的，從PC應用、web、還是移動端來看，使用率和用戶的反饋還是不錯的。

在現在這個時機，能選擇開始使用大模型應用的用戶，這個場景就能過濾掉了非常多普通用戶，基本上是“學習能力強”“思考力強”的用戶，并且大部分使用者，是有“大模型有幻覺”的意識的。

所以在此時的大模型產品開發者對輸出的準確率不做強負責，默認用戶會有一定的分辨能力。

然而，如果是for企業內部的應用場景，如何解決準確率的問題，還有如何讓用戶（員工）用起來的動力。

作為企業應用，有一個核心的問題是，“好多事情和大家的績效掛鉤”

（如果你找到了一個真人，請教一些事情，不論是否有答復，或者說是這個答復是對是錯，都沒問題，有責任人，我甩鍋也算是有對象。

但是如果在很多“培訓”“咨詢”的場景，引入“大模型的助手”，很容易出現，沒有人對結果負責，

鍋沒地兒甩了，總不能讓提問的人來甩吧

所以抵抗幻覺，做好準確率這事，現在就很蛋疼。

但是話說回來，對于已經工作的人來說，讓人對回復多看兩眼，做好風險提示，也算是說的過去。

一、拆解一下企業內部的場景

現在來看，landing比較絲滑的場景，仍然是問答。

并且，這種場景的復用性也是高的，作為產品經理也是愿意干這個的，我在A企業做完，去B企業可以有經驗再來一遍。

所以，在大模型的內部應用來看，我也在引導業務通過這樣的方式來實現。

最近的調研下來來看，基本上是通過【prompt角色扮演+RAG知識庫+強限制】來實現的。

prompt工程來看，這個是好解決的，無外乎，修改測試驗證

但是后兩者是難點，

知識庫的吞吐流程

1）知識庫里的“知識”

首先是知識本身的準確率，在一些企業，存檔做的還不錯，這個也算是能提供

但是如何讓我們的能夠讀明白的文檔，讓大模型本身也讀的明白，

Excel、圖標的ppt、流程圖、腦圖等等不同形式的文檔信息，如何“一鍵向量化”

這可太難了。

所以我們的解決方案，就是運營同學或者各類目文檔的維護人員按照識別效果還不錯的格式，整理一遍。

* 其實這里是有強管理動作在的，管理知識的人不需要問，所以關于這個繁雜的工作如何讓人愿意做，在企業內部也是需要耗費精力去做的。

整理完畢文檔之后，我們上傳大模型平臺，

不管直接的知識庫產品工具，還是自建的知識庫能力。

2）知識的切片

都會進入切片的場景，這里就有一個切的準不準，有沒有切開的問題。

現在常見的知識庫切片邏輯：

按照格式、標點居多。

再或者“適當”的字數，根據語意切的不多見。

切的這個步驟，基本在圖片和表格的信息，就不太能用了。

對了插一句，現在豆包對圖片的識別能力來看，

3）如何通過query找到知識

大模型的邏輯是，先把query語意理解了，然后找到關聯度最高的知識庫知識，

4）大模型輸出的答案：

然后把這些知識和問題按照prompt進行總結輸出。

這里是關于通話大模型進行問答的信息。

所以每個步驟都有不小的風險，一定需要產品親自做測試驗證的。

但是，預防針是，就算每個步驟都參與設定配置，也一定會有偶爾的抽風。

再來一步，作為產品，也需要解決這些抽風問題

提供幾個思路

1. 提供一個“最終解釋權歸屬人”，得讓這個大模型助手又機靈又死板，給自己整個免責聲明。

大模型助手os：“我可以給出答案，但是答案不是我說的”

比如輸出的答案：

-輸入：“如何客戶退款20元的問題？

-輸出：小王在《如何處理客戶投訴問題》內提到：“處理投訴的原文……”

或者，在xxx系統查詢到的xxxx

根據以上查詢的知識，建議方案：…..

(嗯這樣，把整個鍋給提問者找來了，真出問題就能甩了）

2. 讓大模型助手的服務態度好一點

企業內部還有一個痛點是，大家都挺忙的，無法解決的問題，也是讓你A找B，再找C，然后拉個群等等。

所以咱們大模型助手遇到不知道的問題，不妨服務態度好一點，不要直接回復“我不知道”，可以拉滿情緒價值，給打工人一些安慰劑。

就算提問的用戶想要給你個差評，畢竟咱小助手服務態度好，提前不好意思了。

3. 讓專家教教小助手，小助手再教新人

通過上面兩個，

對大模型助手能回答的和不能回答的問題有了一個buffer

但是如何小助手如何成長的機制還沒有建立，

專家對輸出信息的準出進行“調教”

設定一些敏感信息的指定回答方案。并且定期review知識本身的數據

如何解決讓用戶/員工用起來的問題

作為平級部門，我們做了個一個很好用的工具，能幫你解決80%的dirty work，你會用嗎

如果公司內部有強有力的1號位把這個AI工具提到了戰略層級，通過管理手段讓用戶用起來是好的，

但是就算這種情況大概率工具會面臨“甩鍋”的問題，做提效工具的反而被背刺

但是，如果發現這里有一個助手收錄了行業的關鍵詞條（哪怕是互聯網的），并且收錄了公司的各種文檔，還有更多的sop，那么作為提問人，去找這個不是人的人問一下，會不會降低一下提問人的羞恥感呢

或者說，有業務要向產品提需求，總是被diss沒想清楚，方案不成熟，

那用戶是否有機會和這個大模型助手先描述一遍你要實現什么場景呢，（其實這個倒是很簡單了，提供一個需求分析的prompt給大模型助手即可）

所以這里就又推理出了一個方案，

提供一些角色扮演

（類似公司的崗位，通過prompt讓他具備這個行業的一些基礎能力）

集成在大模型助手內，讓他具備一些個新場景。

除此之外，就是和上文的知識庫類似，

找到owner為知識庫負責。