“ 大模型并不是無所不能的，在其能力之外我們需要一些工程化能力來解決問題。”

最近有一個功能是根據數據庫表結構生成類似于API說明文檔的功能；但業務需求是讓模型生成文檔之后，還需要對文檔進行審核，也就是說模型生成，模型審核，最終在人工確認。

關于業務需求的合理性就不多說了，我們只單純的討論一下技術實現。

模型生成與審核

從需求端來說，讓模型根據庫表結構生成說明文檔能夠大大提升處理效率，并且節約人工成本，這個邏輯是沒問題的；但問題主要出在第二步審核上；原因就在于，模型生成本身就不穩定，同一個東西兩次生成結果都不一定能完全相同。

因此，在用模型做審核時就出現了一個問題；不論生成的內容質量怎么樣，在審核時都會審出問題，哪怕由人工看起來也是沒問題的，所以這個是不合理的。

理論上來說，審核的作用是查缺補漏，當發現生成的內容有問題時，在審核的過程中發現其中的問題并給予修正；但每次都有問題這不但不合理，而且也接受不了；可能本身生成的內容是正確的，然后審核修正的時候反而變錯的了。

所以，為了解決這個問題，我能想到的唯一的辦法就是優化提示詞，既然審核有問題，那么我就優化生成的提示詞，讓其按照標準約束生成內容，并且審核時也按照標準約束進行審核。

但是實際操作下來卻發現，不論怎么優化提示詞都很難做到審核不出一點問題；哪怕是直接在審核提示詞中明確說明只要沒有明顯的邏輯錯誤和問題，就是對的；但這依然沒解決問題。

所以，從這里我們也能發現從某方面來說，大模型的能力確實是有限的；它就像一個神經病一樣，永遠理解不了人類的需求，也解決不了問題。

但是，抱怨歸抱怨問題還是要解決啊；這時怎么辦呢？

經過很多次的提示詞優化都解決不了問題，這時作者開始懷疑是不是思路有問題，要么就是需求有問題；但從邏輯上來說，需求雖然感覺有點問題，但整體上也不能說有錯。

因此，這時就想起之前同事常說的一句話，既然需求是合理的，那就能做。

所以，這時就考慮換個思路；既然說每次審核都會審出問題，那么在審核之前我先做個判斷，先驗證一下是否需要審核；之后再對生成的文檔進行審核。

說起來可能有點繞，原理就是在審核流程之前加一層判斷；讓模型根據自己的理解，從常理上來判斷一下當前的內容有沒有問題，如果有問題在進行審核，如果沒有問題就不需要審核了。

所以說，大模型雖然能力很強大，但其也是有能力范圍的；當超過其能力范圍時，我們只能通過其它方式來避開或者說從結構層面來解決這些問題。

本文轉載自??????AI探索時代?????? 作者：DFires