LLM模型prompt開發及?模型應?
- ?語?模型 LLM
- 如何構建?個AI對話系統
- 關于模型的訓練
- ollama
- 調?LLM模型
- 設置API KEY
- 測試一個對話
- prompt提示詞
- 提示詞結構特征
- 提示詞的五大核心價值
- 1. 信息傳遞的精準性
- 2. 輸出質量的可控性
- 3. 用戶意圖的對?性
- 4. 復雜任務的拆解性
- 5. 倫理?險的防御性
- 經典框架解析
- 任務場景
- 問題拆解法
- 最終示例
?語?模型 LLM
引?
?型語?模型模型，?義上的理解：就是?種通過特定的算法和數據結構?構建的?種機器學習推理模型。?狹義上我們還
可以把它理解為：通過超?的算法模型所構建的?種?機交互系統。
對于?義?式的理解，恐怕很多不了解相關技術概念名稱的?是很困難的。但對于狹義的?式（或者理解為從“它能做什么?）這個?度出發，我們倒是可以通過?個有趣的解釋來理解為什么說 “?語?模型是?種?機交互系統?。
從?類發明并創造 電腦（Computer） 這種設備以來，無論是?型化，?型化，還是微型化。我們都在不予余?的想要通過 電腦（Computer） 為?類達到?個目的：幫助?類解決現實?生活活中的各類需求和問題。
這個目標或者說是理想，在之前很??段時間實現起來都是非常困難的。原因有兩個：?是因為電腦創造之初，就是數學和?程的天才作品，其結構和?作原理不是普通?能夠輕松理解的。?是因為其結構和?作形式并不能直接和?類的思想和?為習慣直接對接。
隨著軟件系統的規模和復雜度不斷上升，我們也不得不接收這樣的?個現實：想要讓計算機幫助我們完成某項任務，我們必
須要先通過學習才能掌握它，讓它為我們服務。
如何構建?個AI對話系統
怎么構建?臺能與我們對話的系統呢？最有效的?種?法就是讓機器去傾聽（把?本內容輸?給AI 對話系統）。設計這類機器系統的主要?作就是讓機器系統?量的學習?類的語?和對話；
但僅靠傾聽還遠遠不能實現我們所想要得到的 “聰明的? 智能AI對話系統。實際上，?語?模型（LLM）所練習的是 “最?程度的積極地傾聽?：讓智能對話系統不斷連續地嘗試預測說話者的下?句話內容。
注意：這?所說的“連續?是指按 字符的?式逐個嘗試預測
關于模型的訓練
也許在剛剛上?提到的最后?句話中，我們提到 訓練“train? 這個詞。按照常識，“train? 就是意味著某種形式的監督，也可以表?為某種形式的?法和?段。
訓練對話系統（Chat GPT）的學習材料都是從互聯?上抓取的?本內容，所以內容的連續性是可以確保的，訓練所需要
的前提條件完全可以滿?。
所以模型的訓練就是：監督者負責將對話系統預測的內容與?本中的實際內容進?對?，不斷訓練模型正確地預測?本后?的內容。
所以說，?語?模型的訓練是?法問題。
ollama
ollama 是?個讓?語?模型在本地運?的軟件?具。
ollama 快速上?
安裝成功后，可以在系統的終端下直接通過指令運?。它會根據指令和指定的模型?動下載，存?本地后運?。
調?LLM模型
?語?模型的本地化調?與API調?這兩種?式各有其獨特的特點和差異性
?語?模型的調?分為本地化和遠程調??式：
本地化調?：
from transformers import pipeline, set_seed
if __name__ == '__main__':generator = pipeline('text-generation', model='openai-community/gpt2')set_seed(33)text = generator("你好！我是?個AI助?,", max_length=50, num_return_sequences=5,print(text)
優點
- 能夠完全控制數據和模型,確保數據隱私和安全；
- 可以根據特定需求進?定制和優化；
- ?需依賴外部服務，避免?絡延遲。
缺點
- 需要強?的計算資源和基礎設施
- 維護和更新成本?
- 初始設置復雜，技術?檻?。
遠程調?：
import requestsimport jsonif __name__ == '__main__':# url = 'http://localhost:11434/api/chat'url = 'http://localhost:11434/api/generate'data = {"model": "qwen2","prompt": "?海為什么是藍?的？","stream" False}response = requests.post(url, json=data)print(response.status_code)print(json.loads(response.text)["response"])
優點：
- ?需強?的本地計算資源，使??便；
- 由提供商負責維護和更新，降低管理成本；
- 可以快速集成和部署，適合快速開發和測試。
缺點： - 數據需要傳輸到外部服務，存在隱私和安全問題；
- 依賴?絡穩定性，可能遇到延遲問題；
- 功能和使?受到API提供商的限制。
?模型調?存在兩種模式：chat 和 generate
generate：通常是?次性?成?本，在單個請求中根據給定的輸?和條件?成指定的?本輸出，不保留對話狀態，每次?成都是獨?的，適合于沒有對話上下?依賴的任務。
chat：主要?于模擬對話場景，?持多輪對話。它會維護對話的上下?信息，能夠根據之前的對話歷史?成相關的回復，就像?與?之間的聊天?樣，適?于連續對話和需要上下?理解的任務。
上? 遠程調? 代碼展?的是使?web協議調?本地ollama模型的實現，并?真正的 “遠程?
設置API KEY
雖然 OpenAI 的 chatgpt3.5 web版已經可以?需注冊直接使?了，但對于API 調?，還是需要注冊??的?份驗證的。官?提供了免費注冊機制，但所有的API調?都會以調?時對應的token數量（包括輸?的prompt提?和?成的response）來計費。所以，對于開發者來講，這部分不是免費的。
?持 OpenAI API 的國內?模型也可以使?，推薦智譜清源的flash免費?模型。?需代理，但要指定 api-key 和 base-url 。https://www.bigmodel.cn/console/overview
測試一個對話
1.?先安裝python-dotenv包，?于?持配置項導?系統環境變量
2.創建或打開?個項目目錄，內部創建?個 .env ?件并使??本編輯器編輯內容
API_KEY=“此處替換為??的api-key” # API_Key
BASE_URL=“https://open.bigmodel.cn/api/paas/v4” # 智譜官?API URL
3.編寫?段python代碼，測試openai的api對話調?
import os
from dotenv import load_dotenv,find_dotenv
from openai import OpenAI
if __name__ == "__main__":load_dotenv(find_dotenv())#創建調用客戶端client = OpenAI(api_key = os.getenv["api_key"],base_url = os.getenv("base_url"),)#chat模式調用response = client.chat.completions.create(#模型名稱model = "glm-4-plus"#消息messages=[{'role':'user','content':"我喜歡你，你喜歡我嗎？"}]#模型參數temperature = 0)#打印結果print(response.choices[0].message.content)
find_dotenv 會搜索并返回 .env ?件所在的位置，字符串格式。
load_dotenv 會加載指定 .env ?件中的字段，注冊為系統環境變量。可以通過 os.getenv 讀取系統環境變量的值。
OpenAI 對象會通過指定的 api_key 和 base_url 創建?個?模型調?的客?端，?于和指定的服務器連接并進?通訊。
client.chat.completions.create() 是實現chat模式的客?端?法調?。
參數：
model 指定要調?的模型名稱
messages 由?個或多個?? role 對話內容組成的信息，這?我們稱之為 提?詞（Prompt）。
temperature 采樣溫度，控制輸出的隨機性，必須為正數 取值范圍是： (0.0,1.0) ， 默認值為 0.75 ，值越?，會使輸出更
隨機，更具創造性；值越?，輸出會更加穩定或確定。
top_p 核取樣 取值范圍是： (0.0, 1.0) ，默認值為 0.90 模型考慮具有 top_p 概率質量 tokens 的結果。
max_tokens 控制?成的響應的最? tokens 數量
?模型token統計
token 可簡單理解為模型處理?本時的基本單位，通常是字詞、標點、?段等的編碼表? ，不同模型的 token 切分規則有差異 。
例如：Open AI 的 o3 模型，最多?持20萬個上下? token，最多?持10萬個 最?輸出 token。
上下?（context）：指模型在?成或理解?本時所參考的 “前?信息? ，這些信息以 token 形式被模型納?考慮。
最?輸出（max output）：指模型?次?成?本時，最多能輸出的 token 數量 。
響應格式
{"choices": [{"finish_reason": "stop","index": 0,"message": {"content": "2022年世界杯在卡塔爾舉?。","role": "assistant"},"logprobs": null}],"created": 1677664795,"id": "chatcmpl-7QyqpwdfhqwajicIEznoc6Q47XAyW","model": "gpt-3.5-turbo-0613","object": "chat.completion","usage": {"completion_tokens": 17,"prompt_tokens": 57,"total_tokens": 74}
}
對話響應的關鍵信息在 content 字段中，可以直接?下?的代碼獲取
response.choices[0].message.content
每個響應都將包含?個 finish_reason 可能取值為：
stop ：API 返回完整消息，或由通過 stop 參數提供的停?序列之?終?的消息
length ：由于 max_tokens 參數令牌限制模型的輸出不完整
function_call ：模型決定調??個函數
content_filter ：由于指定了內容過濾器中的關鍵詞?省略了內容
null ：API 響應仍在進?中或未完成
根據輸?參數，模型響應可能包含不同的信息。
prompt提示詞
提示詞在?模型交互中的核心作用
在了解了?模型?作的本質：通過統計預測?成?本后，也就明??模型對語義是缺乏真正理解的。
那么所謂的提?詞（prompt）?是什么呢？我們可以把??當做是與?模型進?交互的 “翻譯官” ??。
既然是翻譯，那么就要??思考?下。提?詞就是對?模型提出問題或要求時，詳細描述的?本。
通過描述增加模型的理解
下?我們可以通過下?的實驗來對?:
輸?簡單提示：
分析用戶需求
觀察?模型?成的?本，是具體？還是泛泛?談？
輸入優化提示：
作為電商客服，分析??投訴 ’ 物流太慢 ’ 的原因，需包含快遞公司效率、天?影響、??收貨地址三個維度
補償模型缺陷
?模型缺陷：缺乏實時數據、專業領域知識、邏輯推理能?
知識注?：
當前時間是2025年3?2?，據@國鐵濟南局 微博消息，濟南、淄博等地出現?范圍暴雪，受此影響，京滬?分析?鐵延誤原因。
領域限定：
“以律師?份審核合同條款…”
提示詞結構特征
橫軸：表示包含答案的?檔在輸?中的位置，從第1位到第20位 。
縱軸：表示模型回答的準確率（Accuracy）。
數據曲線：展示的是gpt-3.5-turbo-0613的表現。（open-book 即開卷模式，表?可訪問相關?檔）
標注說明：
當相關?檔在輸?開頭（1st Position ）時，模型準確率?達75左右 。
當相關?檔在輸?結尾（20th Position ）時，準確率約為63 。
當相關?檔在輸?中間位置（如10th Position ）時，準確率?幅下降。
基線對?：紅?虛線代表gpt-3.5-turbo-0613（closed - book，閉卷模式，不能訪問相關?檔）的表現，作為基線（Baseline: model must answer question without access to a document ），其準確率穩定在55左右 。
提示詞的五大核心價值
1.信息傳遞的精準性
2.輸出質量的可控性
3.用戶意圖的對?性
4.復雜任務的拆解性
5.倫理?險的防御性
1. 信息傳遞的精準性
**問題：**模糊指令導致輸出偏差
新版本：A5CN204
更新內容：
1.更新 ZLauncher 版本? v1.1.3-beta
2.更新應?商店版本? v2.60
3.修復品牌顯?錯誤
4.瀏覽器默認主?更改為http://n1.nokia.com/cn
5.修復部分?機拔插可能出現的偵測錯誤
6.修正??量時揚聲器外放破?問題
7.提升揚聲器?量穩定性
8.提升藍?偵測穩定性
9.加強視頻播放的暫停/快進/快退流暢度
10.加強部分App運?效率，如電?郵件，應?商店等
根據以上描述，撰寫產品升級說明
解決?案：
明確?標：根據以上描述，撰寫500字以內的產品升級說明。
量化標準：
根據以上描述，撰寫產品升級說明，要求達到客?滿意度提升20%以上。
案例對?：
低效：“撰寫產品升級說明” → 輸出抽象
?效：“500字以內、滿意度提升20%以上” → 輸出可執??案
2. 輸出質量的可控性
約束維度：
針對對?份電商的客?評論，?成?份電商?動回復。實現提?詞可控
3. 用戶意圖的對?性
深層需求挖掘：
??輸?：
?成xxx促銷?案
潛在需求：提升轉化率、突出產品賣點、符合品牌調性
提?詞設計：
撰寫突出 ’ 限時折扣 + 贈品 ’ 的促銷?案，使?感嘆號增強緊迫感，結尾添加購買鏈接
4. 復雜任務的拆解性
拆解策略：
問題拆解法：
制定市場推??案
分解為 “?標設定→競品分析→渠道選擇→效果評估”
多輪提?法：
通過 “請先收集數據→分析趨勢→?成?案” 的分步驟引導
5. 倫理?險的防御性
安全控制：
敏感詞過濾：“禁?提及政治敏感話題”
合規引導：“根據《?絡安全法》第 XX 條…”
?險警?：“此內容可能涉及虛假宣傳，請核查事實”
經典框架解析
??設定 + 任務指令 + ?例引導
問題拆解法：將復雜任務分解為?步驟
任務場景
??需要為?場線上會議設計?個30分鐘的議程框架，要求覆蓋討論主題、時間分配、參與?員和預期成果。
- ??設定
你是?位專業的會議策劃專家，擅??效組織線上會議。你的任務是根據??需求，設計結構化的議程框架。 - 任務指令
請為?場30分鐘的線上會議設計議程框架，需包含以下要素：
會議主題與?標
時間分配（精確到分鐘）
關鍵討論點與參與?員
預期成果與后續?動 - ?例引導
?例輸?：
討論新市場進?策略，參會者包括市場部負責?、產品經理、銷售總監。
?例輸出：
- 會議主題：東南亞市場進?策略討論（30分鐘）
?標：確定產品定位、渠道選擇和推?預算。
時間分配：
- 開場（2分鐘）：主持?介紹議程與?標（主持?：市場部負責?）
- 市場分析（8分鐘）：產品經理匯報數據（參與?：產品經理）
- 渠道討論（10分鐘）：銷售總監提出建議（參與?：銷售總監）
- 預算分配（8分鐘）：全體討論并確定?案（參與?：全體）
- 總結（2分鐘）：主持?確認下?步?動（主持?：市場部負責?）
- 預期成果：
- 確定產品核?賣點與?標??畫像。
- 明確渠道優先級與推?預算分配。
- 后續?動：市場部3?內提交細化?案。
問題拆解法
將任務分解為?步驟：
確定會議主題與?標
?問題：??的核?需求是什么？需要解決哪些具體問題？
時間分配與流程設計
?問題：每個環節需要多?時間？如何平衡討論與決策？
關鍵討論點與??分配
?問題：哪些環節需要特定?員主導？如何避免冷場或超時？
預期成果與閉環
?問題：會議結束后需要輸出什么？誰負責后續跟進？
最終示例
你是?位專業的會議策劃專家。請根據以下輸?設計30分鐘線上會議議程：
輸?：
討論公司年度營銷預算分配，參會者包括CEO、市場總監、財務總監。
要求：
- 按照“會議主題與?標 → 時間分配 → 關鍵討論點與?? → 預期成果?的結構輸出。
- 參考?例格式，確保每個環節時間精確到分鐘，??明確。
- ?例：[上述?例內容]
輸出：
[此處由模型?成]
解析說明
- ??設定明確了模型的專業性，增強??信任。
- 任務指令將模糊需求轉化為具體可執?的框架。
- ?例引導通過結構化案例降低模型理解成本。
- 問題拆解法將復雜任務分解為可管理的?步驟，確保邏輯完整性。通過此框架，模型可?效?成符合預期的會議議程，減少迭代成本。
)