原標(biāo)題：基于亞馬遜云科技的大語言模型知識(shí)問答應(yīng)用落地實(shí)踐

　　隨著大語言模型效果明顯提升，其相關(guān)的應(yīng)用不斷涌現(xiàn)呈現(xiàn)出越來越火爆的趨勢(shì)。其中一種比較被廣泛關(guān)注的技術(shù)路線是大語言模型(LLM)+知識(shí)召回(Knowledge Retrieval)的方式，在私域知識(shí)問答方面可以很好的彌補(bǔ)通用大語言模型的一些短板，解決通用大語言模型在專業(yè)領(lǐng)域回答缺乏依據(jù)、存在幻覺等問題。其基本思路是把私域知識(shí)文檔進(jìn)行切片然后向量化后續(xù)通過向量檢索進(jìn)行召回，再作為上下文輸入到大語言模型進(jìn)行歸納總結(jié)。

　　在這個(gè)技術(shù)方向的具體實(shí)踐中，知識(shí)庫可以采取基于倒排和基于向量的兩種索引方式進(jìn)行構(gòu)建，它對(duì)于知識(shí)問答流程中的知識(shí)召回這步起關(guān)鍵作用，和普通的文檔索引或日志索引不同，知識(shí)的向量化需要借助深度模型的語義化能力，存在文檔切分，向量模型部署&推理等額外步驟。知識(shí)向量化建庫過程中，不僅僅需要考慮原始的文檔量級(jí)，還需要考慮切分粒度，向量維度等因素，最終被向量數(shù)據(jù)庫索引的知識(shí)條數(shù)可能達(dá)到一個(gè)非常大的量級(jí)，可能由以下兩方面的原因引起：

　　各個(gè)行業(yè)的既有文檔量很高，如金融、醫(yī)藥、法律領(lǐng)域等，新增量也很大。

　　為了召回效果的追求，對(duì)文檔的切分常常會(huì)采用按句或者按段進(jìn)行多粒度的冗余存貯。

　　這些細(xì)節(jié)對(duì)知識(shí)向量數(shù)據(jù)庫的寫入和查詢性能帶來一定的挑戰(zhàn)，為了優(yōu)化向量化知識(shí)庫的構(gòu)建和管理，基于亞馬遜云科技的服務(wù)，構(gòu)建了如下圖的知識(shí)庫構(gòu)建流程：

　　通過S3 Bucket的Handler實(shí)時(shí)觸發(fā)Lambda啟動(dòng)對(duì)應(yīng)知識(shí)文件入庫的Glue job

　　Glue Job中會(huì)進(jìn)行文檔解析和拆分，并調(diào)用SageMaker的Embedding模型進(jìn)行向量化

　　通過Bulk方式注入到Amazon OpenSearch中去

　　并對(duì)整個(gè)流程中涉及的多個(gè)方面，包括如何進(jìn)行知識(shí)向量化，向量數(shù)據(jù)庫調(diào)優(yōu)總結(jié)了一些 實(shí)踐和心得。

　　知識(shí)向量化

　　文檔拆分

　　知識(shí)向量化的前置步驟是進(jìn)行知識(shí)的拆分，語義完整性的保持是最重要的考量。分兩個(gè)方面展開討論。該如何選用以下兩個(gè)關(guān)注點(diǎn)分別總結(jié)了一些經(jīng)驗(yàn)：

　　a. 拆分片段的方法

　　關(guān)于這部分的工作，Langchain作為一種流行的大語言模型集成框架，提供了非常多的Document Loader和Text Spiltters，其中的一些實(shí)現(xiàn)具有借鑒意義，但也有不少實(shí)現(xiàn)效果是重復(fù)的。

　　目前使用較多的基礎(chǔ)方式是采用Langchain中的RecursiveCharacterTextSplitter，屬于是Langchain的默認(rèn)拆分器。它采用這個(gè)多級(jí)分隔字符列表——[“\n\n”， “\n”， ” “， “”]來進(jìn)行拆分，默認(rèn)先按照段落做拆分，如果拆分結(jié)果的chunk_size超出，再繼續(xù)利用下一級(jí)分隔字符繼續(xù)拆分，直到滿足chunk_size的要求。

　　但這種做法相對(duì)來說還是比較粗糙，還是可能會(huì)造成一些關(guān)鍵內(nèi)容會(huì)被拆開。對(duì)于一些其他的文檔格式可以有一些更細(xì)致的做法。

　　FAQ文件，必須按照一問一答粒度拆分，后續(xù)向量化的輸入可以僅僅使用問題，也可以使用問題+答案

　　Markdown文件，”#”是用于標(biāo)識(shí)標(biāo)題的特殊字符，可以采用MarkdownHeaderTextSplitter作為分割器，它能更好的保證內(nèi)容和標(biāo)題對(duì)應(yīng)的被提取出來。

　　PDF文件，會(huì)包含更豐富的格式信息。Langchain里面提供了非常多的Loader，但Langchain中的PDFMinerPDFasHTMLLoader的切分效果上會(huì)更好，它把PDF轉(zhuǎn)換成HTML，通過HTML的

　　塊進(jìn)行切分，這種方式能保留每個(gè)塊的字號(hào)信息，從而可以推導(dǎo)出每塊內(nèi)容的隸屬關(guān)系，把一個(gè)段落的標(biāo)題和上一級(jí)父標(biāo)題關(guān)聯(lián)上，使得信息更加完整。

　　b. 模型對(duì)片段長(zhǎng)度的支持

　　由于拆分的片段后續(xù)需要通過向量化模型進(jìn)行推理，所以必須考慮向量化模型的Max_seq_length的限制，超出這個(gè)限制可能會(huì)導(dǎo)致出現(xiàn)截?cái)�，�?dǎo)致語義不完整。從支持的Max_seq_length來劃分，目前主要有兩類Embedding模型，如下表所示(這四個(gè)是有過實(shí)踐經(jīng)驗(yàn)的模型)。

　　這里的Max_seq_length是指Token數(shù)，和字符數(shù)并不等價(jià)。依據(jù)之前的測(cè)試經(jīng)驗(yàn)，前三個(gè)模型一個(gè)token約為1.5個(gè)漢字字符左右。而對(duì)于大語言模型，如chatglm，一個(gè)token一般為2個(gè)字符左右。如果在切分時(shí)不方便計(jì)算token數(shù)，也可以簡(jiǎn)單按照這個(gè)比例來簡(jiǎn)單換算，保證不出現(xiàn)截?cái)嗟那闆r。

　　前三個(gè)模型屬于基于Bert的Embedding模型，OpenAI的text-embedding-ada-002模型是基于GPT3的模型。前者適合句或者短段落的向量化，后者OpenAI的SAAS化接口，適合長(zhǎng)文本的向量化，但不能私有化部署。

　　可以根據(jù)召回效果進(jìn)行驗(yàn)證選擇。從目前的實(shí)踐經(jīng)驗(yàn)上看text-embedding-ada-002對(duì)于中文的相似性打分排序性可以，但區(qū)分度不夠(集中0.7左右)，不太利于直接通過閾值判斷是否有相似知識(shí)召回。

　　另外，對(duì)于長(zhǎng)度限制的問題也有另外一種改善方法，可以對(duì)拆分的片段進(jìn)行編號(hào)，相鄰的片段編號(hào)也臨近，當(dāng)召回其中一個(gè)片段時(shí)，可以通過向量數(shù)據(jù)庫的range search把附近的片段也召回回來，也能保證召回內(nèi)容的語意完整性。

　　向量化模型選擇

　　前面提到四個(gè)模型只是提到了模型對(duì)于文本長(zhǎng)度的支持差異，效果方面目前并沒有非常權(quán)威的結(jié)論�？梢酝ㄟ^leaderboard來了解各個(gè)模型的性能，榜上的大多數(shù)的模型的評(píng)測(cè)還是基于公開數(shù)據(jù)集的benchmark，對(duì)于真實(shí)生產(chǎn)中的場(chǎng)景benchmark結(jié)論是否成立還需要case by case地來看。但原則上有以下幾方面的經(jīng)驗(yàn)可以分享：

　　經(jīng)過垂直領(lǐng)域Finetune的模型比原始向量模型有明顯優(yōu)勢(shì)

　　目前的向量化模型分為兩類，對(duì)稱和非對(duì)稱。未進(jìn)行微調(diào)的情況下，對(duì)于FAQ建議走對(duì)稱召回，也就是Query到Question的召回。對(duì)于文檔片段知識(shí)，建議使用非對(duì)稱召回模型，也就是Query到Answer(文檔片段)的召回。

　　沒有效果上的明顯的差異的情況下，盡量選擇向量維度短的模型，高維向量(如openai的text-embedding-ada-002)會(huì)給向量數(shù)據(jù)庫造成檢索性能和成本兩方面的壓力。

　　向量化并行

　　真實(shí)的業(yè)務(wù)場(chǎng)景中，文檔的規(guī)模在百到百萬這個(gè)數(shù)量級(jí)之間。按照冗余的多級(jí)召回方式，對(duì)應(yīng)的知識(shí)條目 可能達(dá)到億的規(guī)模。由于整個(gè)離線計(jì)算的規(guī)模很大，所以必須并發(fā)進(jìn)行，否則無法滿足知識(shí)新增和向量檢索效果迭代的要求。步驟上主要分為以下三個(gè)計(jì)算階段。

　　文檔切分并行

　　計(jì)算的并發(fā)粒度是文件級(jí)別的，處理的文件格式也是多樣的，如TXT純文本，Markdown，PDF等，其對(duì)應(yīng)的切分邏輯也有差異。而使用Spark這種大數(shù)據(jù)框架來并行處理過重，并不合適。使用多核實(shí)例進(jìn)行多進(jìn)程并發(fā)處理則過于原始，任務(wù)的觀測(cè)追蹤上不太方便。所以可以選用AWS Glue的Python shell引擎進(jìn)行處理。主要有如下好處：

　　方便的按照文件粒度進(jìn)行并發(fā)，并發(fā)度簡(jiǎn)單可控。具有重試、超時(shí)等機(jī)制，方便任務(wù)的追蹤和觀察，日志直接對(duì)接到AWS CloudWatch

　　方便的構(gòu)建運(yùn)行依賴包，通過參數(shù)–additional-python-modules指定即可，同時(shí)Glue Python的運(yùn)行環(huán)境中已經(jīng)自帶了opensearch_py等依賴

　　向量化推理并行

　　由于切分的段落和句子相對(duì)于文檔數(shù)量也膨脹了很多倍，向量模型的推理吞吐能力決定了整個(gè)流程的吞吐能力。這里采用SageMaker Endpoint來部署向量化模型，一般來說為了提供模型的吞吐能力，可以采用GPU實(shí)例推理，以及多節(jié)點(diǎn)Endpoint/Endpoint彈性伸縮能力，Server-Side/Client-Side Batch推理能力這些都是一些有效措施。具體到離線向量知識(shí)庫構(gòu)建這個(gè)場(chǎng)景，可以采用如下幾種策略：

　　GPU實(shí)例部署：向量化模型CPU實(shí)例是可以推理的。但離線場(chǎng)景下，推理并發(fā)度高，GPU相對(duì)于CPU可以達(dá)到20倍左右的吞吐量提升。所以離線場(chǎng)景可以采用GPU推理，在線場(chǎng)景CPU推理的策略。

　　多節(jié)點(diǎn)Endpoint對(duì)于臨時(shí)的大并發(fā)向量生成，通過部署多節(jié)點(diǎn)Endpoint進(jìn)行處理，處理完畢后可以關(guān)閉

　　利用Client-Side Batch推理：離線推理時(shí)，Client-side batch構(gòu)造十分容易。無需開啟Server-side Batch推理，一般來說Sever-side batch都會(huì)有個(gè)等待時(shí)間，如50ms或100ms，對(duì)于推理延遲比較高的大語言模型比較有效，對(duì)于向量化推理則不太適用。

　　OpenSearch批量注入

　　Amazon OpenSearch的寫入操作，在實(shí)現(xiàn)上可以通過bulk批量進(jìn)行，比單條寫入有很大優(yōu)勢(shì)。

　　向量數(shù)據(jù)庫優(yōu)化

　　向量數(shù)據(jù)庫選擇哪種近似搜索算法，選擇合適的集群規(guī)模以及集群設(shè)置調(diào)優(yōu)對(duì)于知識(shí)庫的讀寫性能也十分關(guān)鍵，主要需要考慮以下幾個(gè)方面：

　　算法選擇

　　在OpenSearch里，提供了兩種k-NN的算法：HNSW (Hierarchical Navigable Small World)和IVF(Inverted File)。

　　在選擇k-NN搜索算法時(shí)，需要考慮多個(gè)因素。如果內(nèi)存不是限制因素，建議優(yōu)先考慮使用HNSW算法，因?yàn)镠NSW算法可以同時(shí)保證latency和recall。如果內(nèi)存使用量需要控制，可以考慮使用IVF算法，它可以在保持類似HNSW的查詢速度和質(zhì)量的同時(shí)，減少內(nèi)存使用量。但是，如果內(nèi)存是較大的限制因素，可以考慮為HNSW或IVF算法添加PQ編碼，以進(jìn)一步減少內(nèi)存使用量。需要注意的是，添加PQ編碼可能會(huì)降低準(zhǔn)確率。因此，在選擇算法和優(yōu)化方法時(shí)，需要綜合考慮多個(gè)因素，以滿足具體的應(yīng)用需求。

　　集群規(guī)模預(yù)估

　　選定了算法后，可以根據(jù)公式，計(jì)算所需的內(nèi)存進(jìn)而推導(dǎo)出k-NN集群大小

　　批量注入優(yōu)化

　　在向知識(shí)向量庫中注入大量數(shù)據(jù)時(shí)，需要關(guān)注一些關(guān)鍵的性能優(yōu)化，以下是一些主要的優(yōu)化策略：

　　Disable refresh interval

　　增加indexing線程

　　增加knn內(nèi)存占比

   投稿郵箱：chuanbeiol@163.com   詳情請(qǐng)?jiān)L問川北在線：http://m.fishbao.com.cn/