PixverseAI互動功能（HUG）在AI擁抱視頻生成中的應(yīng)用
微信截圖_17401194941360-1024x571.png)
比如用戶可能會問“我想看兩個男人在天臺決斗的電影”，此類問題在傳統(tǒng)NLP技術(shù)下是難以做到識別用戶是想看《無間道》的意圖的，而大模型強大的泛化推理能力可以很好的解決。
因此在整個鏈路中，首先重點要解決的就是意圖識別問題，我們在意圖識別領(lǐng)域使用大模型對傳統(tǒng)NLP能力進行了全面升級，本文的重點也是介紹大模型意圖識別能力在智能電視AI OS的核心鏈路中落地過程和思考。
意圖識別概念介紹
意圖識別（Intent Classification），是一種自然語言處理技術(shù)，用于分析用戶的輸入并將其映射到某個預(yù)定義的意圖類別。這種技術(shù)在問答機器人、智能客服、虛擬助手等領(lǐng)域被廣泛使用。其目的是通過分析用戶的文本或語音輸入，識別用戶的詢問、請求或指示真正的目的，從而提供個性化、準(zhǔn)確的服務(wù)。
例如，在智能客服場景中，用戶輸入的語句可能比較模糊、復(fù)雜，包含著咨詢、抱怨、建議等多種潛在意圖，大模型通過意圖識別能力，剖析語句的語言模式、關(guān)鍵詞以及語義關(guān)聯(lián)等，準(zhǔn)確判斷出用戶究竟是想要咨詢產(chǎn)品功能，還是對服務(wù)質(zhì)量有所不滿，從而針對性地給出恰當(dāng)回復(fù)，有效提升客戶服務(wù)體驗。
在大模型的應(yīng)用體系里，意圖識別處于十分關(guān)鍵的位置，它就像是一座橋梁，連接著用戶模糊或明確的表達與大模型后續(xù)具體的任務(wù)執(zhí)行，只有精準(zhǔn)完成這一步驟，才能保證后續(xù)一系列動作的準(zhǔn)確性和有效性，讓大模型真正成為幫助用戶解決問題、滿足需求的有力工具。
例如下面是一個企業(yè)內(nèi)部對話機器人的例子：
在意圖層面有以下幾個概念：
意圖改寫：指在不改變用戶原始意圖的前提下，對用戶表達意圖的文本內(nèi)容進行重新表述。例如，原始文本為 “明天的天氣”，改寫后的文本可以是 “幫我查一下明天的天氣狀況”。通過意圖改寫可以有效提高大模型輸出的準(zhǔn)確率。
意圖分類：通過給不同的意圖分配特定標(biāo)簽，便于大模型進行快速分類和處理。比如將意圖分為 “查詢類”“預(yù)訂類”“咨詢類” 等大的類別標(biāo)簽，在 “查詢類” 下又可以細分出 “查詢天氣”“查詢航班” 等具體標(biāo)簽。當(dāng)用戶輸入內(nèi)容后，大模型依據(jù)這些預(yù)設(shè)的標(biāo)簽體系，能夠迅速判斷出所屬類別，從而采取相應(yīng)的處理邏輯。
意圖槽位：意圖槽位在大模型意圖識別中起著關(guān)鍵作用，它就像是一個個精準(zhǔn)捕捉用戶需求的 “小格子”。例如在用戶預(yù)訂機票的場景中，像出發(fā)地、目的地、出發(fā)時間、航班艙位等級等這些關(guān)鍵要素都可以看作是不同的意圖槽位。大模型通過分析用戶輸入的語句，嘗試將對應(yīng)的信息填充到相應(yīng)的槽位里，以此來更好地理解用戶究竟想要做什么。
意圖置信度：是指模型在預(yù)測用戶意圖時的自信程度。通常用一個概率值來表示，概率越高，表示模型對預(yù)測的意圖越有信心。例如，模型預(yù)測用戶意圖是 “產(chǎn)品咨詢”，置信度為 0.9，這就表明模型比較確定用戶的意圖是產(chǎn)品咨詢；如果置信度為 0.4，說明模型對這個預(yù)測不是很有把握。
意圖識別在智能電視中的落地挑戰(zhàn)
由于該場景處于電視C端業(yè)務(wù)的核心交互鏈路上，因此對意圖識別模塊也提出了更高的要求。該場景的落地挑戰(zhàn)主要來自于以下幾個方面：
1.延遲要求：由于全鏈路較長，用戶對延遲容忍度低，因此對意圖識別模型的延遲要求也非?？量蹋ǔＰ枰?strong>500ms-800ms左右必須返回全包，以供后續(xù)鏈路繼續(xù)處理業(yè)務(wù)。
2.準(zhǔn)確性要求：C端用戶對整體體驗效果敏感，不準(zhǔn)確的意圖會導(dǎo)致全鏈路功能失效，無法達到用戶預(yù)期。因此對意圖識別模型的準(zhǔn)確性要求非常高，需要保證簡單指令100%準(zhǔn)確率，復(fù)雜指令98%+準(zhǔn)確率。
3.實時數(shù)據(jù)處理能力：由于電視場景的特性，業(yè)務(wù)上需要涉及到最新的媒資信息或互聯(lián)網(wǎng)上較新的梗，例如“老默吃魚”，單純靠基模能力無法有效理解。因此需要將一些較新的知識內(nèi)容注入給模型。
方案一：基模 + Prompt
開發(fā)成本低，適用于需要快速上線，對延時要求不高，分類相對簡單的場景。
該方案主要靠基模的推理能力，需要根據(jù)分類難度和延時要求選擇不同模型。建議至少使用32b以上的模型，如qwen-plus、qwen-max。
Prompt的實現(xiàn)也有較多寫法，這里是一些常用的實現(xiàn)技巧：
CoT的核心在于引導(dǎo)模型逐步構(gòu)建一個邏輯鏈，這個鏈由一系列相關(guān)的推理步驟組成，每個步驟都是基于前一步的結(jié)果。這種方法有助于模型更好地理解問題的上下文和復(fù)雜性，并且增強了模型輸出的解釋性和可信度。
# 思考步驟為了完成上述目標(biāo)，請按照下面的過程，一步一步思考后完成: 1.首先需要先理解候選的意圖信息共有如下{}個類別，每個意圖的含義或常見描述如下：{}
大模型具備強大的少樣本學(xué)習(xí)能力，通過在prompt中引入few shot少樣本可有效提高大模型在意圖識別分類任務(wù)中的能力。例如：
2. 然后，觀察以下意圖識別分類案例，學(xué)習(xí)意圖識別分類任務(wù)的能力：{}
3. 意圖識別前，請重點學(xué)習(xí)并記住以下識別準(zhǔn)則：{}
（4）輸出示例
4. 請以JSON格式進行輸出，輸出示例：{}
基于以上原因，我們放棄了基模 + 提示詞的方案，該場景更適合業(yè)務(wù)相對簡單，延遲要求不敏感的業(yè)務(wù)場景。
方案二：基模 + Prompt + RAG
檢索增強生成（Retrieval-Augmented Generation，RAG）指的是在LLM回答問題之前從外部知識庫中檢索相關(guān)信息，RAG有效地將LLM的參數(shù)化知識與非參數(shù)化的外部知識庫結(jié)合起來，使其成為實現(xiàn)大型語言模型的最重要方法之一
鑒于方案一中垂類領(lǐng)域知識的問題，考慮加入RAG能力解決。通過在知識庫中上傳大量的意圖分類知識，使得該方案可以理解較為垂類或更個性化要求的分類判定邏輯。
該方案引入了RAG能力，對模型推理要求不是很高，建議選用性能相對性價比較高的模型，如qwen-turbo、qwen-plus。
以下是一些建議的步驟：
首先我們需要定義不同意圖的分類以及其槽位的設(shè)計，這些設(shè)計會和實際的業(yè)務(wù)場景以及后續(xù)承載具體實現(xiàn)的Agent密切相關(guān)，例如：
（2）數(shù)據(jù)生成
這里可以考慮給一些生產(chǎn)上用戶可能問的query示例，用LLM生成一批同義句，此處不再贅述
根據(jù)前面設(shè)計的意圖語料結(jié)構(gòu)，使用大尺寸模型生成相關(guān)意圖分類和槽位，并可加入在線搜索相關(guān)能力，代碼示例和Prompt如下：
prompt = """# 角色你是一位意圖樣本生成專家，擅長根據(jù)給定的模板生成意圖及對應(yīng)的槽位信息。你能夠準(zhǔn)確地解析用戶輸入，并將其轉(zhuǎn)化為結(jié)構(gòu)化的意圖和槽位數(shù)據(jù)。
## 技能### 技能1：解析用戶指令- **任務(wù)**：根據(jù)用戶提供的自然語言指令，識別出用戶的意圖。
### 技能2：生成結(jié)構(gòu)化意圖和槽位信息- 意圖分類：video_search,music_search,information_search- 槽位分類：-- information_search: classification,video_category,video_name,video_season-- music_search: music_search,music_singer,music_tag,music_release_time-- video_search: video_actor,video_name,video_episode- **任務(wù)**：將解析出的用戶意圖轉(zhuǎn)換為結(jié)構(gòu)化的JSON格式。 - 確保每個意圖都有相應(yīng)的槽位信息，不要自行編造槽位。 - 槽位信息應(yīng)包括所有必要的細節(jié)，如演員、劇名、集數(shù)、歌手、音樂標(biāo)簽、發(fā)布時間等。
### 技能3：在線搜索- 如果遇到關(guān)于電影情節(jié)的描述，可以調(diào)用搜索引擎獲取到電影名、演員等信息稱補充到actor,name等槽位中
### 輸出示例 - 以JSON格式輸出，例如： -"這周杭州的天氣如何明天北京有雨嗎"：{'infor_search':{'extra_info':['這周杭州的天氣如何明天北京有雨嗎']}} -"我一直在追趙麗穎的楚喬傳我看到第二十集了它已經(jīng)更新了嗎我可以看下一集嗎"：{'video_search':{'video_actor':['趙麗穎'],'video_name':['楚喬傳'],'video_episode':['第21集'],'extra_info':['我一直在追趙麗穎的楚喬傳我看到第二十集了它已經(jīng)更新了嗎我可以看下一集嗎']}}
## 限制- 只處理與意圖生成相關(guān)的任務(wù)。- 生成的意圖和槽位信息必須準(zhǔn)確且完整。- 在解析過程中，確保理解用戶的意圖并正確映射到相應(yīng)的服務(wù)類型- 如果遇到未知的服務(wù)類型或槽位信息，可以通過調(diào)用搜索工具進行補充和確認。- 直接輸出Json，不要輸出其他思考過程生成后的用于知識庫的數(shù)據(jù)集格式如下：
[{“instruction”:”播放一首七仔的歌曲我想聽他的經(jīng)典老歌最好是70年代的音樂風(fēng)格”,”output”:”{‘music_search’:{‘singer’:[‘張學(xué)友’],’music_tag’:[‘經(jīng)典老歌’],’release_time’:[’70年代’]}}”}]
這里有非常多成熟的方案可以選擇，可以考慮阿里云百煉平臺的RAG方案，此處不再贅述。
因此，該方案也不太適用于電視C端交互鏈路上，但是方案二關(guān)于數(shù)據(jù)增強的思路還是值得借鑒的，基于這個思路，我們可以嘗試用小尺寸模型SFT的方案
方案三：使用小尺寸模型進行SFT
通過小尺寸模型解決延遲問題，通過微調(diào)解決數(shù)據(jù)增強問題
一般而言，模型底座越大，下游任務(wù)效果越好，但是部署成本和推理代價相應(yīng)增大。針對意圖識別的場景，建議從4B左右的大模型底座開始進行SFT和調(diào)參，當(dāng)效果較大同時通過調(diào)參無法進一步提升時，建議換成7B的更大底座。超過10B的底座理論上能得到更好的結(jié)果，但是需要權(quán)衡實際的效果和成本問題，因此本場景使用7B的底座性價比較高。
選用LoRA方式進行微調(diào)
LoRA 原理（來源 LoRA 論文：LORA: LOW-RANK ADAPTATION OF LARGE LANGUAGE MODELS）
LoRa算法在固定主預(yù)訓(xùn)練參數(shù)的情況下，用支路去學(xué)習(xí)特定任務(wù)知識，來完成特定任務(wù)。它的假設(shè)為模型適應(yīng)時的權(quán)重改變總是“低秩”的。訓(xùn)練方法為在每層transfomer block旁邊引入一個并行低秩的支路，支路的輸入是transfomer block的輸入，然后將輸出和transfomer block的輸出相加。訓(xùn)練完后將原始權(quán)重加上LoRA訓(xùn)練的權(quán)重（
），最終使得模型結(jié)構(gòu)不變。
SFT的大致流程如下：
參考方案二中的意圖預(yù)料設(shè)計，此處不再贅述
樣本生成有很多方式，比如前面提到的LLM生成或是引入一些數(shù)據(jù)預(yù)處理工具。筆者這里使用的是PAI-iTag工具。首先，將用于iTag標(biāo)注的數(shù)據(jù)注冊到PAI數(shù)據(jù)集，該數(shù)據(jù)集為manifest格式文件，內(nèi)容示例如下：
{“data”:{“instruction”: “我想聽音樂”}}{“data”:{“instruction”: “太吵了，把聲音開小一點”}}{“data”:{“instruction”: “我不想聽了，把歌關(guān)了吧”}}{“data”:{“instruction”: “我想去杭州玩，幫我查下天氣預(yù)報”}}
標(biāo)注完成后可以將標(biāo)注結(jié)果導(dǎo)出至OSS，在本示例中，輸出文件內(nèi)容如下：
{“data”:{“instruction”:”我想聽音樂”,”_itag_index”:””},”label-1787402095227383808″:{“results”:[{“questionId”:”2″,”data”:”play_music()”,”markTitle”:”output”,”type”:”survey/value”}]},”abandonFlag”:0,”abandonRemark”:null}{“data”:{“instruction”:”太吵了，把聲音開小一點”,”_itag_index”:””},”label-1787402095227383808″:{“results”:[{“questionId”:”2″,”data”:”volume_down()”,”markTitle”:”output”,”type”:”survey/value”}]},”abandonFlag”:0,”abandonRemark”:null}{“data”:{“instruction”:”我不想聽了，把歌關(guān)了吧”,”_itag_index”:””},”label-1787402095227383808″:{“results”:[{“questionId”:”2″,”data”:”music_exit()”,”markTitle”:”output”,”type”:”survey/value”}]},”abandonFlag”:0,”abandonRemark”:null}{“data”:{“instruction”:”我想去杭州玩，幫我查下天氣預(yù)報”,”_itag_index”:””},”label-1787402095227383808″:{“results”:[{“questionId”:”2″,”data”:”weather_search(杭州)”,”markTitle”:”output”,”type”:”survey/value”}]},”abandonFlag”:0,”abandonRemark”:null}
標(biāo)注完成的數(shù)據(jù)格式說明參考標(biāo)注數(shù)據(jù)格式概述。為了在PAI-ModelGallery
種使用標(biāo)注數(shù)據(jù)進行模型訓(xùn)練，需要將上述文件轉(zhuǎn)化為PAI-ModelGallery
接受的訓(xùn)練數(shù)據(jù)格式，可以參考如下Python腳本：
# 輸入文件路徑和輸出文件路徑input_file_path = 'test_json.manifest'output_file_path = 'train.json'
converted_data = []with open(input_file_path, 'r', encoding='utf-8') as file: for line in file: data = json.loads(line) instruction = data['data']['instruction'] for key in data.keys(): if key.startswith('label-'): output = data[key]['results'][0]['data'] converted_data.append({'instruction': instruction, 'output': output}) break
with open(output_file_path, 'w', encoding='utf-8') as outfile: json.dump(converted_data, outfile, ensure_ascii=False, indent=4)全參數(shù)微調(diào)消耗計算資源最多，而且容易使大模型產(chǎn)生災(zāi)難性遺忘，LoRA和QLoRA有效地避免了這個問題。另一方面，QLoRA由于參數(shù)精度低，容易對下游任務(wù)的效果產(chǎn)生不利影響。綜合考慮，使用LoRA算法進行微調(diào)。
全局批次大小=卡數(shù)*per_device_train_batch_size*gradient_accumulation_steps
這里在GPU顯存允許的情況下盡可能調(diào)大batch size，可以使得模型更快收斂到最優(yōu)解，同時具有較高的泛化能力。
序列長度對顯存消耗和訓(xùn)練效果有較大的影響，過小的序列長度雖然節(jié)省了顯存，但是導(dǎo)致某些比較長的訓(xùn)練數(shù)據(jù)集被切斷，造成不利影響；過大的序列長度又會造成顯存的浪費。從意圖識別的場景來看，根據(jù)實際數(shù)據(jù)的長度，選擇64/128/256的長度比較合適。
如果訓(xùn)練數(shù)據(jù)質(zhì)量比較差，訓(xùn)練效果一般會受影響，所以在數(shù)據(jù)標(biāo)注的時候需要進行充分的質(zhì)量校驗。同時，由于LoRA訓(xùn)練一般參數(shù)調(diào)整空間不大，學(xué)習(xí)率默認可以進行偏大設(shè)置，例如1e-4左右，當(dāng)訓(xùn)練loss下降過慢或者不收斂時，建議適當(dāng)調(diào)大學(xué)習(xí)率，例如3e-4或者5e-4。不建議使用1e-3這個量級的學(xué)習(xí)率，容易得不到優(yōu)化的結(jié)果。
一般而言，模型底座越大，下游任務(wù)效果越好，但是部署成本和推理代價相應(yīng)增大。針對意圖識別的場景，建議從4B左右的大模型底座開始進行SFT和調(diào)參，當(dāng)效果較大同時通過調(diào)參無法進一步提升時，建議換成7B的更大底座。超過10B的底座理論上能得到更好的結(jié)果，但是需要權(quán)衡實際的效果和成本問題，因此，因此本場景使用7B的底座性價比較高。
（4）啟動訓(xùn)練任務(wù)
微信截圖_17401196335802-1024x448.png)
值得注意的是，如果需要在訓(xùn)練過程中改變默認的system_prompt，讓大模型扮演某種特定的角色，可以在Qwen1.5系列模型的訓(xùn)練中配置自定義的
system_prompt，例如“你是一個意圖識別專家，可以根據(jù)用戶的問題識別出意圖，并返回對應(yīng)的意圖和參數(shù)”。在這種情況下，給定一個訓(xùn)練樣本：
[ { “instruction”:”我想聽音樂”, “output”:”play_music()” }]
實際用于訓(xùn)練的數(shù)據(jù)格式如下：
<|im_start|>system\n你是一個意圖識別專家，可以根據(jù)用戶的問題識別出意圖，并返回對應(yīng)的意圖和參數(shù)<|im_end|>\n<|im_start|>user\n我想聽音樂<|im_end|>\n<|im_start|>assistant\nplay_music()<|im_end|>\n
當(dāng)設(shè)置apply_chat_template為true并且添加system_prompt，算法會自行對訓(xùn)練數(shù)據(jù)進行擴展，無需關(guān)注執(zhí)行細節(jié)。
當(dāng)模型訓(xùn)練結(jié)束后，可以使用如下Python腳本進行模型效果的評測。假設(shè)評測數(shù)據(jù)如下：
[ { “instruction”:”想知道的十年是誰唱的？”, “output”:”music_query_player(十年)” }, { “instruction”:”今天北京的天氣怎么樣？”, “output”:”weather_search(杭州)” }]
評測腳本如下所示：
#encoding=utf-8from transformers import AutoModelForCausalLM, AutoTokenizerimport jsonfrom tqdm import tqdm
device = "cuda" # the device to load the model onto
# 修改模型路徑model_name = '/mnt/workspace/model/qwen14b-lora-3e4-256-train/'print(model_name)model = AutoModelForCausalLM.from_pretrained( model_name, torch_dtype="auto", device_map="auto")tokenizer = AutoTokenizer.from_pretrained(model_name)
count = 0ecount = 0
# 修改訓(xùn)練數(shù)據(jù)路徑test_data = json.load(open('/mnt/workspace/data/testdata.json'))system_prompt = '你是一個意圖識別專家，可以根據(jù)用戶的問題識別出意圖，并返回對應(yīng)的函數(shù)調(diào)用和參數(shù)。'
for i in tqdm(test_data[:]): prompt = '<|im_start|>system\n' + system_prompt + '<|im_end|>\n<|im_start|>user\n' + i['instruction'] + '<|im_end|>\n<|im_start|>assistant\n' gold = i['output'] gold = gold.split(';')[0] if ';' in gold else gold
model_inputs = tokenizer([prompt], return_tensors="pt").to(device) generated_ids = model.generate( model_inputs.input_ids, max_new_tokens=64, pad_token_id=tokenizer.eos_token_id, eos_token_id=tokenizer.eos_token_id, do_sample=False ) generated_ids = [ output_ids[len(input_ids):] for input_ids, output_ids in zip(model_inputs.input_ids, generated_ids) ] pred = tokenizer.batch_decode(generated_ids, skip_special_tokens=True)[0] if gold.split('(')[0] == pred.split('(')[0]: count += 1 gold_list = set(gold.strip()[:-1].split('(')[1].split(',')) pred_list = set(pred.strip()[:-1].split('(')[1].split(',')) if gold_list == pred_list: ecount += 1 else: pass
print("意圖識別準(zhǔn)確率：", count/len(test_data))print("參數(shù)識別準(zhǔn)確率：", ecount/len(test_data))部署的推理服務(wù)支持使用ChatLLM WebUI進行實時交互，也可以使用API進行模型推理，具體使用方法參考5分鐘使用EAS一鍵部署LLM大語言模型應(yīng)用：
https://help.aliyun.com/zh/pai/use-cases/deploy-llm-in-eas
以下給出一個示例request客戶端調(diào)用：
import argparseimport jsonfrom typing import Iterable, List
import requests
def post_http_request(prompt: str, system_prompt: str, history: list, host: str, authorization: str, max_new_tokens: int = 2048, temperature: float = 0.95, top_k: int = 1, top_p: float = 0.8, langchain: bool = False, use_stream_chat: bool = False) -> requests.Response: headers = { "User-Agent": "Test Client", "Authorization": f"{authorization}" } pload = { "prompt": prompt, "system_prompt": system_prompt, "top_k": top_k, "top_p": top_p, "temperature": temperature, "max_new_tokens": max_new_tokens, "use_stream_chat": use_stream_chat, "history": history } response = requests.post(host, headers=headers, json=pload, stream=use_stream_chat) return response
def get_response(response: requests.Response) -> List[str]: data = json.loads(response.content) output = data["response"] history = data["history"] return output, history
if __name__ == "__main__": parser = argparse.ArgumentParser() parser.add_argument("--top-k", type=int, default=4) parser.add_argument("--top-p", type=float, default=0.8) parser.add_argument("--max-new-tokens", type=int, default=2048) parser.add_argument("--temperature", type=float, default=0.95) parser.add_argument("--prompt", type=str, default="How can I get there?") parser.add_argument("--langchain", action="store_true")
args = parser.parse_args()
prompt = args.prompt top_k = args.top_k top_p = args.top_p use_stream_chat = False temperature = args.temperature langchain = args.langchain max_new_tokens = args.max_new_tokens
host = "EAS服務(wù)公網(wǎng)地址" authorization = "EAS服務(wù)公網(wǎng)Token"
print(f"Prompt: {prompt!r}\n", flush=True) # 在客戶端請求中可設(shè)置語言模型的system prompt。 system_prompt = "你是一個意圖識別專家，可以根據(jù)用戶的問題識別出意圖，并返回對應(yīng)的意圖和參數(shù)"
# 客戶端請求中可設(shè)置對話的歷史信息，客戶端維護當(dāng)前用戶的對話記錄，用于實現(xiàn)多輪對話。通常情況下可以使用上一輪對話返回的histroy信息，history格式為List[Tuple(str, str)]。 history = [] response = post_http_request( prompt, system_prompt, history, host, authorization, max_new_tokens, temperature, top_k, top_p, langchain=langchain, use_stream_chat=use_stream_chat) output, history = get_response(response) print(f" --- output: {output} \n --- history: {history}", flush=True)
# 服務(wù)端返回JSON格式的響應(yīng)結(jié)果，包含推理結(jié)果與對話歷史。def get_response(response: requests.Response) -> List[str]: data = json.loads(response.content) output = data["response"] history = data["history"] return output, history在智能電視意圖識別場景中，為了保證用戶的交互體驗，通常要求更高的延時，因此建議使用PAI提供的BladeLLM推理引擎進行LLM服務(wù)的部署。
因為主要靠微調(diào)提升效果，Promp的寫法相對簡單，不再預(yù)置業(yè)務(wù)規(guī)則和思維鏈：
{"role": "system", "content": "你是個意圖識別專家，你要通過用戶的輸入，識別用戶的意圖以及槽位信息，注意：不要添加沒有的意圖和槽位。"}幾種方案的對比：
在實際的生成鏈路上，我們發(fā)現(xiàn)要保證準(zhǔn)確率、時效性、以及成本之間，還有一些工作要做，主要包含以下幾個靈魂拷問：
1.如何保證生產(chǎn)準(zhǔn)確率持續(xù)符合要求？
互聯(lián)網(wǎng)上的信息更新迭代很快，尤其是在娛樂性質(zhì)較重的媒資類產(chǎn)品上，幾乎每天都會產(chǎn)生新的電視/電影/音樂等信息；一些互聯(lián)網(wǎng)上的梗也持續(xù)出現(xiàn)，比如“老默吃魚”，“蔣欣在這里”等等，用戶個性化的問法也是層出不窮，如何能持續(xù)保證生產(chǎn)的準(zhǔn)確率符合98%以上的預(yù)期是一個難題。
2.如何在生產(chǎn)環(huán)境上對結(jié)果糾錯？
電視場景的交互是以語音為主，不太涉及觸屏等精細化交互操作。如果客戶對某個答案不滿意，并不會像PC或手機上的智能機器人那樣有一個“點踩”的反饋渠道。出現(xiàn)大量事實性錯誤時，只能通過用戶投訴得到反饋，這會極大有損用戶體驗。所以如何拿到生產(chǎn)的意圖結(jié)論對錯成為一個待解決的問題。
3.海量C端用戶的指令無法窮舉，大量的訓(xùn)練集如何產(chǎn)生？
我們通過微調(diào)解決垂直業(yè)務(wù)數(shù)據(jù)問題，前期我們準(zhǔn)備的訓(xùn)練數(shù)據(jù)只能解決一小部分問題，實際生產(chǎn)上微調(diào)模型是需要不停的迭代的，那么微調(diào)的數(shù)據(jù)要從要哪里來也是一個很重要的問題。
4.訓(xùn)練集不停變大，反復(fù)SFT耗時耗力，有沒有自動化的方案？
當(dāng)我們拿到了訓(xùn)練集后，需要人工在平臺上進行模型訓(xùn)練和部署，如果這個操作頻率精細化到每天都要處理，那么無疑對人力成本的消耗是巨大的。所以有沒有一個全自動化的方案能幫我們解決這些問題？
通過設(shè)計完整的離線質(zhì)檢工程鏈路，持續(xù)自動訓(xùn)練和部署最新模型，解決生產(chǎn)準(zhǔn)確率、訓(xùn)練集和微調(diào)模型成本的問題。
該方案通過多步驟處理流程，實現(xiàn)了自動對線上意圖質(zhì)檢及自動重新訓(xùn)練的流程?？傮w上分為在線流程和離線流程兩部分，以下是詳細的流程描述：
在線流程：
1.用戶的query先經(jīng)過一道意圖緩存庫，該庫直接以query為key，將曾經(jīng)正確返回的意圖結(jié)果存儲在es中。當(dāng)緩存被命中時直接將結(jié)果返回，不再走后續(xù)鏈路，以此提高響應(yīng)速度和保證準(zhǔn)確性。該緩存庫主要是為一些簡單意圖如系統(tǒng)指令、媒資名搜索做快速結(jié)果返回
2.如果未命中緩存，則走到后續(xù)的模型推理鏈路。當(dāng)前使用的是微調(diào)后的qwen-7b模型
離線流程：
1.當(dāng)大模型輸出意圖推理結(jié)果后，會異步將query+reponse傳入給一個意圖優(yōu)化應(yīng)用，作為整體質(zhì)檢的入口
2.調(diào)用一個大尺寸模型，例如qwen-max對結(jié)果進行質(zhì)檢。質(zhì)檢規(guī)則是輸出response相對于result的得分情況，滿分為1分，只有0.9分以上的答案才認為是正確的
3.如果意圖準(zhǔn)確，則重新將此次的意圖結(jié)果寫進緩存中，方便下次調(diào)用讀取
4.如果意圖得分低于0.9，認為該意圖生成質(zhì)量不佳，此時會嘗試使用大尺寸模型如qwen-max進行意圖的重新生成。需要注意的是，此質(zhì)檢agent會引入LLM實時搜索能力，保證對一些較新的query信息做好理解
5.當(dāng)意圖生成agent的答案重新通過質(zhì)檢后，會更新到訓(xùn)練集中，以供下一次SFT使用
在某國產(chǎn)頭部電視廠家落地過程中，最終經(jīng)過多輪技術(shù)選型，我們決策使用PAI平臺進行qwen-7b模型的訓(xùn)練和推理部署，該方案準(zhǔn)確率和延遲上都有較大優(yōu)勢，平均延遲500ms，生產(chǎn)實時準(zhǔn)確率達到98%+。
隨著電視技術(shù)的迅猛發(fā)展和用戶交互模式的日益多樣化，意圖識別技術(shù)在增強用戶體驗中發(fā)揮著不可或缺的作用。本文聚焦于電視環(huán)境中大模型意圖識別的核心技術(shù)、所面臨的挑戰(zhàn)以及當(dāng)前的解決方案。
AI大模型技術(shù)還在不斷高速迭代更新，作為阿里云大模型技術(shù)服務(wù)團隊將陪伴客戶共同成長，一起見證更加智能且人性化的電視互動體驗的誕生。通過持續(xù)優(yōu)化和升級現(xiàn)有的大模型結(jié)構(gòu)，并融入多維度的數(shù)據(jù)源——例如語音情感分析與視覺內(nèi)容感知等先進技術(shù)，未來的電視設(shè)備將不僅能夠準(zhǔn)確理解用戶的指令，還能夠預(yù)判其需求，提供超越預(yù)期的個性化服務(wù)。
這種進步將重新定義觀眾與電視之間的互動方式，開啟智能家居娛樂的新紀(jì)元。
