在大型語(yǔ)言模型的實(shí)際部署中推理成本與響應(yīng)速度是兩大核心瓶頸而這兩者都與模型處理輸入的令牌數(shù)量直接相關(guān)。一個(gè)常見(jiàn)的優(yōu)化思路是能否在不犧牲模型理解能力的前提下減少輸入提示中的令牌消耗這不僅是成本問(wèn)題也關(guān)乎性能。本文將以一個(gè)具體的工程實(shí)踐為例探討如何通過(guò)重構(gòu)提示詞的結(jié)構(gòu)與內(nèi)容實(shí)現(xiàn)用更少的令牌完成與“ACE”相關(guān)的復(fù)雜任務(wù)并確保輸出質(zhì)量不受影響。我們將從概念分析入手逐步拆解優(yōu)化策略提供可操作的代碼示例和驗(yàn)證方法并最終給出在生產(chǎn)環(huán)境中落地此類(lèi)優(yōu)化的檢查清單。1. 理解令牌經(jīng)濟(jì)性為什么“少即是多”在深入技術(shù)細(xì)節(jié)前必須明確一個(gè)核心概念對(duì)于大多數(shù)按令牌計(jì)費(fèi)的云服務(wù)或自托管模型輸入和輸出的令牌總數(shù)直接決定了單次推理的成本。同時(shí)更長(zhǎng)的輸入序列也會(huì)增加模型的計(jì)算負(fù)擔(dān)可能導(dǎo)致更長(zhǎng)的延遲。1.1 令牌與成本、延遲的關(guān)系令牌是大型語(yǔ)言模型處理文本的基本單位。一個(gè)令牌可能是一個(gè)單詞、一個(gè)子詞甚至一個(gè)標(biāo)點(diǎn)符號(hào)。模型在處理輸入時(shí)需要為每個(gè)令牌分配計(jì)算資源以生成其對(duì)應(yīng)的上下文表示。因此輸入令牌數(shù)n_input_tokens直接影響計(jì)算成本更多的輸入令牌意味著更多的矩陣運(yùn)算。內(nèi)存占用需要存儲(chǔ)更長(zhǎng)的鍵值緩存。推理延遲序列越長(zhǎng)模型生成第一個(gè)輸出令牌所需的時(shí)間可能越長(zhǎng)對(duì)于自回歸模型。在按量付費(fèi)的場(chǎng)景下成本公式通常為Cost (n_input_tokens n_output_tokens) * price_per_token。優(yōu)化輸入令牌數(shù)就是從源頭降低成本。1.2 “ACE”任務(wù)的典型提示結(jié)構(gòu)及其問(wèn)題假設(shè)我們有一個(gè)任務(wù)需要模型基于用戶(hù)提供的“Action”行動(dòng)、“Context”上下文和“Expected Result”預(yù)期結(jié)果——即“ACE”框架——來(lái)生成一份詳細(xì)的技術(shù)方案。一個(gè)未經(jīng)優(yōu)化的提示可能如下你是一個(gè)資深的軟件架構(gòu)師。請(qǐng)根據(jù)用戶(hù)提供的以下三個(gè)要素撰寫(xiě)一份詳細(xì)的技術(shù)實(shí)施方案文檔。 要素說(shuō)明 1. Action行動(dòng) 用戶(hù)希望系統(tǒng)執(zhí)行的核心操作或功能。 2. Context上下文 該行動(dòng)發(fā)生的背景環(huán)境、技術(shù)棧、約束條件和相關(guān)系統(tǒng)狀態(tài)。 3. Expected Result預(yù)期結(jié)果 行動(dòng)成功執(zhí)行后系統(tǒng)應(yīng)達(dá)到的狀態(tài)或輸出的具體指標(biāo)。 用戶(hù)輸入 Action: 為微服務(wù)A設(shè)計(jì)一個(gè)熔斷機(jī)制。 Context: 當(dāng)前系統(tǒng)使用Spring Cloud框架服務(wù)間通過(guò)HTTP調(diào)用。在促銷(xiāo)活動(dòng)期間服務(wù)B的響應(yīng)時(shí)間偶爾會(huì)飆升到5秒以上導(dǎo)致調(diào)用鏈路上的服務(wù)A也出現(xiàn)線(xiàn)程池耗盡和響應(yīng)超時(shí)。 Expected Result: 實(shí)現(xiàn)一個(gè)熔斷器當(dāng)服務(wù)B的失敗率如超時(shí)、5xx錯(cuò)誤在10秒窗口期內(nèi)超過(guò)50%時(shí)快速失敗并進(jìn)入熔斷狀態(tài)熔斷持續(xù)30秒后進(jìn)入半開(kāi)狀態(tài)嘗試放行少量請(qǐng)求。 請(qǐng)確保你的方案包含技術(shù)選型理由、核心配置參數(shù)、代碼結(jié)構(gòu)示例、熔斷狀態(tài)轉(zhuǎn)換邏輯說(shuō)明以及監(jiān)控指標(biāo)設(shè)計(jì)。方案需要專(zhuān)業(yè)、詳盡且可直接用于開(kāi)發(fā)評(píng)審。這個(gè)提示詞清晰、結(jié)構(gòu)化但存在明顯的令牌浪費(fèi)角色定義冗長(zhǎng)“你是一個(gè)資深的軟件架構(gòu)師”是有效的但可以更精簡(jiǎn)?？蚣苷f(shuō)明重復(fù)在任務(wù)描述中詳細(xì)解釋了“ACE”每個(gè)部分的含義但這些解釋可能對(duì)于已經(jīng)理解該框架的模型是冗余的或者可以更緊湊地表達(dá)。指令分散需求說(shuō)明“請(qǐng)確保你的方案包含...”與任務(wù)描述分離增加了認(rèn)知負(fù)荷。格式化空格為了人類(lèi)可讀性添加的大量換行和縮進(jìn)對(duì)模型而言都是額外的令牌。2. 提示詞優(yōu)化策略從結(jié)構(gòu)到語(yǔ)義的壓縮優(yōu)化提示詞不是簡(jiǎn)單地刪除文字而是在保留核心指令和信息的前提下進(jìn)行結(jié)構(gòu)重組和語(yǔ)義精煉。目標(biāo)是讓模型以最少的“燃料”理解相同的“任務(wù)地圖”。2.1 策略一使用更緊湊的指令格式將開(kāi)放式的敘述性指令轉(zhuǎn)換為模型更易解析的鍵值對(duì)或標(biāo)記化指令。模型在預(yù)訓(xùn)練時(shí)見(jiàn)過(guò)大量結(jié)構(gòu)化數(shù)據(jù)對(duì)這種格式的理解效率很高。優(yōu)化前敘述式:你是一個(gè)資深的軟件架構(gòu)師。請(qǐng)根據(jù)用戶(hù)提供的以下三個(gè)要素撰寫(xiě)一份詳細(xì)的技術(shù)實(shí)施方案文檔... 用戶(hù)輸入 Action: ... Context: ... Expected Result: ...優(yōu)化后結(jié)構(gòu)化指令:角色軟件架構(gòu)師 任務(wù)基于ACE框架生成技術(shù)方案 輸入格式 - A: [行動(dòng)] - C: [上下文] - E: [預(yù)期結(jié)果] 輸出要求含技術(shù)選型、核心配置、代碼示例、狀態(tài)邏輯、監(jiān)控指標(biāo)。 輸入 A: 為微服務(wù)A設(shè)計(jì)一個(gè)熔斷機(jī)制。 C: Spring Cloud, HTTP調(diào)用服務(wù)B偶發(fā)5秒延遲導(dǎo)致A線(xiàn)程池耗盡。 E: 熔斷器10秒窗口失敗率50%則熔斷30秒后半開(kāi)。 方案優(yōu)化點(diǎn)分析“角色軟件架構(gòu)師”比“你是一個(gè)資深的軟件架構(gòu)師”更直接?！叭蝿?wù)基于ACE框架生成技術(shù)方案”概括了整個(gè)目標(biāo)。使用“A:”、“C:”、“E:”作為明確的分隔符模型能快速定位信息塊。將“輸出要求”緊跟在任務(wù)后作為生成約束。對(duì)Context和Expected Result進(jìn)行了語(yǔ)義壓縮去除了不影響核心信息的描述性詞語(yǔ)如“當(dāng)前系統(tǒng)”、“促銷(xiāo)活動(dòng)期間”、“偶爾”但保留了關(guān)鍵約束“5秒延遲”“線(xiàn)程池耗盡”。2.2 策略二利用系統(tǒng)的角色預(yù)設(shè)或上下文學(xué)習(xí)如果調(diào)用API如OpenAI API或本地部署的vLLM可以利用system角色消息來(lái)承載不變的指令和角色設(shè)定從而不在每次的user消息中重復(fù)。對(duì)于不支持多角色對(duì)話(huà)的簡(jiǎn)單接口可以將系統(tǒng)指令前置并固化。API調(diào)用示例OpenAI風(fēng)格:import openai # 系統(tǒng)消息包含角色和固定任務(wù)框架通常只發(fā)送一次或在會(huì)話(huà)開(kāi)頭發(fā)送。 system_message { role: system, content: 你是一名軟件架構(gòu)師負(fù)責(zé)根據(jù)ACE行動(dòng)、上下文、預(yù)期結(jié)果輸入生成技術(shù)方案。輸出需包含技術(shù)選型、配置、代碼示例、邏輯說(shuō)明、監(jiān)控指標(biāo)。 } # 用戶(hù)消息僅包含當(dāng)次查詢(xún)的具體ACE內(nèi)容非常精簡(jiǎn)。 user_message { role: user, content: A:設(shè)計(jì)熔斷機(jī)制\nC:Spring Cloud,服務(wù)B延遲高致A線(xiàn)程池耗盡\nE:失敗率50%熔斷30秒后半開(kāi) } response openai.ChatCompletion.create( modelgpt-4, messages[system_message, user_message], temperature0.7 )在這個(gè)例子中system_message的內(nèi)容在多次對(duì)話(huà)中只需傳輸一次如果會(huì)話(huà)保持后續(xù)的user_message可以極其精簡(jiǎn)大幅節(jié)省了令牌。2.3 策略三精簡(jiǎn)示例與上下文如果任務(wù)復(fù)雜需要少量示例Few-Shot Learning示例的選擇和呈現(xiàn)方式至關(guān)重要。選擇最具代表性的示例一個(gè)覆蓋邊界的復(fù)雜示例可能比兩個(gè)簡(jiǎn)單的示例更有效。壓縮示例內(nèi)容在示例中同樣應(yīng)用上述優(yōu)化策略精簡(jiǎn)輸入和輸出。使用分隔符用###、---或example等清晰分隔示例與真實(shí)查詢(xún)避免模型混淆。3. 工程實(shí)踐構(gòu)建一個(gè)提示詞優(yōu)化與評(píng)估管道理論需要實(shí)踐驗(yàn)證。我們構(gòu)建一個(gè)簡(jiǎn)單的Python流程來(lái)量化優(yōu)化效果并確保質(zhì)量。3.1 環(huán)境準(zhǔn)備與依賴(lài)首先確保你的Python環(huán)境建議3.8并安裝必要庫(kù)。我們將使用tiktoken用于OpenAI模型令牌計(jì)數(shù)或transformers用于開(kāi)源模型來(lái)計(jì)數(shù)并使用一個(gè)LLM服務(wù)進(jìn)行質(zhì)量評(píng)估。# 創(chuàng)建虛擬環(huán)境可選 python -m venv venv source venv/bin/activate # Linux/Mac # venv\Scripts\activate # Windows # 安裝依賴(lài) pip install openai tiktoken transformers # 基礎(chǔ)工具包 # 如果你使用其他LLM API如Anthropic Claude安裝對(duì)應(yīng)SDK # pip install anthropic3.2 實(shí)現(xiàn)令牌計(jì)數(shù)器編寫(xiě)一個(gè)函數(shù)用于計(jì)算給定提示詞的令牌數(shù)。這里以O(shè)penAI的cl100k_base編碼器GPT-4/3.5-turbo使用為例。import tiktoken def count_tokens_openai(text: str, model: str gpt-4) - int: 使用tiktoken計(jì)算文本的令牌數(shù)。 Args: text: 輸入文本。 model: 模型名稱(chēng)用于選擇編碼器。 Returns: 令牌數(shù)量。 try: encoding tiktoken.encoding_for_model(model) except KeyError: # 如果模型未找到使用 cl100k_base (GPT-4/3.5-turbo的編碼) encoding tiktoken.get_encoding(cl100k_base) tokens encoding.encode(text) return len(tokens) # 測(cè)試函數(shù) original_prompt 你是一個(gè)資深的軟件架構(gòu)師。請(qǐng)根據(jù)用戶(hù)提供的以下三個(gè)要素... # 此處填入完整的原始長(zhǎng)提示 optimized_prompt 角色軟件架構(gòu)師 任務(wù)基于ACE框架生成技術(shù)方案... # 此處填入優(yōu)化后的提示 orig_tokens count_tokens_openai(original_prompt) opt_tokens count_tokens_openai(optimized_prompt) print(f原始提示令牌數(shù): {orig_tokens}) print(f優(yōu)化后提示令牌數(shù): {opt_tokens}) print(f減少的令牌數(shù): {orig_tokens - opt_tokens}) print(f優(yōu)化比例: {(1 - opt_tokens/orig_tokens)*100:.2f}%)3.3 設(shè)計(jì)質(zhì)量評(píng)估方法令牌減少了但輸出質(zhì)量是否下降我們需要一個(gè)評(píng)估機(jī)制。一個(gè)簡(jiǎn)單有效的方法是使用另一個(gè)LLM或同一模型作為“裁判”根據(jù)既定標(biāo)準(zhǔn)對(duì)原始輸出和優(yōu)化后輸出進(jìn)行評(píng)分。import openai import json def evaluate_response_with_llm(original_output, optimized_output, evaluation_criteria): 使用LLM評(píng)估兩個(gè)回復(fù)的質(zhì)量。 Args: original_output: 原始長(zhǎng)提示得到的回復(fù)。 optimized_output: 優(yōu)化后提示得到的回復(fù)。 evaluation_criteria: 評(píng)估標(biāo)準(zhǔn)列表。 Returns: 包含評(píng)分和理由的字典。 prompt f 你是一個(gè)技術(shù)方案評(píng)審專(zhuān)家。請(qǐng)比較以下兩個(gè)技術(shù)方案回復(fù)Reply A 和 Reply B的質(zhì)量。 評(píng)估標(biāo)準(zhǔn)如下 {json.dumps(evaluation_criteria, indent2, ensure_asciiFalse)} 請(qǐng)從每個(gè)標(biāo)準(zhǔn)出發(fā)分析兩個(gè)回復(fù)的優(yōu)劣。最后給出一個(gè)綜合評(píng)分1-10分10分為最佳并說(shuō)明哪個(gè)回復(fù)更優(yōu)或是否相當(dāng)。 Reply A (來(lái)自原始提示):{original_output}Reply B (來(lái)自?xún)?yōu)化提示):{optimized_output}請(qǐng)以JSON格式輸出你的評(píng)估結(jié)果包含以下字段 - criteria_analysis: 對(duì)每個(gè)標(biāo)準(zhǔn)的詳細(xì)分析。 - score_a: Reply A的綜合得分。 - score_b: Reply B的綜合得分。 - conclusion: 最終結(jié)論說(shuō)明哪個(gè)回復(fù)更優(yōu)或是否持平。 # 調(diào)用LLM API這里需要替換為你自己的API密鑰和端點(diǎn) openai.api_key your-api-key response openai.ChatCompletion.create( modelgpt-4, messages[{role: user, content: prompt}], temperature0.2 # 低溫度保證評(píng)估穩(wěn)定性 ) evaluation_text response.choices[0].message.content # 嘗試解析JSON如果失敗則返回原始文本 try: return json.loads(evaluation_text) except json.JSONDecodeError: return {raw_evaluation: evaluation_text} # 定義評(píng)估標(biāo)準(zhǔn) criteria [ 完整性是否涵蓋了所有要求的要點(diǎn)技術(shù)選型、配置、代碼示例、狀態(tài)邏輯、監(jiān)控指標(biāo)。, 準(zhǔn)確性技術(shù)細(xì)節(jié)、配置參數(shù)、代碼邏輯是否正確無(wú)誤。, 清晰度方案結(jié)構(gòu)是否清晰表述是否易于理解。, 實(shí)用性方案是否可直接或經(jīng)少量修改后用于開(kāi)發(fā)評(píng)審。 ] # 假設(shè)我們已經(jīng)獲得了original_output和optimized_output # evaluation_result evaluate_response_with_llm(original_output, optimized_output, criteria) # print(json.dumps(evaluation_result, indent2, ensure_asciiFalse))3.4 運(yùn)行完整對(duì)比實(shí)驗(yàn)將以上步驟組合形成一個(gè)完整的A/B測(cè)試流程。def run_ace_prompt_experiment(original_prompt_text, optimized_prompt_text, ace_input, api_key): 運(yùn)行完整的提示詞對(duì)比實(shí)驗(yàn)。 openai.api_key api_key # 1. 計(jì)算令牌節(jié)省 orig_tokens count_tokens_openai(original_prompt_text \n ace_input) opt_tokens count_tokens_openai(optimized_prompt_text \n ace_input) token_saving orig_tokens - opt_tokens print( 令牌消耗對(duì)比 ) print(f原始提示組合令牌數(shù): {orig_tokens}) print(f優(yōu)化提示組合令牌數(shù): {opt_tokens}) print(f預(yù)計(jì)單次節(jié)省令牌: {token_saving} ({token_saving/orig_tokens*100:.1f}%)) # 2. 調(diào)用模型獲取回復(fù) def get_completion(prompt): response openai.ChatCompletion.create( modelgpt-3.5-turbo, # 可使用gpt-4但成本更高 messages[{role: user, content: prompt}], temperature0.7, max_tokens1500 ) return response.choices[0].message.content.strip() print(\n 生成回復(fù)... ) original_full_prompt original_prompt_text \n用戶(hù)輸入\n ace_input optimized_full_prompt optimized_prompt_text \n輸入\n ace_input reply_original get_completion(original_full_prompt) reply_optimized get_completion(optimized_full_prompt) # 3. 評(píng)估回復(fù)質(zhì)量 print(\n 進(jìn)行質(zhì)量評(píng)估... ) criteria [...] # 同上文的評(píng)估標(biāo)準(zhǔn) evaluation evaluate_response_with_llm(reply_original, reply_optimized, criteria) print(\n 評(píng)估結(jié)果 ) print(f原始回復(fù)得分: {evaluation.get(score_a, N/A)}) print(f優(yōu)化回復(fù)得分: {evaluation.get(score_b, N/A)}) print(f結(jié)論: {evaluation.get(conclusion, N/A)}) # 4. 綜合報(bào)告 print(\n 實(shí)驗(yàn)總結(jié) ) if evaluation.get(score_b, 0) evaluation.get(score_a, 0) * 0.95: # 優(yōu)化后質(zhì)量不低于原始的95% print(? 成功在保持質(zhì)量的前提下顯著減少了令牌消耗。) print(f 令牌節(jié)省比例: {token_saving/orig_tokens*100:.1f}%) else: print(?? 注意令牌減少但質(zhì)量有較明顯下降需要調(diào)整優(yōu)化策略。) return { token_original: orig_tokens, token_optimized: opt_tokens, reply_original: reply_original, reply_optimized: reply_optimized, evaluation: evaluation } # 執(zhí)行實(shí)驗(yàn) # 注意需要準(zhǔn)備好 original_prompt_text, optimized_prompt_text, ace_input 和有效的 api_key # result run_ace_prompt_experiment(original_prompt_text, optimized_prompt_text, ace_input, sk-...)4. 常見(jiàn)問(wèn)題與排查指南在實(shí)際優(yōu)化過(guò)程中你可能會(huì)遇到以下問(wèn)題。4.1 優(yōu)化后模型輸出偏離預(yù)期現(xiàn)象令牌數(shù)下降了但生成的方案遺漏關(guān)鍵要求或格式混亂?？赡茉蚺c解決方案指令過(guò)度壓縮導(dǎo)致歧義過(guò)度精簡(jiǎn)丟失了關(guān)鍵約束。例如刪除了“包含監(jiān)控指標(biāo)”的要求。檢查對(duì)比優(yōu)化前后提示詞確保所有硬性要求Must-have都被保留。解決使用更精確的關(guān)鍵詞而非刪除。將“請(qǐng)確保你的方案包含...監(jiān)控指標(biāo)設(shè)計(jì)”優(yōu)化為“輸出要求含...監(jiān)控指標(biāo)。”。結(jié)構(gòu)變化導(dǎo)致模型解析困難模型可能不熟悉你自定義的極簡(jiǎn)標(biāo)記如只用“A:”。檢查在優(yōu)化提示中是否使用了模型在預(yù)訓(xùn)練中常見(jiàn)的分隔符或格式。解決在system消息或提示開(kāi)頭用一句話(huà)明確格式“請(qǐng)嚴(yán)格按以下格式理解輸入A: [行動(dòng)] C: [上下文] E: [結(jié)果]”。上下文長(zhǎng)度不足過(guò)度壓縮的Context可能丟失了關(guān)鍵邊界條件。檢查優(yōu)化后的Context是否仍包含所有影響技術(shù)決策的約束如“Spring Cloud框架”、“HTTP調(diào)用”、“線(xiàn)程池耗盡”。解決優(yōu)先保留名詞性關(guān)鍵約束刪除形容詞和副詞性描述。4.2 令牌計(jì)數(shù)與API計(jì)費(fèi)不一致現(xiàn)象本地計(jì)算的令牌數(shù)與云服務(wù)商賬單顯示的令牌數(shù)有差異?？赡茉蚺c解決方案編碼器不一致不同模型使用不同的分詞器Tokenizer。檢查確認(rèn)你使用的計(jì)數(shù)工具如tiktoken是否與目標(biāo)API模型匹配。解決對(duì)于OpenAI API使用tiktoken并指定正確模型名如gpt-4。對(duì)于其他模型需使用其官方或兼容的分詞器如Hugging Face的transformers庫(kù)。計(jì)入了特殊令牌API計(jì)費(fèi)可能包括了消息角色如|im_start|user等特殊令牌。檢查API文檔是否說(shuō)明了輸入輸出的具體計(jì)數(shù)方式。解決對(duì)于精確成本測(cè)算最好使用API提供商提供的計(jì)數(shù)工具或在實(shí)際調(diào)用后查看返回的usage字段。4.3 質(zhì)量評(píng)估結(jié)果不穩(wěn)定現(xiàn)象同一對(duì)輸出多次評(píng)估得分波動(dòng)較大?？赡茉蚺c解決方案評(píng)估提示詞本身不精確評(píng)估標(biāo)準(zhǔn)過(guò)于主觀(guān)如“質(zhì)量更好”。檢查評(píng)估標(biāo)準(zhǔn)是否具體、可衡量如“是否提及Hystrix或Resilience4j”。解決將評(píng)估標(biāo)準(zhǔn)細(xì)化、量化。使用清單式評(píng)估讓LLM裁判做“是非題”而非“論述題”。評(píng)估模型溫度Temperature設(shè)置過(guò)高導(dǎo)致評(píng)估結(jié)果隨機(jī)性大。檢查在評(píng)估調(diào)用中是否設(shè)置了較低的temperature如0.1或0.2。解決將評(píng)估模型的temperature設(shè)為0或使用確定性更高的模型如gpt-4。5. 生產(chǎn)環(huán)境最佳實(shí)踐與擴(kuò)展方向?qū)⑻崾驹~優(yōu)化納入開(kāi)發(fā)流程需要系統(tǒng)化的方法。5.1 建立提示詞版本管理與測(cè)試套件像管理代碼一樣管理提示詞。版本控制使用Git管理原始提示和優(yōu)化后提示提交信息記錄優(yōu)化策略和預(yù)期收益?；貧w測(cè)試為關(guān)鍵任務(wù)提示詞建立一組標(biāo)準(zhǔn)測(cè)試用例ACE輸入和期望輸出的關(guān)鍵點(diǎn)。每次優(yōu)化后運(yùn)行測(cè)試套件確保輸出質(zhì)量不低于基線(xiàn)。A/B測(cè)試在允許的情況下在生產(chǎn)流量中進(jìn)行小比例的A/B測(cè)試直接比較優(yōu)化前后版本的用戶(hù)滿(mǎn)意度或任務(wù)完成率。5.2 制定提示詞優(yōu)化清單在重構(gòu)任何提示詞前對(duì)照此清單檢查角色定義能否用一兩個(gè)詞概括能否移到system消息中任務(wù)描述核心指令是否在開(kāi)頭用一句話(huà)說(shuō)清輸入格式是否使用模型熟悉的結(jié)構(gòu)如JSON、鍵值對(duì)、清晰分隔符輸出要求是否以清單形式列出而非段落描述示例是否必要如果必要是否已最大程度精簡(jiǎn)冗余修飾詞是否刪除了“請(qǐng)”、“一個(gè)”、“詳細(xì)的”等不影響核心語(yǔ)義的詞語(yǔ)注意有時(shí)“請(qǐng)”有助于改善語(yǔ)氣需權(quán)衡。上下文信息是否只保留了影響決策的關(guān)鍵名詞和數(shù)字刪除了背景故事5.3 探索自動(dòng)化與高級(jí)優(yōu)化技術(shù)對(duì)于大規(guī)模應(yīng)用可以考慮提示詞壓縮算法研究如LLMLingua等基于小型語(yǔ)言模型識(shí)別并刪除提示中冗余令牌的技術(shù)。提示詞微調(diào)Fine-tuning針對(duì)特定任務(wù)訓(xùn)練一個(gè)模型使其在極簡(jiǎn)指令下就能輸出高質(zhì)量結(jié)果從根本上減少對(duì)長(zhǎng)提示的依賴(lài)。語(yǔ)義緩存對(duì)于相同或相似語(yǔ)義的查詢(xún)直接返回緩存的結(jié)果避免重復(fù)調(diào)用LLM。最終記住優(yōu)化的黃金法則先確保提示詞清晰、準(zhǔn)確、能穩(wěn)定產(chǎn)生高質(zhì)量輸出然后再對(duì)其進(jìn)行壓縮。不能本末倒置為了節(jié)省少量令牌而引入輸出不確定性和錯(cuò)誤風(fēng)險(xiǎn)。通過(guò)本文提供的策略、工具和清單你可以系統(tǒng)化地開(kāi)展這項(xiàng)工作在成本、速度和效果之間找到最佳平衡點(diǎn)。