如何讓 ChatGPT 讀懂超長保險條款？
本文作者是螞蟻集團前端工程師阿相，如何讓 ChatGPT 成功解讀晦澀難懂的超長保險條款，阿相分享了他的解決方案，相關(guān)代碼已開源，歡迎一起交流～
前言
在去年年底 ChatGPT 剛火的時候我就有一個想法，它能不能幫我讀一下晦澀難懂的保險條款，告訴我它到底在講什么？到底什么病能賠多少錢？甚至能告訴我里面是不是藏有一些坑？但是當(dāng)我把條款內(nèi)容復(fù)制到 ChatGPT 時，我們會發(fā)現(xiàn)，它直接告訴你：“文檔太長了，它處理不了”。
當(dāng)我們自己打開 openai 的文檔（https://platform.openai.com/docs/api-reference/completions/create），我們才明白：哦，原來它接受的最大長度是?4096個?tokens。但這個 一個?token?到底是多長呢？暫時還不知道，反正就是有這么個上限。很顯然，我們的保險條款遠(yuǎn)遠(yuǎn)的超過了它的上限，因為我才復(fù)制兩三頁的內(nèi)容它就?Error?了。
但我們還是納悶，不應(yīng)該啊，ChatGPT 不應(yīng)該很強嗎？它的官方例子可是擺了幾十個案例，看網(wǎng)上的各種文章，它似乎在文字與編碼領(lǐng)域，遠(yuǎn)超絕大數(shù)人類，怎么會連個保險條款都無法承受。
我想從這個案例中看看有沒有其他路子，可惜確實沒有合適的案例能解決我這種超長文本的訴求。于是我停止了這個想法，并先回家過了個快樂的新年。
但在最近，在我的不屑但可能沒啥意義的努力下，我?guī)缀跬瓿闪诉@個想法。先放幾個截圖給大家看看。
問螞蟻爆款「好醫(yī)保長期醫(yī)療」幾個問題的答案：
問市面上很火的「達爾文 7 號重疾」的問題及答案：
如果你仔細(xì)看，你會發(fā)現(xiàn)，它已經(jīng)能非常準(zhǔn)確的回答這幾個很多保險小白常問的問題了。那我到底是怎么實現(xiàn)的呢？這篇文章來一探究竟。
先糾正一下
在我開始正文之前，先讓 ChatGPT 跟大家做個簡單介紹。
所以本文標(biāo)題其實不對，準(zhǔn)確說應(yīng)該是「如何讓 openai 的 API 幫我讀懂保險條款」。因為我其實是調(diào)用了 openai 提供的 API 能力來滿足需求的。更準(zhǔn)確來說是調(diào)用了其 GPT-3 的一些模型，而不是掛代理直接問 ChatGPT。但為了大部分讀者容易理解，就先取一個不恰當(dāng)?shù)臉?biāo)題了。
后文中，我將會以 GPT 通用指代我所調(diào)用的 openai 的 API 服務(wù)。
核心解決方案
話說在新年回來后，ChatGPT 仍愈演愈烈，因此我又來了點兒興趣，并嘗試把 GPT 接入我一個年久失修的個人公眾號。就在這個接入的過程中，為了解決接入遇到的不少問題，我看了不少文檔。果然是開卷有益，實干興邦啊。過程中我又接觸學(xué)習(xí)了一些有用知識。其中最重要的是兩個點知識：
其一是：GPT 的多輪對話是如何實現(xiàn)的？其實很簡單，就是把歷史對話都存起來，然后按照時序重新拼接，再加上這次的問題，合并一起作為?prompt再傳給 GPT 即可。
其二就是，如何讓 GPT 理解超長文本知識并做問題回答？我在逛 openai 官方文檔的時候，發(fā)現(xiàn)了其實人家早早就想到了這個問題，并貼心的準(zhǔn)備好了教程文檔。這在我上一篇 ChaGPT 的文章中也已提到：公眾號如何接入 ChatGPT 及 一些感想
How to build an AI that can answer questions about your website：https://platform.openai.com/docs/tutorials/web-qa-embeddings
Question Answering using Embeddings：https://github.com/openai/openai-cookbook/blob/main/examples/Question_answering_using_embeddings.ipynb
它的思路其實很好理解，詳細(xì)來說，主要是分幾步：
先將巨量的文檔知識拆塊，并使用 openai 提供的
Embeddings能力將該部分內(nèi)容向量化，并做映射存儲。向量化的目的是為了做兩部分文本的相似性匹配。關(guān)于它的文檔在這：https://platform.openai.com/docs/guides/embeddings/what-are-embeddings當(dāng)用戶提問時，將用戶的「提問文本」也做向量化。
遍歷已拆塊并向量化的文檔內(nèi)容，將之與向量化后的「提問文本」做內(nèi)容相似性比較，找到最為相似的文檔內(nèi)容向量。
根據(jù)之前的映射關(guān)系，找到這段「向量」映射著的原始文檔內(nèi)容塊。并把這個內(nèi)容塊作為上下文傳給 GPT。
GPT 會根據(jù)這段上下文回答用戶的提問。
原來如此，那么我只要把保險條款分段向量化，再根據(jù)用戶提問匹配到相應(yīng)的那段內(nèi)容再回答不就好了嗎。簡單，上手吧。
把大象放進冰箱需要幾步？
這個問題似乎正如「把大象放入冰箱」。描述起來很簡單，真正要做起來就舉步維艱。
在我們面前最大的問題就是，到底怎么把這個文檔做分割？
最簡單的方案自然是，把保險條款按頁碼一頁一頁分塊，如果一頁內(nèi)容也超了，那我們就半頁半頁分塊。
但這忽略了一個最大的問題，就像大象的各個器官并非水平均分分布一樣，知識內(nèi)容并非是按頁碼分割的。
一個知識可能第三頁正好起了個標(biāo)題，第四頁才是詳細(xì)的描述。而向量化匹配的時候，卻可能只匹配到第三頁的內(nèi)容。比如這個「好醫(yī)保長期醫(yī)療」的責(zé)任免除條款，就很容易丟失下半部分的免除責(zé)任，造成回答準(zhǔn)確性降低。
除此外，這樣的分割還容易讓 GPT “學(xué)壞”。因為粗暴的按頁分割，很容易把無關(guān)的知識傳給 GPT，導(dǎo)致它可能會因為這些無關(guān)的信息返回錯誤的答案。比如如下關(guān)于用戶信息告知的條款：前一頁內(nèi)容如下：
后一頁內(nèi)容如下：
如果你詢問的問題是：“如果投保時年齡填寫錯誤，理賠時會怎么樣”。
那很有可能你只會將第一頁內(nèi)容傳給 GPT，它將會告訴你保司不承擔(dān)任何責(zé)任，并不退回保險費。
而用我實現(xiàn)的服務(wù)所拼接的知識塊，得到的版本答案如下：
顯然這個問題得到了準(zhǔn)確回答。
以上兩個案例比較生動的說明了分割的重要性。
如何分割文檔
懂得了很多道理，也依舊過不好這一生。? ? ? ? ? ? ??
- ChatGPT也不知道是誰說的
如何分割文檔？其實這個也很好想方案，只是比較難搞。保險條款是有文章結(jié)構(gòu)的，只要咱們可以按文章標(biāo)題給文檔做結(jié)構(gòu)化就好了。最終文檔就會成為這樣的一個文檔樹：
然后我們在深度遍歷這個文檔樹，去識別每個節(jié)點所包含的所有內(nèi)容的長度，達到一定閾值就剪下來作為一個「知識塊」。這就像剪一個西蘭花 ??，按自己可以含進去的大小，一朵朵剪下來。
通過這樣的手段，我們就能在滿足知識文本長度的限制下，切下最為連續(xù)完整的知識內(nèi)容。這其實很簡單，但如果一定要裝逼取個算法名的話，那我稱之為：西蘭花算法 ??。
但在我們切割西蘭花之前，還有一個棘手的問題，怎么把一個條款文檔先變成一棵西蘭花（一顆文檔樹）？
第 0 步：先明白?tokens?咋回事
因為后文很多內(nèi)容都跟這個tokens相關(guān)，所以我必須得提前介紹一下。
有時間的同學(xué)可以直接看官網(wǎng)介紹文檔：https://help.openai.com/en/articles/4936856-what-are-tokens-and-how-to-count-them
沒時間的同學(xué)可以繼續(xù)聽我簡單總結(jié)一下：
tokens?不是指?prompt?字符串的長度；token指的是一段話中可能被分出來的詞匯。比如：i love you，就是三個token，分別為 「i」「love」「you」。不同語言
token計算不一樣，比如中文的「我愛你」其實是算 5 個?token，因為它會先把內(nèi)容轉(zhuǎn)成?unicode。讀過我公眾號那篇文章的同學(xué)，關(guān)于 Emoji 你不知道的事，你們就會知道，有些 emoji 的token長度會超出你的想象。
你可以用這個網(wǎng)站在線體驗?zāi)愕奈淖值?code>token長度：https://platform.openai.com/tokenizer
在
node.js環(huán)境中，你可以用 gpt-3-encoder 這個 npm 包來計算?tokens的長度。
OK，掌握這些知識就足夠理解我們后文的內(nèi)容了。
第 1 步：標(biāo)題的識別
我們可以先看看市面比較火爆的醫(yī)療與重疾險產(chǎn)品的條款。發(fā)現(xiàn)其實保險大部分條款是有一定格式標(biāo)準(zhǔn)的。幾乎都是嵌套數(shù)字標(biāo)題 + 內(nèi)容。
那是否可以依據(jù)一定的規(guī)則，識別出那部分是標(biāo)題，然后根據(jù)標(biāo)題做切割即可？比如說，根據(jù) 「數(shù)字 + ·? + 數(shù)字?」的正則做匹配。
雖然我正則寫不來，但是 ChatGPT 寫的來呀：
雖然它的回答不夠完美，但是基本夠我們繼續(xù)下一步編碼了。于是我嘗試把 PDF 的全文內(nèi)容復(fù)制出來，并做分割。然后我就會發(fā)現(xiàn)幾個很麻煩的地方：
數(shù)字不是只在標(biāo)題中出現(xiàn)，正文中也很容易出現(xiàn)各種數(shù)字。
有些注釋內(nèi)容，也有數(shù)字+內(nèi)容的出現(xiàn)
所以我們復(fù)制出來的文本是這樣的：
所以，如果只是粗暴的根據(jù)某種標(biāo)題規(guī)則來做分割，那我們只會得到錯亂的結(jié)果。
那我們?nèi)搜凼侨绾螐捻撁嬷兄浪菢?biāo)題的呢？我們自然是根據(jù)這個文案的位置、大小，綜合了我們的歷史經(jīng)驗來判斷它是不是標(biāo)題。也就是說，要想真正從一段文本中做很好的標(biāo)題識別以及內(nèi)容分割，必須要獲取這段文本的其他元數(shù)據(jù)。
我的下意識，自然是希望還有 AI 的能力。我把 PDF 轉(zhuǎn)圖片，都傳給某個 AI，它很聰明，幫我 OCR 識別文檔并做好了充分的文檔結(jié)構(gòu)化。
但我在 openai 官網(wǎng)并沒有找到這樣的 api 能力提供。由于我的 AI 儲備非常薄弱，我也很難在網(wǎng)上找到可以滿足我訴求的開源工具。而且根據(jù)我很可能不成熟的感覺，我感覺現(xiàn)在訓(xùn)練出來的開源 AI 模型，頂多只是識別出文字以及文字所在的絕對位置，也很難幫我直接把文檔給按照標(biāo)題結(jié)構(gòu)化了。真有這樣的需求，可能需要我自己準(zhǔn)備大量材料來訓(xùn)練。這似乎再一次難倒了我。
于是我又想到了?pdf.js這個工具。我們 C端 部分投保協(xié)議就是利用這個工具包，把 PDF 文檔轉(zhuǎn)成 DOM 渲染到頁面上。雖然我之前并沒有使用過，但我相信它肯定可以拿到 PDF 上很多元數(shù)據(jù)，否則不可能做到還原成 DOM 去渲染。我甚至想，它有沒有可能直接幫我轉(zhuǎn)成一顆 根據(jù)標(biāo)題已經(jīng)結(jié)構(gòu)化好的 DOM 樹。
在我使用pdf.js后，我發(fā)現(xiàn)，剛才稍微想的有點多了，但也足夠用了。它能把 PDF 文檔的文字塊以及這個文字塊的文字與大小信息 解構(gòu)出來。比如這樣：
其中的?width與height決定了文字塊的大小，transform決定了文字塊在文檔上的絕對位置信息。pdf.js也是根據(jù)這些信息，把 PDF 內(nèi)容以絕對位置與大小一個個的轉(zhuǎn)成 DOM 并繪制在網(wǎng)頁上。它不理解前后語序與內(nèi)容結(jié)果，它只是粗暴的拼裝。
但這對我來說已經(jīng)夠用了，有了這些信息，我就能分析出哪些文字塊是標(biāo)題，哪些文字塊是正文的正常數(shù)字，哪些內(nèi)容塊是底部的注釋內(nèi)容。比如說：
出現(xiàn)最多的字體大小，有理由相信這就是正文字體大小
持續(xù)出現(xiàn)的一個很靠左的 X 坐標(biāo)，且該坐標(biāo)內(nèi)容基本是數(shù)字，有理由相信，這就是數(shù)字標(biāo)題或數(shù)字注釋所在的 X 坐標(biāo)
雖然符合上述第二條規(guī)則，但卻比正文字體小很多，有理由相信，這是注釋前的數(shù)字
等等等等吧，除此外，我們還需要判斷什么時候到注釋內(nèi)容，什么是頁碼內(nèi)容。因為這些內(nèi)容都要做一些特殊處理。另外就是不同文檔可能有些特殊的邊界情況要處理一下。
雖然說這依舊很人肉，不智能，但至少能把路走通了。至于有些不是以 x.x.x 這樣的數(shù)字做標(biāo)題的文檔，比如：第一章、第一節(jié)什么的，還是能拓展的，但就先不考慮了。
第 2 步：過長內(nèi)容摘要化
事情走到這一步，大問題就沒有了。但實際應(yīng)用的時候，我們還是會發(fā)現(xiàn)一個小問題，就是很多小節(jié)的內(nèi)容其實比較長，我們能做相似性映射的知識塊其實往往不僅一塊。當(dāng)我們拼接多塊知識的時候，內(nèi)容又超出了。而如果我們只拼接一塊內(nèi)容，知識又不夠完整。這又讓我們抓耳撓腮了。
我仔細(xì)看了看這些小節(jié)的內(nèi)容，我覺得，其實這段文本，要是用文言文來說，可能還可以再短一點（漢語真是博大精深）。但是我覺得如果讓 GPT 幫我把它轉(zhuǎn)成文言文的話，用戶提問的問題很可能就映射不到了。當(dāng)然，我也真的試了一下，發(fā)現(xiàn)?text-davinci-003這個模型似乎在文言文領(lǐng)域也不太行，保險條款它很難轉(zhuǎn)成文言文。
但我有了另外一個思路，就是保險條款其實廢話還是有些多的，我可以讓 GPT 幫我做一些摘要性的總結(jié)，且盡量不丟失最核心的有效知識。在我網(wǎng)上搜索這塊相關(guān)的知識時，發(fā)現(xiàn) NLP 領(lǐng)域有一種叫「命名實體識別（https://baike.baidu.com/item/%E5%91%BD%E5%90%8D%E5%AE%9E%E4%BD%93%E8%AF%86%E5%88%AB/6968430）」的技術(shù)，常用于搜索引擎、信息提取、問答系統(tǒng)中。不管三七二十一了，openai 這么強大，那我就這么讓它幫我這么做吧。
實際測試下來，這樣的方式相比直接總結(jié)摘要，從最終效果來看，返回的結(jié)果會穩(wěn)定很多，且返回的知識不會只說到一半。具體原因也不懂，有資深的大佬可以幫忙指點一下。
經(jīng)過這樣摘要化以后，我們就能把一段較長的知識文本給有效縮短。當(dāng)用戶問起相關(guān)知識時，可以調(diào)用更多的知識塊來回答用戶。
第 3 步：超長內(nèi)容極限壓縮
事情走到這一步，你可能以為就真沒啥問題了。但實際上我們又遇到了個小麻煩。就是有部分小節(jié)的內(nèi)容依舊還是太長了。就像一顆基因變異的西蘭花 ??。
我已經(jīng)剪到最小的分支了，但這個最小的分支依舊超過了max_tokens的限制。這又難倒我了，現(xiàn)在我該怎么分割它？這似乎回到了我最開始遇到的問題。不過好在，這些變異的西蘭花并沒有動畫靈能百分百中的那么夸張，大部分還只是 略超?max_tokens一些，幾乎不會超過其兩倍。而自己觀察這些超出去的內(nèi)容，往往是兩種類型。
較長的表格，比如藥品列表，如下圖 1。
一些責(zé)任或疾病的詳細(xì)介紹，如下圖 2。
我們發(fā)現(xiàn)這些小節(jié)的內(nèi)容，其實并不適合分割。比如藥品列表要是分割成兩塊接近max_tokens的知識內(nèi)容，一次性問答只能獲取其中一塊知識。這就會導(dǎo)致回答錯誤。比如你問有多少種藥品可以報銷，它自然會算錯。責(zé)任也是一樣。
但這些小節(jié)有另外一個方向，就是壓縮內(nèi)容。里面有很多文字其實是相似的，比如一堆的社保目錄內(nèi)/外。比如責(zé)任內(nèi)容中頻繁出現(xiàn)的：惡性腫瘤 保險金 被保險人等等。我們只要做一本字典，把這些很長的重復(fù)性文字，用另外一種特殊的較短的字符指代。這段長文本就會瞬間被壓縮到較短的文本，我們再連同字典一起發(fā)給 GPT，讓它再翻譯回來并做摘要化，于是就繞過了max_tokens的限制。
但問題又來了，說的容易，代碼怎么知道哪些文字是一段詞語？如果代碼不知道哪些文字是一段詞語，又怎么做字典映射。總不能自己先把所有可能的詞匯都預(yù)先想好吧。雖然保險有一些專業(yè)術(shù)語可以提前預(yù)設(shè)，但總歸有更多的未知的。
這就引出了 NLP 領(lǐng)域的另外一門技術(shù)，分詞。很開心的是，在中文領(lǐng)域，且在 node.js 生態(tài)中，有一個比較好用的分詞工具「結(jié)巴分詞-https://github.com/yanyiwu/nodejieba」。不出意外，這也是 ChatGPT 告訴我的。
運用這個結(jié)巴分詞，我們就可以把一段內(nèi)容分割成一個個詞匯，同時也支持傳入用戶預(yù)設(shè)的詞匯字典。這樣我們就能知道哪些詞匯在一段文本中被重復(fù)使用多次。對于這些詞匯，我們再用一個最短的字符去映射它。
為了映射的字符盡量的短，我也是撓了一下腦袋，本來最簡單就是一個特殊字符加上從1遞增的數(shù)字就好了，比如這樣：*${index}。但是這個方式經(jīng)過我實測，壓縮完的tokens效果還不夠極致?？紤]到我們都是基本是中文環(huán)境，我最終選擇了 26個字母大小寫 + 24個拉丁字母大小寫作為索引：
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZαβγδεζηθικλμνξοπρστυφχψωΑΒΓΔΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΩ
根據(jù)第 0 步的知識，我們知道，千萬別用 emoji 去做字典索引。
這樣我們就得到最多100個索引，當(dāng)然如果內(nèi)容中已有出現(xiàn)具體的字母，最好還是針對該段內(nèi)容剔除該字母。經(jīng)過實際測試，這樣的壓縮效果會比數(shù)字映射法稍微好一些。且經(jīng)過實測，這樣問 openai 依舊能得到正確答案。舉個例子：
上文中的，相學(xué)長白天吃飯,相學(xué)長中午也吃飯,相學(xué)長晚上還吃飯
會被轉(zhuǎn)化成，a白天b,a中午也b,a晚上還b|上文中,a:相學(xué)長,b:吃飯
我們把這句話拿去問 GPT：相學(xué)長每天都在做什么。它能給出正確的回答：相學(xué)長每天都在吃飯。
除了字典法壓縮外，其實還有一個也比較顯著的手段。就是把全角字符全部轉(zhuǎn)成半角字符。在我的實際測試中，一段 8247 個tokens長度的內(nèi)容。換半角相比不換半角，能多壓縮 580 個tokens，簡直是效果驚人！
其實不僅僅超過max_tokens的文本需要壓縮。我建議超過 3000?tokens的文本都得壓縮一下。因為 openai 最大的 4096 個token限制。并非是限制?prompt。而是限制?prompt+ 它的答案。也就是說，當(dāng)我們做摘要化的時候，如果我們提供的原始內(nèi)容越長，它能返回的摘要就越短。這顯然不符合我們的訴求。所以，雖然文章中這里寫著是第三步，但實際操作時，壓縮其實是第二步，壓縮需要在摘要化之前。
也是因為max_tokens的計算涵蓋了 GPT 的回答內(nèi)容，所以當(dāng)我們根據(jù)用戶提問拼接知識塊的時候，不能按照?max_tokens的限制去打滿內(nèi)容，盡量留出 幾百到一千的?tokens給 GPT 做回答。
在我實操過程中呢，其實還存在一個文檔的內(nèi)容，怎么壓縮也壓縮不到預(yù)期的長度。我確實選擇了逃避，因為這段內(nèi)容是無數(shù)個疾病的詳細(xì)介紹，我騙自己說這些詳細(xì)介紹并沒太大用。因此最終我做了一個特殊處理，如果是這個超長的疾病介紹，我就只保留了疾病標(biāo)題，去掉了疾病的內(nèi)容。
針對這種，再壓縮也解決不了的問題，我目前確實還沒找到非常好的解法。
最終經(jīng)過我們對 PDF 文檔的分割、壓縮、小節(jié)內(nèi)容摘要化、轉(zhuǎn)成嵌套文檔樹，最終再上一個西蘭花算法。我們就能完成對這個 PDF 文檔的合理分割了。最終我們再把分割后的內(nèi)容做向量化處理，就能實現(xiàn)一個比較好的基于超長保單文檔的保險產(chǎn)品問答服務(wù)。
其實其他領(lǐng)域的文檔也差不多，只要這個文檔結(jié)構(gòu)比較好切割。
代碼已開源
?? 相關(guān)代碼開源，有興趣的同學(xué)自己下載繼續(xù)研究吧~ https://github.com/wuomzfx/pdfGPT
關(guān)于到底怎么做向量化、怎么做匹配，我在本文就不多說了，這個還是比較容易了。包括其他還有一些特殊的處理，比如怎么把注釋內(nèi)容拼接到正文里。這些都可以在源碼中方便尋找到。其他可能還稍微需要一點工具知識的，就是 node 中如何做兩個?embedding?向量的相似性匹配。用?@stblib/blas這個 npm 包就行。DEMO 示例：
如果還有哪里不明白的，歡迎評論區(qū)或者先嘗試問下 ChatGPT~
最后一點小感悟
感覺人工智能的時代真的要到來了，連我這種 AI 小白，似乎都已經(jīng)能完成一個可能真的能投入使用的服務(wù)。我再整個小程序，糊個頁面，把一些異常容錯機制再完善完善。再稍微整個爬蟲，從保險行業(yè)協(xié)會網(wǎng)站幫用戶快捷找到相關(guān)的保險條款。我?guī)缀蹙湍軐崿F(xiàn)一個幫助用戶回答保險產(chǎn)品的應(yīng)用了。
亦或者，我可以自己預(yù)設(shè)一些問題。通過這些問題，我可以從保險條款中結(jié)構(gòu)化出很多有效的信息，比如保額保費、責(zé)任細(xì)節(jié)、投保年限、續(xù)保年限等等。結(jié)構(gòu)化之后，我又可以直接做不同產(chǎn)品的對比，根據(jù)用戶的要求推薦比較合適的保險產(chǎn)品。這是一件挺有可能的事情，我嘗試把之前的兩個問答作為對比再次問 GPT 推薦哪款產(chǎn)品，它的回答比較中肯且有用。
總之，新的 AI 基礎(chǔ)設(shè)施，已經(jīng)能成為現(xiàn)在大部分工程師的有利工具。在某些垂直領(lǐng)域做一些深入研究，通過這些工具，AI 就能發(fā)揮出意想不到的作用，我們可以快速的產(chǎn)出各種有意思的產(chǎn)品。就好像 HTML5 跟 小程序 帶來一系列有意思的 輕量APP 一樣。相信，AI 浪潮在這兩年就要席卷而來了~~
