小米官宣：2023年上半年出貨量中國第一！
今日早間，小米電視官方微博帶來消息，稱2023年小米電視上半年出貨量達到了中國第一，同時還表示小米電視的巨屏風(fēng)暴即將開始。“公布一個好消息2023年#小米電視上半年出貨量中國
作者簡介
Terry，攜程自然語言處理和大語言模型算法方向?qū)＜遥卸嗄甑淖匀徽Z言處理項目經(jīng)驗和AI落地經(jīng)驗。
隨著OpenAI的ChatGPT火遍全球，大語言模型（Large Language Model，下文簡稱LLM）成為了人工智能領(lǐng)域的熱門話題。大語言模型是一種基于深度學(xué)習(xí)的自然語言處理技術(shù)，它能夠模擬人類的語言能力并生成連貫的文本。這種技術(shù)的出現(xiàn)引起了廣泛的關(guān)注和應(yīng)用。大型語言模型在機器翻譯、文本生成、智能對話等領(lǐng)域發(fā)揮著重要作用。在這些領(lǐng)域中，它們能夠理解和生成自然語言，使得機器能夠更好地與人類進行交流和合作。
無論是在學(xué)術(shù)研究還是商業(yè)領(lǐng)域中，LLM都有潛力成為一個強大的工具，幫助我們更好地理解和利用自然語言。但由于ChatGPT是閉源且信息安全存疑，并不適合在企業(yè)內(nèi)部的所有業(yè)務(wù)場景使用。此外，最近有大批優(yōu)秀的開源大語言模型涌現(xiàn)，比如Llama-2。因此，很多企業(yè)構(gòu)建屬于自己領(lǐng)域的LLM和配套系統(tǒng)，應(yīng)用在自身的業(yè)務(wù)場景中。為了適應(yīng)旅游場景的應(yīng)用，我們也構(gòu)建了一套訓(xùn)練、推理LLM的系統(tǒng)，充分利用LLM的強大能力。
LLM訓(xùn)練系統(tǒng)有預(yù)訓(xùn)練（Pretrain）、繼續(xù)預(yù)訓(xùn)練（Continue Pretrain）、微調(diào)（Finetune）幾個模式。
1）預(yù)訓(xùn)練階段使用的數(shù)據(jù)是大規(guī)模的通用數(shù)據(jù)，通常訓(xùn)練成本高達數(shù)百萬GPU-hour，成本很高。例如在Llama-2-70B的預(yù)訓(xùn)練中，使用的172萬GPU-hour，在Falcon-180B的預(yù)訓(xùn)練中，使用了超過700萬GPU-hour。
2）繼續(xù)預(yù)訓(xùn)練階段基于預(yù)訓(xùn)練過的基座模型（foundation model），使用特定領(lǐng)域的無標注數(shù)據(jù)訓(xùn)練，通常需要數(shù)千GPU-hour。可以用于學(xué)習(xí)領(lǐng)域內(nèi)知識，拓展語言、領(lǐng)域詞表。
3）微調(diào)階段基于基座模型，使用特定任務(wù)的數(shù)據(jù)訓(xùn)練，可以使模型對齊某些輸出范式，完成特定的任務(wù)，通常需要10到1000 GPU-hour，成本較低。代表模型有Alpaca等。
訓(xùn)練框架基于PyTorch + DeepSpeed、Transformers的技術(shù)路線，有Nvidia、Meta、Microsoft、HuggingFace等公司支持，并且有廣泛社區(qū)支持。PyTorch在更新至2.0后，加入compile模式，大幅提升訓(xùn)練速度；DeepSpeed中的ZeRO與offload技術(shù)幫助模型在多機多卡的訓(xùn)練中使用較小的顯存用量；這些技術(shù)簡化了百億到千億參數(shù)的模型的訓(xùn)練，并且在訓(xùn)練中保持穩(wěn)定。
通過Flash Attention、Apex、算子融合等提高硬件利用率的技術(shù)，目前我們可以以超過50%浮點利用率（MFU）的效率訓(xùn)練百億參數(shù)的模型。
根據(jù)可訓(xùn)練的參數(shù)量可以分為全參數(shù)訓(xùn)練、LoRA、QLoRA等技術(shù)。
全參數(shù)訓(xùn)練推薦在大量數(shù)據(jù)及預(yù)算充分的情況下使用，訓(xùn)練時模型的全部參數(shù)參與訓(xùn)練，可以精準的對齊目標范式；LoRA、QLoRA作為參數(shù)高效的訓(xùn)練方式，推薦在資源受限或需要快速獲取結(jié)果的情況下使用。
Llama原生詞表中1個中文字通常對應(yīng)2個token，導(dǎo)致中文內(nèi)容的token數(shù)量較長，不利于模型訓(xùn)練與推理的效率；并且Llama的預(yù)訓(xùn)練語料中中文占比較少，沒有針對中文語料優(yōu)化。
拓展詞表可以幫助解決這兩個問題。我們在Llama詞表的基礎(chǔ)上拓展了超過1萬的中文詞表，并使用大量中文語料繼續(xù)預(yù)訓(xùn)練，模型在中文數(shù)據(jù)上的困惑度（Perplexity）顯著降低。在訓(xùn)練與推理時，相同字數(shù)的中文數(shù)據(jù)的token減少一半，成本降低。
在GPU SRAM與HBM（High Bandwidth Memory）的IO速度相差十多倍，使用更少的內(nèi)存訪問量可以顯著提高計算速度。Flash Attention 的目標是避免從HBM中讀寫注意力矩陣。Flash Attention解決了兩個問題達到這個目標：
1）在不訪問整個輸入的情況下計算 softmax reduction。Flash Attention重組注意力計算，將輸入分成塊，并在輸入塊上進行多次傳遞，從而逐步執(zhí)行 softmax reduction。
2）在后向傳播中不能存儲中間注意力矩陣。存儲前向傳遞的 softmax 歸一化因子，在后向傳播中快速重新計算片上注意力，這比從 HBM 中讀取中間注意力矩陣的標準方法更快。
LLM的推理系統(tǒng)的關(guān)鍵的是延遲與成本。延遲關(guān)系到用戶的感受，最低標準是不能低于人類的打字速度，每秒1-3字，在給用戶整段文章或者代碼提示時需要更快的速度，理想情況時可以略高于人類看文字的速度，約每秒5-10字。然而高速通常意味著更高的硬件要求，更高的成本。
我們的推理部署系統(tǒng)有低延遲、高吞吐、高并發(fā)、高可用的特性。（以13B模型、1xA100部署為例）
1）低延遲：最快生成速度20ms/token；
2）批量生成吞吐量達到1600+ token/s；
3）可有效應(yīng)對并發(fā)數(shù)超過100；
4）高可用部署，僅需10分鐘即可部署兩地、多區(qū)域部署。
LLM在推理時是一個自回歸的過程，使用前n個token作為輸入預(yù)測第n+1個token。其中attention部分使用的K和V部分的前n token的向量在每次預(yù)測中時是不變的，可以將KV的值緩存下來，在預(yù)測下一個token的時候避免重復(fù)計算。
在應(yīng)用KV-cache進行LLM的自回歸解碼過程中，LLM 的所有輸入token都會生成其注意K和V張量，并且這些張量保存在x顯存中以生成下一個token。其中有兩個特點導(dǎo)致內(nèi)存大量浪費，大約浪費了60%-80%的顯存：
1）緩存占用大：在Llama-13B中單個序列最多占用1.7GB；
2）動態(tài)：緩存大小取決于序列長度，序列長度變化很大并且不可預(yù)測。
PagedAttention 允許在不連續(xù)的內(nèi)存空間中存儲連續(xù)的KV張量。PagedAttention 將每個序列的 KV 緩存劃分為塊，每個塊包含固定數(shù)量toke的KV。在注意力計算過程中，PagedAttention 內(nèi)核有效地識別并獲取這些塊。除此之外使用的內(nèi)存共享，Copy-on-write等機制大幅降低內(nèi)存使用量，并提升吞吐量。比HuggingFace默認方法提高最多24倍。
批量預(yù)測可以減少模型的加載次數(shù)，提高內(nèi)存帶寬利用率，提高計算資源的利用率，最終增加吞吐量、降低推理成本。
傳統(tǒng)的批量預(yù)測是靜態(tài)批處理，批處理的大小在推理完成前保持不變。然而在LLM的推理中每個請求逐個生成token，直到生成到最大長度或者停止token（EOS），在同一批次中每個請求的生成長度幾乎不可能相同。如果采用傳統(tǒng)的靜態(tài)批處理，需要不停生成直到最長的序列完成，GPU并不能完全充分利用。在極端情況，同一批次同時生成最大長度為100token與8000token的序列時，需要等待8000 token的序列完成，才能進行下一批次的預(yù)測，這樣GPU利用率會低于分別推理每一條請求，即批處理大小為1的情況。
為了充分利用GPU，增大吞吐量，可以使用連續(xù)批處理（Continuous Batching）。在模型輸出停止token后放入新的待生成序列，批次中的每一個空白token都可以被充分利用。
以部署在A100的13B模型為例，從第1個token生成至128token，在并發(fā)為1時可以實現(xiàn)2.6qps，在并發(fā)100時可以實現(xiàn)13qps，并且延遲得到有效控制，用戶感知的生成token速度在16-48 token/s，超過人類聊天時的打字速度，在客服聊天場景下體驗良好。在需要高吞吐量的場景下，最高可以超過1700 token/s。按照A100 20元/小時的成本估算，約0.003元/1000token，比使用GPT-3.5的使用成本低5-10倍。
如下圖所示，并發(fā)限制在100時可以達到用戶感知與吞吐量的最佳平衡，用戶無需忍受超長時間的等待，服務(wù)器可以以較低的成本提供服務(wù)。
智能客服機器人在攜程的服務(wù)環(huán)節(jié)起到非常重要的作用，60%以上的客人通過智能客服機器人等自助功能解決咨詢問題，例如下圖中的場景。
傳統(tǒng)的智能客服機器人，一般借助分類或者匹配模型，準確識別用戶的意圖，進而回答客人問題或者幫助客人解決問題。但傳統(tǒng)的分類或匹配模型經(jīng)常面臨召回率不高，缺少訓(xùn)練語料等問題，特別是針對較為長尾的用戶意圖。一般情況下，有了充足的高質(zhì)量訓(xùn)練語料，模型才能有好的效果，而為了收集高質(zhì)量語料，往往需要投入較多的人力。
大語言模型系統(tǒng)，解決了上述的問題。首先，LLM可以取代傳統(tǒng)小模型，完成識別用戶意圖的任務(wù)，并且在準確率和召回率上都有提升。此外，在我們LLM推理系統(tǒng)的加持下，LLM的推理速度可以達到傳統(tǒng)小模型的水平。線上數(shù)據(jù)表明，在識別意圖方面，LLM相比于傳統(tǒng)模型，準確率提升5%以上，召回率提升20%以上，而響應(yīng)速度保持不變。
其次，由于LLM使用成本較高，對于繼續(xù)使用小模型的場景，借助LLM的生成能力，可以輕松構(gòu)造出大量的高質(zhì)量語料，并且這些樣本類型多樣，與客人的真實問題相近。通過這種方式可以提高模型的泛化性能，還能節(jié)省人力投入。目前已經(jīng)落地的場景中，準備語料的人力投入平均從20人日減少到5人日以下。
在旅游的服務(wù)場景中，往往從客人或供應(yīng)商獲取的是大段的非結(jié)構(gòu)化文本信息，此時需要依賴人工進行信息抽取并填表，需要花費很高的人工成本。
而采用傳統(tǒng)算法進行抽取，實際使用中的準確率和召回率都不是很高。此外，當提取復(fù)雜關(guān)系的實體時，需要花費大量時間設(shè)計模型與規(guī)則，依然有很高的開發(fā)成本。
大語言模型系統(tǒng)，解決了上述的問題。使用LLM只需要簡單地構(gòu)造prompt，就能輕松識別復(fù)雜關(guān)系的實體，開發(fā)成本大大降低。
以下圖的火車票信息抽取場景為例，非結(jié)構(gòu)化文本內(nèi)包含多人、多時間、不同出發(fā)地、到達地、車廂、座位等實體，并且輸出也需要歸納為多行。經(jīng)過微調(diào)后的LLM，可以準確地將目標信息結(jié)構(gòu)化輸出為表格。針對火車票信息抽取場景，相比于采用傳統(tǒng)算法，LLM的抽取準確率可以從80%提升到95%以上，而開發(fā)人日從5人日左右減少到1人日以下。
在客服場景中，不同時間或不同場景，往往會由不同的客服人員服務(wù)客人。當客人的對話結(jié)束時，需要對客人的對話記錄進行歸納、總結(jié)，便于后續(xù)其他客服人員服務(wù)客人時，能快速了解之前的背景信息，否則需要花費時間去查看歷史對話記錄。
如果依賴人工總結(jié)，會花費大量的人工成本。而采用傳統(tǒng)的算法小模型，很容易造成信息丟失，準確率不高等問題。
大語言模型系統(tǒng)，解決了上述的問題。借助LLM強大的生成能力，我們可以通過調(diào)整prompt，讓模型對會話內(nèi)容進行歸納，并按我們需要的方式輸出，例如將客人問題發(fā)生的時間、地點、任務(wù)等信息，串聯(lián)成一段通順且便于理解的話，也可以將客人的問題總結(jié)成標簽。
線上數(shù)據(jù)表明，采用LLM，準確率相比小模型提升5%以上，節(jié)省客服人員平均每段對話的查看時間2分鐘以上。
除了大語言模型以外，其他的大模型也在高速發(fā)展中，多模態(tài)大模型未來會成為主流。可以預(yù)見到，大模型在旅游領(lǐng)域的未來是非常廣闊的，隨著科技的不斷發(fā)展，大模型將在旅游行業(yè)中發(fā)揮重要作用。例如：
隨著使用量的提高，對模型的反饋也可以幫助模型進行大規(guī)模的人類反饋的強化學(xué)習(xí)（RLHF），進一步提升大模型的性能，實現(xiàn)更優(yōu)秀的表現(xiàn)。
本文鏈接：http://www.www897cc.com/showinfo-26-40686-0.html攜程旅游大語言模型系統(tǒng)介紹及其應(yīng)用
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號