1. 這不是“AI名詞解釋大全”而是一份技術(shù)人用得上的國慶掃盲地圖“AI概念大全技術(shù)人的國慶7天掃盲指南”——看到這個標(biāo)題我第一反應(yīng)不是去翻教科書而是打開終端敲了兩行命令git clone https://github.com/ai-lexicon/ai-glossary和make build-pdf。結(jié)果發(fā)現(xiàn)90%的所謂“AI術(shù)語手冊”要么是把維基百科詞條復(fù)制粘貼成PDF要么堆砌一堆“大模型”“Transformer”“RLHF”之類的詞配上三行百度百科式定義連“為什么需要這個概念”“它在真實項目里長什么樣”都懶得提。更別說區(qū)分“技術(shù)人真正在意的邊界”比如“微調(diào)Fine-tuning”和“提示工程Prompt Engineering”根本不是同一層抽象——前者要改權(quán)重、跑GPU、管顯存后者連GPU都不用但對業(yè)務(wù)邏輯的理解深度反而決定成敗。這份指南是我過去三年帶團(tuán)隊做AI落地時反復(fù)被問爆的37個問題的濃縮。它不按字母順序排也不照搬論文結(jié)構(gòu)而是按技術(shù)人真實的認(rèn)知路徑來組織從你早上打開釘釘看到“老板說我們要上AI”到下午在會議室里聽產(chǎn)品經(jīng)理講“希望AI能自動寫周報”再到晚上回家查資料時被“LoRA”“QLoRA”“DPO”這些縮寫繞暈——這條路徑上每一個卡點(diǎn)我都標(biāo)好了坐標(biāo)、配好了實操快照、寫清了避坑口訣。比如“Agent”這個詞2024年之前工程師聊的是“智能體架構(gòu)設(shè)計”2024年之后再聊必須先確認(rèn)對方說的是“LangChain里的Agent類”還是“AutoGen里的GroupChatManager”或是“LlamaIndex里的ReActAgent”——它們底層調(diào)用的API、依賴的LLM能力、甚至錯誤日志格式全都不一樣。不厘清這個光背定義毫無意義。它適合三類人剛轉(zhuǎn)AI崗的后端/前端工程師想快速建立技術(shù)判斷力帶AI項目的PM或技術(shù)負(fù)責(zé)人需要和算法團(tuán)隊高效對齊語言還有那些被“AI”項目推著走的運(yùn)維、測試、DBA同事——你們不需要訓(xùn)練模型但得知道“為什么這個服務(wù)突然CPU飆到95%”“為什么緩存命中率從99%掉到60%”。整份指南所有概念都錨定在可觀察、可調(diào)試、可部署的實操現(xiàn)場。沒有“理論上可以”只有“我昨天在K8s里實測過加這行配置后延遲降了400ms”。國慶七天每天聚焦一個認(rèn)知模塊每天動手驗證一個最小可行案例。不是填鴨是拆解——把AI這個黑盒子一層層剝開給你看里面的螺絲、線纜和散熱硅脂。2. 概念分層為什么不能按字母表學(xué)AI技術(shù)人的認(rèn)知必須匹配工程現(xiàn)實2.1 真正的分層邏輯從“能跑通”到“能交付”的四階躍遷很多AI掃盲材料失敗的根本原因在于混淆了概念層級。就像教人修車如果一上來就講“熱力學(xué)第二定律”而不是先讓你擰開機(jī)油蓋看液位那學(xué)完也只會背公式。AI領(lǐng)域同樣存在清晰的四階認(rèn)知躍遷每一階對應(yīng)不同的技術(shù)動作、工具鏈和風(fēng)險點(diǎn)L0能跑通Run—— 目標(biāo)讓一段代碼在本地筆記本上輸出非空結(jié)果。典型場景pip install transformers python -c from transformers import pipeline; p pipeline(text-generation); print(p(Hello))。這里的關(guān)鍵是環(huán)境兼容性CUDA版本、PyTorch編譯選項、基礎(chǔ)依賴tokenizers、safetensors是否裝對。我見過太多人卡在這一步因為transformers4.40.0要求torch2.2.0而他們系統(tǒng)里是torch2.1.2報錯信息卻只顯示ImportError: cannot import name xxx根本看不出根源。L1能復(fù)現(xiàn)Reproduce—— 目標(biāo)在不同機(jī)器、不同時間用相同輸入得到相同輸出。這要求嚴(yán)格鎖定隨機(jī)種子torch.manual_seed(42)、確定性算法torch.backends.cudnn.deterministic True、模型權(quán)重哈希校驗sha256sum pytorch_model.bin。去年我們交付一個文本分類模型給客戶測試環(huán)境準(zhǔn)確率92%生產(chǎn)環(huán)境只有87%——最后發(fā)現(xiàn)是客戶服務(wù)器沒關(guān)cudnn.benchmark導(dǎo)致每次卷積算子選擇不同小數(shù)點(diǎn)后三位的浮點(diǎn)誤差累積放大。L2能調(diào)優(yōu)Tune—— 目標(biāo)在約束條件下顯存≤16GB、推理延遲≤500ms、成本≤$0.02/次找到最優(yōu)配置。這時才真正用到“LoRA”“量化”“vLLM”這些詞。但注意LoRA不是萬能銀彈。我在某電商客服項目里試過對7B模型加LoRA適配層顯存從14GB降到9GB但QPS從120掉到78——因為LoRA引入的額外矩陣乘法讓GPU kernel launch overhead翻倍。最終換成了AWQ量化FlashAttention-2顯存壓到6.2GBQPS反升到156。L3能交付Ship—— 目標(biāo)模型作為服務(wù)穩(wěn)定運(yùn)行30天以上支持灰度發(fā)布、AB測試、異常熔斷、指標(biāo)監(jiān)控。這時“Agent”不再是論文里的agent而是Prometheus里的一條ai_request_duration_seconds_bucket曲線“RAG”不再是向量檢索流程圖而是Grafana面板上rag_retrieval_latency_ms和llm_generation_latency_ms的雙峰分布“評估”不是accuracy數(shù)字而是業(yè)務(wù)側(cè)定義的“用戶點(diǎn)擊‘繼續(xù)追問’按鈕的比例提升≥15%”。提示跳過L0/L1直接學(xué)L2/L3就像沒學(xué)過加減法就去解微分方程——表面看懂了實際一寫代碼就崩。國慶七天建議前兩天死磕L0/L1用Hugging Face的transformers庫跑通5個經(jīng)典任務(wù)文本分類、命名實體識別、問答、摘要、文本生成每跑通一個手動改一行代碼比如換tokenizer、改max_length、刪掉device_mapauto觀察報錯信息這才是真正的掃盲起點(diǎn)。2.2 概念映射表每個熱詞背后的真實技術(shù)動作網(wǎng)絡(luò)熱搜詞常把技術(shù)概念娛樂化、模糊化。比如“AI Agent”被自媒體渲染成“數(shù)字員工”但工程師眼里它本質(zhì)是狀態(tài)機(jī)工具調(diào)度LLM調(diào)用的組合模式。下表列出國慶期間高頻熱詞及其在真實工程中的技術(shù)動作、常用工具、典型陷阱熱搜詞工程本質(zhì)常用工具/框架典型陷阱我的實操口訣大模型LLM參數(shù)量10B的自回歸語言模型核心約束是KV Cache內(nèi)存占用Hugging Face Transformers, vLLM, Ollama盲目追求參數(shù)量忽略上下文長度對顯存的平方級影響2048→4096KV Cache內(nèi)存×4“顯存不夠先砍context_length再考慮量化最后才換小模型”RAG檢索增強(qiáng)生成將外部知識庫檢索結(jié)果拼接到prompt中讓LLM基于事實回答LlamaIndex, LangChain, Milvus, Chroma檢索結(jié)果噪聲大LLM盲目信任錯誤片段生成“幻覺答案”“RAG效果差先檢查檢索召回率Recall5再調(diào)rerank閾值最后才動LLM prompt”Agent用LLM決策下一步動作調(diào)用工具/API/查數(shù)據(jù)庫循環(huán)直到目標(biāo)達(dá)成LangChain Agents, AutoGen, CrewAI工具調(diào)用失敗不重試、無超時控制、狀態(tài)丟失導(dǎo)致無限循環(huán)“Agent必加三道保險工具調(diào)用超時timeout10s、最大步數(shù)限制max_iter5、失敗日志落盤loggingTrue”微調(diào)Fine-tuning在預(yù)訓(xùn)練模型上用領(lǐng)域數(shù)據(jù)更新部分權(quán)重適配下游任務(wù)PEFT (LoRA), Hugging Face Trainer, DeepSpeedLoRA rank設(shè)太高64導(dǎo)致顯存爆炸或太低4導(dǎo)致效果無提升“LoRA rank經(jīng)驗公式base_model_dim × 0.0017B模型推薦rank813B模型推薦rank16”提示工程Prompt Engineering通過設(shè)計prompt結(jié)構(gòu)、few-shot示例、約束格式引導(dǎo)LLM輸出符合預(yù)期的結(jié)果PromptFlow, DSPy, LangChain PromptTemplate過度依賴復(fù)雜prompt掩蓋模型能力不足線上效果隨LLM版本升級劇烈波動“Prompt不是萬能膠先用rule-based baseline兜底再用prompt優(yōu)化上限兩者AB測試”這張表不是讓你死記硬背而是提供診斷線索。比如你聽到“我們做了RAG但用戶反饋答案不準(zhǔn)”別急著調(diào)LLM先查表里“RAG”對應(yīng)的“典型陷阱”——立刻想到去查recall5指標(biāo)。我上周幫一個政務(wù)項目排查RAG問題發(fā)現(xiàn)召回率僅32%原因是他們用默認(rèn)的SentenceTransformer模型做嵌入而政務(wù)文本含大量專有名詞如“長三角一體化發(fā)展示范區(qū)”通用模型根本無法捕捉語義。換成微調(diào)過的領(lǐng)域嵌入模型后召回率升至89%答案準(zhǔn)確率同步提升。2.3 為什么“掃盲”必須包含部署與監(jiān)控——脫離生產(chǎn)的概念都是空中樓閣很多技術(shù)人學(xué)AI止步于Jupyter Notebook里的model.generate()。但真實世界里模型上線后第一小時比訓(xùn)練過程更重要。我經(jīng)歷過三次“模型上線即崩潰”事件原因全在概念盲區(qū)第一次模型在本地generate()很穩(wěn)上線后大量CUDA out of memory。查日志發(fā)現(xiàn)生產(chǎn)API網(wǎng)關(guān)默認(rèn)開啟keep-alive長連接導(dǎo)致GPU顯存無法釋放。解決方案在FastAPI的StreamingResponse里強(qiáng)制headers{Connection: close}。第二次RAG服務(wù)響應(yīng)時間從200ms飆升到3s。監(jiān)控顯示redis_memory_used_bytes暴漲。原來開發(fā)用redis-py的pipeline批量存向量但沒設(shè)pipeline.execute()超時Redis阻塞后所有請求排隊。修復(fù)加pipeline.execute(timeout1.0)。第三次LLM服務(wù)CPU使用率99%但GPU利用率僅12%。nvidia-smi顯示顯存已滿ps aux發(fā)現(xiàn)Python進(jìn)程占滿CPU。根源是transformers的generate()默認(rèn)啟用use_cacheTrue但生產(chǎn)環(huán)境并發(fā)高KV Cache管理混亂觸發(fā)大量CPU-GPU數(shù)據(jù)拷貝。方案改用vLLM其PagedAttention機(jī)制原生解決此問題。這些教訓(xùn)說明“AI概念”的完整定義必須包含其在生產(chǎn)環(huán)境中的可觀測性指標(biāo)、資源消耗特征、故障模式。比如“量化Quantization”這個概念不能只講“把FP16轉(zhuǎn)INT4”而要明確AWQ量化需硬件支持Ampere GPU顯存節(jié)省約60%但首次推理慢權(quán)重解壓縮開銷GPTQ量化純軟件實現(xiàn)兼容性好但量化后模型體積比AWQ大15%動態(tài)量化Dynamic Quantization僅對激活值量化CPU推理友好GPU上無效。國慶掃盲每天學(xué)完概念必須動手做一件事用psutil和pynvml監(jiān)控一次本地推理的CPU/GPU/內(nèi)存占用截圖保存。第七天你會發(fā)現(xiàn)自己看技術(shù)文檔的眼光徹底變了——不再問“這個模型多大”而是問“它在A10上batch_size1時的P95延遲是多少”。3. 國慶七天實操路線圖每天一個最小閉環(huán)拒絕紙上談兵3.1 Day 1L0級通關(guān)——用Hugging Face跑通第一個文本生成任務(wù)目標(biāo)不是“學(xué)會”而是親手制造并解決一個真實報錯。很多人卡在第一步不是能力問題而是環(huán)境配置的細(xì)節(jié)黑洞。實操步驟創(chuàng)建干凈虛擬環(huán)境python3.10 -m venv ai-scan source ai-scan/bin/activate安裝最小依賴pip install torch2.2.0 torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118注意cu118匹配你的NVIDIA驅(qū)動安裝transformerspip install transformers4.40.0避免最新版的breaking change運(yùn)行最簡代碼from transformers import AutoTokenizer, AutoModelForCausalLM import torch tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2-0.5B-Instruct) model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2-0.5B-Instruct, torch_dtypetorch.float16) model.to(cuda) inputs tokenizer(你好今天天氣如何, return_tensorspt).to(cuda) outputs model.generate(**inputs, max_new_tokens50) print(tokenizer.decode(outputs[0], skip_special_tokensTrue))關(guān)鍵陷阱與排查報錯OSError: Cant load tokenizer for Qwen/Qwen2-0.5B-Instruct說明Hugging Face Hub未登錄。執(zhí)行huggingface-cli login用Token登錄Token在https://huggingface.co/settings/tokens獲取。報錯CUDA out of memoryQwen2-0.5B需約3GB顯存若顯存不足加device_mapauto自動分層加載或改用Qwen/Qwen2-0.5B無instruct版更輕量。輸出亂碼或空字符串檢查skip_special_tokensTrue是否漏寫或tokenizer是否匹配模型Qwen系列必須用Qwen tokenizer。實操心得我第一次跑通時發(fā)現(xiàn)max_new_tokens50生成了200字符。查源碼發(fā)現(xiàn)generate()默認(rèn)pad_token_id為None導(dǎo)致padding位置被誤生成。解決方案顯式指定pad_token_idtokenizer.eos_token_id。這種細(xì)節(jié)只有親手踩坑才會記住。3.2 Day 2L1級加固——實現(xiàn)跨環(huán)境結(jié)果一致性目標(biāo)在Mac M2無GPU、Windows RTX4090、Linux A10服務(wù)器上用同一段代碼、同一模型、同一輸入得到完全相同的輸出。核心操作固定隨機(jī)種子在代碼開頭加import torch import numpy as np import random torch.manual_seed(42) np.random.seed(42) random.seed(42)關(guān)閉非確定性算法torch.backends.cudnn.enabled FalseGPU或torch.backends.mps.enabled FalseMac鎖定模型權(quán)重下載模型文件到本地用from_pretrained(./local_qwen)而非在線加載避免Hub版本漂移驗證方法將生成結(jié)果tokenizer.decode(outputs[0])的SHA256哈希值打印出來三臺機(jī)器對比是否一致。不一致逐項檢查Python版本3.10.12 vs 3.10.13可能有細(xì)微差異PyTorch編譯選項torch.__config__.show()查看CUDA/cuDNN版本nvcc --version,cat /usr/local/cuda/version.txt注意完全一致性在分布式訓(xùn)練中幾乎不可能但單機(jī)推理必須做到。這是后續(xù)所有調(diào)優(yōu)的基石——如果連結(jié)果都不可復(fù)現(xiàn)調(diào)參就是玄學(xué)。3.3 Day 3L2級實戰(zhàn)——用LoRA微調(diào)一個情感分類模型目標(biāo)在消費(fèi)級GPURTX 3090, 24GB上用LoRA將bert-base-chinese微調(diào)為電商評論情感分類器顯存占用≤12GB。數(shù)據(jù)準(zhǔn)備用開源的chnsenticorp數(shù)據(jù)集中文情感分析正面/負(fù)面/中性git clone https://huggingface.co/datasets/SeohyunHong/chnsenticorp # 取前1000條樣本加快訓(xùn)練 head -n 1000 chnsenticorp/train.json train_mini.jsonLoRA配置關(guān)鍵參數(shù)r8LoRA rank7B模型常用813B用16過大顯存暴增過小效果不佳lora_alpha16縮放因子通常設(shè)為r的2倍lora_dropout0.05防止過擬合但Dropout在LoRA中效果有限0.05足夠biasnone不訓(xùn)練bias項減少參數(shù)量訓(xùn)練命令用Hugging Face Trainerpython run_finetune.py \ --model_name_or_path bert-base-chinese \ --train_file train_mini.json \ --per_device_train_batch_size 16 \ --learning_rate 2e-4 \ --num_train_epochs 3 \ --output_dir ./lora_output \ --report_to none \ --load_best_model_at_end \ --lora_r 8 \ --lora_alpha 16 \ --lora_dropout 0.05 \ --lora_bias none顯存監(jiān)控技巧訓(xùn)練時執(zhí)行watch -n 1 nvidia-smi觀察Memory-Usage。若超12GB立即降低per_device_train_batch_size從16→8→4或增加--gradient_accumulation_steps 4用時間換空間。實操心得LoRA微調(diào)后模型文件夾里會多出adapter_config.json和adapter_model.bin。部署時必須同時加載原始模型和adapter權(quán)重。我曾因忘記peft庫直接from_pretrained()原始模型導(dǎo)致微調(diào)失效——正確做法是PeftModel.from_pretrained(model, ./lora_output)。3.4 Day 4L2級進(jìn)階——構(gòu)建一個RAG問答系統(tǒng)目標(biāo)用LlamaIndex ChromaDB搭建一個基于《三體》小說文本的問答系統(tǒng)支持中文查詢。數(shù)據(jù)處理下載《三體》TXT文本用LlamaIndex切片from llama_index.core import SimpleDirectoryReader, VectorStoreIndex from llama_index.vector_stores.chroma import ChromaVectorStore import chromadb # 加載文本 documents SimpleDirectoryReader(input_files[santi.txt]).load_data() # 切片chunk_size512overlap50 from llama_index.core.node_parser import SentenceSplitter parser SentenceSplitter(chunk_size512, chunk_overlap50) nodes parser.get_nodes_from_documents(documents) # 存入Chroma chroma_client chromadb.PersistentClient(path./chroma_db) chroma_collection chroma_client.create_collection(santi) vector_store ChromaVectorStore(chroma_collectionchroma_collection) index VectorStoreIndex(nodes, vector_storevector_store)檢索增強(qiáng)關(guān)鍵不是“能檢索”而是“檢得準(zhǔn)”。默認(rèn)的similarity_top_k2太粗糙。實測發(fā)現(xiàn)對《三體》中“智子”相關(guān)問題top_k5并加rerank效果更好from llama_index.core.retrievers import VectorIndexRetriever from llama_index.core.query_engine import RetrieverQueryEngine from llama_index.core.postprocessor import SimilarityPostprocessor retriever VectorIndexRetriever(indexindex, similarity_top_k5) query_engine RetrieverQueryEngine( retrieverretriever, node_postprocessors[SimilarityPostprocessor(similarity_cutoff0.7)] ) response query_engine.query(智子是如何干擾人類粒子對撞機(jī)的)性能陷阱ChromaDB默認(rèn)用hnswlib但中文embedding需用all-MiniLM-L6-v2等模型。若用text-embedding-ada-002OpenAI API則需付費(fèi)且延遲高。本地替代方案jinaai/jina-embeddings-v2-base-zh專為中文優(yōu)化。注意RAG效果差90%概率是檢索環(huán)節(jié)問題而非LLM本身。Day 4務(wù)必用query_engine.retrieve(智子)打印出前5個檢索片段人工檢查是否相關(guān)。不相關(guān)換embedding模型或調(diào)整切片大小。3.5 Day 5L3級交付——將RAG服務(wù)封裝為FastAPI接口目標(biāo)把Day 4的RAG系統(tǒng)打包成可被前端調(diào)用的HTTP API并加入基礎(chǔ)監(jiān)控。FastAPI代碼骨架from fastapi import FastAPI, HTTPException from pydantic import BaseModel import time import psutil app FastAPI() class QueryRequest(BaseModel): question: str app.post(/ask) async def ask_question(request: QueryRequest): start_time time.time() try: # 調(diào)用Day 4的query_engine response query_engine.query(request.question) latency time.time() - start_time # 記錄指標(biāo)簡易版 with open(latency.log, a) as f: f.write(f{latency:.3f}\n) return {answer: str(response), latency_ms: int(latency*1000)} except Exception as e: raise HTTPException(status_code500, detailstr(e))生產(chǎn)級加固加超時from starlette.middleware.base import BaseHTTPMiddleware全局設(shè)置timeout30s防DDoSpip install slowapi加limiter.limit(10/minute)日志結(jié)構(gòu)化用structlog替代print()日志含request_id、status_code、latency部署驗證用curl測試curl -X POST http://localhost:8000/ask \ -H Content-Type: application/json \ -d {question:三體人為什么害怕人類}同時開另一個終端tail -f latency.log觀察延遲是否穩(wěn)定。實操心得API返回{answer: ...}看似簡單但生產(chǎn)中必須加content-type: application/json頭否則前端fetch可能解析失敗。我曾因此被前端同學(xué)追著罵了半小時——加一行response.headers[Content-Type] application/json即可解決。3.6 Day 6L3級監(jiān)控——用Prometheus監(jiān)控RAG服務(wù)目標(biāo)讓RAG服務(wù)的延遲、錯誤率、QPS變成可圖表化的數(shù)字而非靠tail -f猜。Prometheus配置在FastAPI中集成prometheus-fastapi-instrumentatorfrom prometheus_fastapi_instrumentator import Instrumentator instrumentator Instrumentator() instrumentator.instrument(app).expose(app)啟動服務(wù)后訪問http://localhost:8000/metrics能看到http_request_duration_seconds_bucket等指標(biāo)。Grafana可視化創(chuàng)建Dashboard關(guān)鍵面板P95延遲histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[1h]))錯誤率rate(http_requests_total{status~5..}[1h]) / rate(http_requests_total[1h])QPSrate(http_requests_total[1h])告警規(guī)則alert.rules當(dāng)P95延遲2s持續(xù)5分鐘觸發(fā)企業(yè)微信告警groups: - name: rag-alerts rules: - alert: RAGHighLatency expr: histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) 2 for: 5m labels: severity: warning annotations: summary: RAG服務(wù)P95延遲過高 description: 當(dāng)前P95延遲{{ $value }}s超過閾值2s注意監(jiān)控不是擺設(shè)。Day 6必須親手配置一次哪怕只監(jiān)控一個指標(biāo)。你會發(fā)現(xiàn)http_request_duration_seconds的bucket邊界如le0.1決定了你能否看到“100ms內(nèi)完成的請求占比”。不設(shè)合理bucket監(jiān)控圖就是一條直線。3.7 Day 7綜合診斷——用真實故障演練鞏固全部概念目標(biāo)模擬一個典型生產(chǎn)故障用前六天學(xué)的概念和工具完成全流程排查。故障場景RAG服務(wù)上線后用戶反饋“回答越來越慢有時超時”。監(jiān)控顯示P95延遲從300ms升至2500mshttp_requests_total{status504}激增chroma_collection_countChroma中向量數(shù)量穩(wěn)定無增長排查路線圖定位層級curl -v http://localhost:8000/ask看是否超時 → 確認(rèn)是API層問題非LLM或Chroma本身檢查依賴netstat -tuln | grep :8000看端口是否被占ps aux | grep uvicorn看進(jìn)程是否僵死分析日志grep timeout logs/app.log→ 發(fā)現(xiàn)大量ReadTimeout: HTTPConnectionPool(hostlocalhost, port8000): Read timed out.關(guān)聯(lián)監(jiān)控查Grafana發(fā)現(xiàn)http_request_duration_seconds_bucket{le1}占比從95%掉到40% → 說明1秒內(nèi)完成的請求銳減深入代碼檢查Day 5的FastAPI代碼發(fā)現(xiàn)query_engine.query()未設(shè)超時 → 加timeout10參數(shù)驗證修復(fù)重啟服務(wù)ab -n 100 -c 10 http://localhost:8000/ask壓測P95回落至320ms最后一課所有概念的價值都在故障時刻兌現(xiàn)。國慶七天不是學(xué)完就結(jié)束而是建立一套肌肉記憶——看到延遲升高本能地去看監(jiān)控、查日志、測依賴、改代碼。這套反應(yīng)鏈比記住100個名詞重要一萬倍。4. 高頻問題速查表技術(shù)人真正在意的12個靈魂拷問4.1 “大模型”到底多大才算“大”顯存和延遲怎么算“大模型”的“大”不是絕對參數(shù)量而是相對于你的硬件和業(yè)務(wù)需求的相對規(guī)模。計算顯存占用的經(jīng)驗公式顯存(MB) ≈ (模型參數(shù)量 × 2字節(jié)) KV Cache內(nèi)存 KV Cache內(nèi)存 ≈ 2 × batch_size × seq_len × num_layers × hidden_size × 2字節(jié)以Qwen2-7B為例參數(shù)量7B × 2字節(jié) 14GBFP16KV Cachebatch_size1, seq_len2048, num_layers32, hidden_size4096≈ 2 × 1 × 2048 × 32 × 4096 × 2 ≈ 1.07GB總計≈15GB需A1024GB或RTX409024GB但若用AWQ 4-bit量化參數(shù)量部分降至7B × 0.5字節(jié) 3.5GB總顯存≈4.6GBRTX309024GB綽綽有余。實操口訣“先算參數(shù)顯存再估KV Cache最后留20%余量。顯存不夠量化優(yōu)先于換小模型。”4.2 “RAG”和“微調(diào)”到底該選哪個選型決策樹數(shù)據(jù)量 1000條且領(lǐng)域高度垂直→ 微調(diào)LoRA效果更穩(wěn)定數(shù)據(jù)量 10萬條且實時更新頻繁→ RAG免訓(xùn)練更新知識庫即可數(shù)據(jù)含大量表格/圖片/公式→ RAG可多模態(tài)檢索微調(diào)難處理非文本業(yè)務(wù)要求100%事實準(zhǔn)確如醫(yī)療、法律→ RAG引用溯源微調(diào)易幻覺我做過對比實驗電商客服場景用1000條售后對話微調(diào)Qwen2-1.5BF10.82用RAGChromaQwen2-0.5BF10.79但RAG能即時接入最新退貨政策PDF微調(diào)需重新訓(xùn)練。注意RAG不是萬能。若檢索召回率50%強(qiáng)行上RAG不如用微調(diào)規(guī)則兜底。4.3 “Agent”真的需要嗎還是過度設(shè)計Agent的價值在于解決多步驟、強(qiáng)狀態(tài)、需工具協(xié)同的任務(wù)。判斷標(biāo)準(zhǔn)? 需要調(diào)用多個API如查天氣→訂機(jī)票→發(fā)郵件通知? 需要根據(jù)中間結(jié)果動態(tài)決策如用戶問“幫我訂張去上海的機(jī)票”Agent需先查航班→選價格→確認(rèn)座位→支付? 任務(wù)有明確終止條件如“生成一份周報” vs “幫我寫周報要包含銷售數(shù)據(jù)、下周計劃、風(fēng)險提示”? 簡單問答“今天北京天氣”? 單一工具調(diào)用“把這段文字翻譯成英文”? 無狀態(tài)任務(wù)“總結(jié)這篇文檔”實操心得我曾用LangChain Agent做會議紀(jì)要生成結(jié)果因工具調(diào)用失敗陷入無限重試。后來改成“LLM生成初稿→規(guī)則提取關(guān)鍵人名/日期→人工審核”效率反升3倍。Agent不是炫技是為了解決真痛點(diǎn)。4.4 “提示工程”到底有沒有用怎么證明有用但價值有天花板。實測數(shù)據(jù)對Qwen2-0.5B優(yōu)化prompt加few-shot、明確格式使JSON輸出準(zhǔn)確率從68%→89%對Qwen2-7B同樣prompt優(yōu)化準(zhǔn)確率僅從92%→94%證明方法AB測試。部署兩個endpoint/api/v1/prompt-basic基礎(chǔ)prompt/api/v1/prompt-optimized優(yōu)化prompt用相同1000條測試集請求統(tǒng)計json.loads()成功率、字段提取準(zhǔn)確率。關(guān)鍵提示工程效果隨LLM能力提升而衰減。不要在GPT-4級別模型上花大力氣調(diào)prompt而在Qwen2-0.5B上值得投入。4.5 “量化”會不會嚴(yán)重?fù)p失效果不會但要看量化類型和任務(wù)AWQ/GPTQ4-bit文本生成、摘要任務(wù)BLEU/ROUGE下降1%可接受FP16→INT8TensorRT對數(shù)學(xué)推理、代碼生成任務(wù)準(zhǔn)確率可能降5-10%動態(tài)量化CPU僅適用于推理訓(xùn)練無效實測Qwen2-1.5B在CMRC2018閱讀理解任務(wù)上FP16EM62.3%, F171.8%AWQ 4-bitEM61.9%, F171.5%GPTQ 4-bitEM62.1%, F171.6%口訣“生成類任務(wù)量化安全推理類任務(wù)謹(jǐn)慎數(shù)學(xué)/代碼任務(wù)優(yōu)先保精度?！?.6 “開源模型”和“商業(yè)API”怎么選決策矩陣維度開源模型Qwen、DeepSeek商業(yè)APIQwen API、Moonshot成本一次性硬件投入長期0成本按token計費(fèi)長期成本高可控性完全可控可審計、可修改黑盒無法debug策略變更不透明延遲自建集群延遲穩(wěn)定500ms網(wǎng)絡(luò)抖動P99延遲可能3s定制化可微調(diào)、可量化、可私有化僅限prompt調(diào)優(yōu)無法改模型適用場景? 內(nèi)部系統(tǒng)、敏感數(shù)據(jù)、高并發(fā)、低延遲要求 → 開源模型? 快速M(fèi)VP、無運(yùn)維能力、小流量、需多模型切換 → 商業(yè)API我的實踐用開源Qwen2-7B做內(nèi)部知識庫問答月省API費(fèi)用$2300用Moonshot API做對外Demo一周上線零運(yùn)維。4.7 “評估”AI效果除了Accuracy還有什么指標(biāo)Accuracy是毒藥。真實場景指標(biāo)業(yè)務(wù)指標(biāo)客服場景的“首次解決率FCR”、電商場景的“推薦點(diǎn)擊率CTR”技術(shù)指標(biāo)Hallucination Rate生成內(nèi)容中虛構(gòu)事實的比例人工抽樣100條標(biāo)注Latency P9595%請求的響應(yīng)時間Token Efficiency每美元生成的有效token數(shù)排除padding、stop token人工評估用Pairwise Comparison讓標(biāo)注員對比A/B模型輸出選更好者注意不要用BLEU評估開放生成。我曾見團(tuán)隊用BLEU0.45的模型上線用戶投訴“答案像機(jī)器人”因為BLEU只看n-gram重疊不管流暢