最近和几个技术团队负责人聊天发现一个普遍现象大家都能用 ChatGPT 写几行代码但真正想把 AI 能力稳定、高效、低成本地集成到现有业务系统里团队却常常卡壳。不是模型效果飘忽不定就是工程链路复杂到难以维护最后要么项目烂尾要么沦为“人工智障”演示。这背后的核心问题是从“会用 AI 工具”到“能交付 AI 系统”之间存在巨大的能力鸿沟。过去半年我深度参与了几个 AI 原生应用的从零到一也踩遍了从模型选型、提示工程、到服务化部署、幻觉处理的每一个坑。今天我想结合这些实战经验为你系统性地拆解一份AI 工程核心技能图谱。这不是一份面面俱到的理论清单而是一张聚焦于“如何让 AI 真正在工程体系里跑起来”的实战地图。如果你满足以下任一情况这篇文章就是为你写的技术负责人或架构师正在规划团队的 AI 能力建设路线。后端/全栈工程师需要将大模型 API 或开源模型集成到产品中。对 AI 应用开发感兴趣但被层出不穷的框架和概念搞得眼花缭乱。本文将围绕一个核心判断展开AI 工程化的关键不在于追求最前沿的模型而在于构建一套可观测、可迭代、可协作的标准化工程体系Harness Engineering。下面我们就从最痛的痛点开始。1. 我们到底在解决什么问题从“玩具”到“工程”的鸿沟很多人对 AI 工程的认知还停留在“调 API、写 Prompt”阶段。这能做出演示原型Demo但离可用的产品Product相差甚远。让我们看几个真实场景场景一效果不稳定你用一个精心设计的 Prompt 让 GPT-4 生成产品推荐文案测试时效果惊艳。上线后随着用户输入变得千奇百怪回复质量急剧下降甚至出现胡言乱语幻觉。你无法定量评估这种下降更不知道如何系统地优化。场景二链路复杂你的应用需要先调用模型 A 理解用户意图再调用搜索引擎 B 获取实时信息最后用模型 C 合成最终回答。这个链路中任何一个环节出错或超时整个服务就不可用。调试时你就像在迷宫里抓 bug。场景三成本失控产品火了API 调用量激增月底账单让你目瞪口呆。你发现很多请求是重复的、无效的或者完全可以用更便宜的模型替代但你没有数据和工具来分析优化。场景四协作低效算法工程师调出的 Prompt交给后端工程师封装成 API。后端看不懂 Prompt 的逻辑算法也不关心服务的稳定性。一旦效果不好双方就开始“踢皮球”。这些问题的根源是缺乏工程化的思维和工具。传统的软件工程有成熟的开发流程、测试框架、监控告警和 DevOps 体系。而 AI特别是大模型应用引入了新的不确定性非确定性输出、新的组件提示词、向量数据库、新的评估方式难以用通过/失败衡量。AI 工程的核心任务就是为这种新的研发范式建立一套同样严谨、高效的支撑体系。这就是Harness Engineering驾驭工程理念的价值所在。它不只是一个新名词其核心思想是像驾驭Harness烈马一样通过缰绳工具和流程来控制 AI 能力的巨大潜能和不确定性使其服务于确定性的业务目标。接下来我们将技能图谱具象化为可学习的模块。2. AI 工程技能全景图四大核心支柱基于实战我将 AI 工程的核心技能归纳为四大支柱。这张图谱不是让你全部精通而是帮你建立体系认知明确学习路径。AI 工程能力四大支柱 ├── 1. 基础层大模型原理与交互 │ ├── 模型工作原理Transformer, Tokenization │ ├── 主流模型家族与选型GPT, Claude, 开源模型 │ ├── 核心交互范式Prompt Engineering Function Calling │ └── 成本与性能权衡 ├── 2. 架构层应用模式与系统设计 │ ├── 应用架构模式Agent, RAG, Fine-tuning │ ├── 数据流设计上下文管理、工具调用、记忆机制 │ ├── 非功能设计延迟、吞吐、容错、降级 │ └── 安全与合规内容过滤、数据隐私、审计 ├── 3. 工程层开发、测试与部署 │ ├── 开发框架LangChain, LlamaIndex, Semantic Kernel │ ├── 评估体系单元测试、集成测试、评估指标相关性、忠实度 │ ├── 运维部署模型服务化TGI, vLLM、API网关、监控 │ └── 持续迭代A/B测试、数据反馈闭环、Prompt版本管理 └── 4. 设施层工具链与团队协作 ├── 向量数据库Chroma, Pinecone, Weaviate ├── 实验跟踪MLflow, Weights Biases, Prompt工具 ├── 团队协作Prompt即代码、知识库、评审流程 └── 成本治理用量分析、预算控制、优化策略下面我们深入每一层看看具体要掌握什么以及如何开始实践。3. 基础层不只是调用 API这一层是地基。误区在于认为“会用 OpenAI SDK 就是会 AI 开发了”。其实你需要理解背后的“为什么”。3.1 理解模型的工作原理无需深究数学你不需要推导 Transformer 的每一行公式但必须理解几个关键概念Token词元模型处理文本的基本单位不是字符也不是单词。中文里一个词可能被分成多个 Token。这直接关系到 API 调用成本按 Token 计费和上下文长度限制。上下文窗口Context Window模型能“记住”的单次对话最大 Token 数。超出部分会被丢弃。设计系统时必须考虑如何精简或分块输入。温度Temperature和 Top-p控制模型输出随机性的参数。Temperature 高回答更创意多变Temperature 低回答更稳定一致。产品环境通常使用较低温度。3.2 Prompt Engineering 的本质是“任务说明书”Prompt Engineering 不是“咒语学”而是清晰、无歧义地定义任务。一个结构化的 Prompt 通常包含角色Role明确模型的身份。“你是一个资深的 Java 技术专家。”任务Task清晰说明要做什么。“请将以下自然语言描述转换为符合阿里巴巴 Java 开发规范的代码。”上下文Context提供必要的背景信息。“我们正在开发一个电商订单系统。”示例Examples提供少量示例Few-shot Learning让模型快速理解格式和要求。格式Format指定输出格式。“请以 JSON 格式输出包含className,fields,methods三个键。”约束Constraints列出限制条件。“不要使用任何第三方库。方法名必须使用驼峰命名法。”示例一个代码生成的 Prompt 模板# 这不是代码而是一个 Prompt 模板的示例 SYSTEM_PROMPT 你是一个经验丰富的{language}开发工程师精通{company}_code_style开发规范。 你的任务是根据用户的需求生成高质量、可运行、符合规范的代码。 请严格按照以下要求执行 1. 代码必须包含必要的注释。 2. 优先使用标准库如需第三方库必须明确说明。 3. 输出格式首先用一句话说明实现思路然后给出完整代码块。 USER_REQUEST 帮我写一个Python函数接收一个文件路径读取该文件的MD5值。 # 实际调用时将 SYSTEM_PROMPT 和 USER_REQUEST 组合发送给模型3.3 模型选型没有最好只有最合适不要盲目追求 GPT-4。根据场景选择复杂推理、高精度任务GPT-4、Claude 3 Opus。成本高但效果好。常规对话、内容生成GPT-3.5-Turbo、Claude 3 Haiku。性价比之选。对数据隐私有要求/需要微调开源模型Llama 3, Qwen, DeepSeek。需要自建基础设施但控制力强。特定领域代码CodeLlama, DeepSeek-Coder。关键动作建立自己的模型评测基准。对相同的测试集如20个业务典型问题用不同模型测试记录效果、延迟和成本。数据驱动决策。4. 架构层设计可维护的 AI 应用当任务超出一次简单的问答时就需要设计应用架构。主要有三种模式4.1 三种核心架构模式RAG检索增强生成解决模型“知识陈旧”和“幻觉”问题。流程用户提问 → 从你的知识库向量数据库检索相关文档 → 将文档作为上下文注入 Prompt → 模型生成基于已知信息的回答。适用场景智能客服、企业知识库、基于文档的问答。技术栈文本分块Chunking→ 向量化Embedding Model→ 向量数据库Vector DB→ 检索器Retriever。Agents智能体让模型具备使用工具、执行多步骤任务的能力。核心思想模型作为“大脑”可以规划、调用各种“工具”函数如搜索网络、查询数据库、执行代码。流程模型接收目标 → 思考计划 → 调用工具 → 观察结果 → 继续思考或输出最终结果。适用场景自动化工作流、复杂问题拆解、动态交互系统。关键挑战规划失败、工具调用循环、高延迟。Fine-tuning微调用自己的数据训练模型让它更“懂你”。与 Prompt Engineering 的区别Prompt 是每次告诉模型怎么做微调是改变模型本身的“性格”和“知识”。适用场景风格迁移让模型学会你的写作风格、复杂格式输出稳定生成特定 JSON、领域知识深度固化。成本考量需要高质量的标注数据、训练计算资源。对于大多数应用RAG 优质 Prompt 是更快的起点。4.2 系统设计要点以 RAG 系统为例设计一个简单的 RAG 系统你需要考虑以下组件和流程graph TD A[原始文档brPDF/Word/TXT] -- B[文档加载与解析brPyPDF2, docx] B -- C[文本分块brRecursiveCharacterTextSplitter] C -- D[向量化brEmbedding Modelbrtext-embedding-3-small] D -- E[存储至向量数据库brChromaDB] F[用户提问] -- G[问题向量化] G -- H[向量相似度检索brTop-K相关片段] H -- I[构建增强Promptbr上下文问题] I -- J[大模型生成回答brGPT-4/Claude] J -- K[最终答案] E -- H对应的技术实现关键步骤文档处理与向量化# 使用 LangChain 和 OpenAI Embeddings from langchain_community.document_loaders import PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_chroma import Chroma # 1. 加载文档 loader PyPDFLoader(path/to/your/document.pdf) documents loader.load() # 2. 分割文本 text_splitter RecursiveCharacterTextSplitter( chunk_size1000, # 每个块的大小 chunk_overlap200, # 块之间的重叠避免割裂语义 separators[\n\n, \n, 。, , , , , , ] ) chunks text_splitter.split_documents(documents) # 3. 生成向量并存入数据库 embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db # 本地持久化 )检索与生成from langchain_openai import ChatOpenAI from langchain.chains import RetrievalQA # 4. 创建检索器 retriever vectorstore.as_retriever(search_kwargs{k: 4}) # 检索最相关的4个片段 # 5. 创建 LLM llm ChatOpenAI(modelgpt-3.5-turbo, temperature0) # 6. 创建 RAG 链 qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, # 将检索到的所有内容“塞”进Prompt retrieverretriever, return_source_documentsTrue, # 返回来源便于追溯 chain_type_kwargs{ prompt: PROMPT # 可以传入自定义的Prompt模板控制回答格式 } ) # 7. 提问 result qa_chain.invoke({query: 请问本文档中提到的AI工程核心技能是什么}) print(result[result]) print(来源文档, result[source_documents])这个流程看似简单但每个环节都有“坑”分块大小太大检索不精准太小上下文不完整。Embedding 模型不同模型对同一文本的向量表示差异很大直接影响检索质量。检索策略除了相似度检索还可以结合关键词检索Hybrid Search、元数据过滤等。Prompt 设计如何将检索到的片段有效地组织成模型能理解的上下文是效果的关键。5. 工程层从脚本到服务从手动到自动这是区分“爱好者”和“工程师”的关键层。核心是建立标准化的开发运维流程。5.1 开发框架选型不要重复造轮子LangChain/LangGraph目前最流行的框架模块丰富社区活跃。但抽象层次高学习曲线陡峭有时感觉“为了用框架而用框架”。适合快速原型和复杂Agent工作流。LlamaIndex专注于 RAG 场景在数据连接、索引和检索方面非常强大API 相对更直观。如果你的核心是 RAGLlamaIndex 可能是更直接的选择。Semantic Kernel (微软)与 .NET 生态结合紧密强调规划Planner能力。适合微软技术栈团队。纯 SDK 自定义编排对于简单应用如封装一个聊天接口直接使用 OpenAI SDK 或开源模型库搭配 FastAPI 等 Web 框架可能是最轻量、最可控的方案。建议从简单需求开始先尝试直接用 SDK。当需要串联多个步骤、管理复杂状态时再引入框架。理解框架解决的问题比会用框架更重要。5.2 测试如何测试一个不确定的系统传统软件的单元测试输入 A期望输出 B对 AI 系统常常失效。我们需要新的测试范式组件测试检索测试给定查询检查检索到的文档是否相关。Prompt 测试固定输入和上下文检查模型输出是否稳定、符合格式。# 一个简单的Prompt测试示例 def test_code_generation_prompt(): prompt f{SYSTEM_PROMPT}\n用户请求{USER_REQUEST} # 使用一个固定的、轻量级的模型如 gpt-3.5-turbo进行测试 response call_llm(prompt, modelgpt-3.5-turbo, temperature0) # 断言响应包含代码块 assert python in response # 断言响应包含“MD5”关键词 assert MD5 in response.upper() # 更复杂的可以用规则或模型来评估代码语法是否正确集成测试与评估指标端到端测试模拟真实用户流。评估指标相关性Relevance回答是否切题可以用另一个模型评判员来打分。忠实度Faithfulness回答是否严格基于提供的上下文防止幻觉。毒性Toxicity回答是否包含有害内容。工具可以使用RAGAS、TruLens、LangSmith等专门评估框架。非功能测试延迟、吞吐量、并发、成本。5.3 部署与监控让服务稳定运行模型服务化云 API最简单但依赖网络成本随用量增长。自托管开源模型使用TGI(Text Generation Inference)、vLLM等高性能推理服务器。它们支持连续批处理、PagedAttention 等优化能极大提升吞吐量。# 使用 vLLM 快速启动一个开源模型服务 # 安装pip install vllm # 启动服务 vllm serve meta-llama/Meta-Llama-3-8B-Instruct # 客户端调用 from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keytoken-abc123 ) response client.chat.completions.create( modelmeta-llama/Meta-Llama-3-8B-Instruct, messages[{role: user, content: Hello!}] )应用部署将你的 AI 应用如 FastAPI 服务容器化Docker使用 Kubernetes 或云服务进行编排。监控与可观测性核心指标请求量、响应延迟、Token 消耗、错误率。业务指标用户满意度可结合反馈按钮、任务完成率。成本监控按模型、按接口、按用户维度统计 Token 消耗设置预算告警。链路追踪记录每个请求的完整处理过程包括调用了哪些工具、检索了哪些文档、模型思考过程如果支持等。这是调试复杂 Agent 的救命稻草。6. 设施层与团队协作规模化基石个人英雄主义无法支撑企业级 AI 应用。需要建立团队协作规范和基础设施。6.1 Prompt 即代码与版本管理Prompt 是 AI 应用的核心逻辑必须像管理代码一样管理它。存储将 Prompt 模板存储在 Git 仓库中如.prompt文件或代码中的字符串常量。版本化每次对 Prompt 的修改都应提交并附上修改原因和测试结果。代码审查像审查代码一样审查 Prompt 的清晰度、安全性和潜在偏见。环境隔离开发、测试、生产环境使用不同的 Prompt 版本和模型 API Key。6.2 实验跟踪与管理AI 开发充满实验性。必须系统化地记录实验避免重复劳动和结果丢失。记录什么Prompt 内容、模型参数、输入数据、输出结果、评估分数、成本、运行环境。工具可以使用MLflow、Weights Biases或专门的 Prompt 管理工具如PromptHub。流程每个实验都有一个唯一 ID便于复现和对比。6.3 成本治理与优化AI 成本可能是指数级增长的。必须从一开始就建立成本意识。预算与告警为每个项目/环境设置月度预算接近时自动告警。用量分析分析哪些用户、哪些功能消耗了最多的 Token。是否存在滥用或无效调用优化策略缓存对相同或相似的查询结果进行缓存。模型阶梯简单任务用便宜模型如 GPT-3.5复杂任务再用强模型如 GPT-4。精简输入输出优化 Prompt减少不必要的上下文让模型输出更简洁。异步与批处理非实时任务可以批量处理利用模型的并行能力。7. 实战演练构建一个简单的技术文档问答助手让我们综合运用上述技能构建一个最小可用的 RAG 问答助手。假设我们有一些内部技术文档Markdown 格式。项目结构tech_doc_qa/ ├── app.py # FastAPI 主应用 ├── core/ │ ├── config.py # 配置管理 │ ├── document_processor.py # 文档处理 │ └── qa_chain.py # RAG 链核心逻辑 ├── data/ │ └── documents/ # 存放原始文档 ├── prompts/ # Prompt 模板目录 │ └── qa_prompt.md ├── requirements.txt └── README.md1. 环境准备与依赖 (requirements.txt)fastapi0.104.1 uvicorn[standard]0.24.0 langchain0.1.0 langchain-openai0.0.2 langchain-chroma0.1.0 chromadb0.4.22 openai1.6.1 python-dotenv1.0.0 pypdf23.0.1 # 用于PDF如果是MD文件可不用2. 配置管理 (core/config.py)import os from dotenv import load_dotenv load_dotenv() class Settings: OPENAI_API_KEY os.getenv(OPENAI_API_KEY) OPENAI_BASE_URL os.getenv(OPENAI_BASE_URL, https://api.openai.com/v1) EMBEDDING_MODEL os.getenv(EMBEDDING_MODEL, text-embedding-3-small) LLM_MODEL os.getenv(LLM_MODEL, gpt-3.5-turbo) VECTOR_DB_PATH os.getenv(VECTOR_DB_PATH, ./chroma_db) DOCUMENT_DIR os.getenv(DOCUMENT_DIR, ./data/documents) settings Settings()3. 文档处理与向量化 (core/document_processor.py)import os from langchain_community.document_loaders import DirectoryLoader, TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_chroma import Chroma from .config import settings class DocumentProcessor: def __init__(self): self.embeddings OpenAIEmbeddings( modelsettings.EMBEDDING_MODEL, openai_api_keysettings.OPENAI_API_KEY, base_urlsettings.OPENAI_BASE_URL ) self.text_splitter RecursiveCharacterTextSplitter( chunk_size800, chunk_overlap150, separators[\n## , \n### , \n\n, \n, 。, , , , , , ] ) def load_and_split_documents(self, directory_path: str): 加载并分割文档 # 加载所有.md文件 loader DirectoryLoader( directory_path, glob**/*.md, loader_clsTextLoader, loader_kwargs{autodetect_encoding: True} ) raw_docs loader.load() print(f已加载 {len(raw_docs)} 个文档) # 分割文档 all_splits self.text_splitter.split_documents(raw_docs) print(f分割为 {len(all_splits)} 个文本块) return all_splits def create_or_update_vectorstore(self, documents, persist_directory: str): 创建或更新向量数据库 vectorstore Chroma.from_documents( documentsdocuments, embeddingself.embeddings, persist_directorypersist_directory ) print(f向量数据库已保存至 {persist_directory}) return vectorstore def get_retriever(self, persist_directory: str, search_k4): 获取检索器 vectorstore Chroma( persist_directorypersist_directory, embedding_functionself.embeddings ) return vectorstore.as_retriever(search_kwargs{k: search_k})4. Prompt 模板 (prompts/qa_prompt.md)你是一个专业的技术文档助手负责回答关于公司内部技术栈、架构和开发规范的问题。 请严格根据以下提供的上下文信息来回答问题。如果上下文中有明确答案请基于上下文回答。如果上下文信息不足或未提及请直接说“根据现有资料我无法回答这个问题”不要编造信息。 上下文信息 {context} 用户问题{question} 请用清晰、有条理的中文给出回答。如果涉及代码请使用正确的代码块格式。5. RAG 链核心逻辑 (core/qa_chain.py)from langchain_openai import ChatOpenAI from langchain.prompts import PromptTemplate from langchain.chains import RetrievalQA from pathlib import Path from .config import settings from .document_processor import DocumentProcessor class QAChatChain: def __init__(self): self.processor DocumentProcessor() self.llm ChatOpenAI( modelsettings.LLM_MODEL, temperature0.1, # 低温度保证回答稳定 openai_api_keysettings.OPENAI_API_KEY, base_urlsettings.OPENAI_BASE_URL ) # 读取Prompt模板 prompt_template_path Path(__file__).parent.parent / prompts / qa_prompt.md with open(prompt_template_path, r, encodingutf-8) as f: prompt_template f.read() self.qa_prompt PromptTemplate( templateprompt_template, input_variables[context, question] ) # 初始化检索器假设向量库已存在 self.retriever self.processor.get_retriever( persist_directorysettings.VECTOR_DB_PATH, search_k4 ) # 创建链 self.qa_chain RetrievalQA.from_chain_type( llmself.llm, chain_typestuff, retrieverself.retriever, chain_type_kwargs{prompt: self.qa_prompt}, return_source_documentsTrue ) def query(self, question: str): 执行查询 result self.qa_chain.invoke({query: question}) return { answer: result[result], sources: [doc.metadata.get(source, Unknown) for doc in result[source_documents]] } def rebuild_vectorstore(self): 重新构建向量数据库首次运行或文档更新后调用 documents self.processor.load_and_split_documents(settings.DOCUMENT_DIR) self.processor.create_or_update_vectorstore(documents, settings.VECTOR_DB_PATH) print(向量数据库重建完成。)6. FastAPI 主应用 (app.py)from fastapi import FastAPI, HTTPException from pydantic import BaseModel from core.qa_chain import QAChatChain import uvicorn app FastAPI(title技术文档问答助手 API) qa_chain QAChatChain() class QueryRequest(BaseModel): question: str class QueryResponse(BaseModel): answer: str sources: list[str] app.post(/query, response_modelQueryResponse) async def query_document(request: QueryRequest): try: result qa_chain.query(request.question) return QueryResponse(**result) except Exception as e: raise HTTPException(status_code500, detailf查询失败: {str(e)}) app.post(/rebuild-index) async def rebuild_index(): 手动触发重建向量索引需要权限控制 try: qa_chain.rebuild_vectorstore() return {message: 索引重建任务已启动} except Exception as e: raise HTTPException(status_code500, detailf重建失败: {str(e)}) app.get(/health) async def health_check(): return {status: healthy} if __name__ __main__: # 首次运行需要先构建向量库 # qa_chain.rebuild_vectorstore() uvicorn.run(app, host0.0.0.0, port8000)7. 运行与测试将你的 Markdown 文档放入data/documents/目录。在项目根目录创建.env文件配置你的 OpenAI API Key 等信息。安装依赖pip install -r requirements.txt。首次运行需要初始化向量库取消app.py中qa_chain.rebuild_vectorstore()的注释运行一次python app.py。完成后再次注释掉。启动服务python app.py。使用 curl 或 Postman 测试curl -X POST http://localhost:8000/query \ -H Content-Type: application/json \ -d {question: 我们项目的后端主要使用什么编程语言}这个示例涵盖了配置管理、文档处理、Prompt 模板化、服务封装等关键工程实践。你可以在此基础上添加认证、限流、更复杂的检索策略如重排序和监控。8. 常见问题与排查指南在实践过程中你一定会遇到各种问题。以下是一些典型问题及排查思路问题现象可能原因排查步骤解决方案回答质量差答非所问1. 检索到的文档不相关2. Prompt 指令不清晰3. 上下文过长或过短1. 检查向量库查询时打印出检索到的源文档看是否相关。2. 检查分块策略块大小是否合适重叠是否足够3. 简化并强化 Prompt明确指令加入“不知道就说不知道”的约束。1. 优化 Embedding 模型或尝试混合检索。2. 调整分块参数或尝试不同的分块方法按标题、按句子。3. 使用更结构化的 Prompt 模板加入 Few-shot 示例。服务响应慢1. Embedding 或 LLM API 调用慢2. 检索过程慢向量数据库查询3. 网络延迟1. 在代码中添加计时器定位慢的环节。2. 检查向量数据库的索引是否建立如 Chroma 的持久化文件。3. 检查网络连接和 API 端点。1. 考虑缓存 Embedding 结果。2. 对向量数据库进行性能调优或更换为更高效的数据库如 PGVector 的索引。3. 对于自托管模型使用 vLLM 等高性能推理框架。消耗 Token 过多成本高1. 输入上下文太长2. 重复调用相同内容3. 模型选型过强1. 统计每次请求的输入/输出 Token 数。2. 分析日志看是否有重复或无效查询。1. 优化检索只返回最相关的片段减小 K 值。2. 实现查询结果缓存。3. 对简单查询降级使用更便宜的模型。出现“幻觉”编造信息1. 检索到的上下文不足或噪声大2. 模型 Temperature 参数过高3. Prompt 未做限制1. 检查检索到的源文档是否包含了足够信息。2. 检查模型参数。1. 在 Prompt 中加强指令“必须严格基于上下文上下文未提及则明确告知无法回答”。2. 降低 Temperature 值如设为 0。3. 在最终输出前增加一个“事实核查”步骤让模型引用来源。向量库更新后检索效果变差1. 新文档的 Embedding 与旧文档分布差异大2. 分块策略不一致1. 对比新旧文档的向量相似度。2. 检查处理新文档的代码流程是否与旧文档一致。1. 确保使用完全相同的 Embedding 模型和参数。2. 重建整个向量库而不是增量添加以保证一致性。Agent 陷入循环或无法完成任务1. 工具定义不清晰2. 规划Planning能力不足3. 缺少超时或最大步数限制1. 打印出 Agent 的思考过程如果框架支持。2. 检查工具函数的输入输出是否符合预期。1. 为工具提供更详细、更精确的描述。2. 采用更强大的规划模型如 GPT-4。3. 在代码中强制设置最大迭代次数和超时时间。9. 最佳实践与进阶方向当你跑通基本流程后以下实践能让你的系统更健壮、更高效配置外部化所有模型参数、API Key、路径等都应通过环境变量或配置文件管理绝不能硬编码在代码中。实现异步处理对于耗时的 Embedding 生成或模型调用使用异步asyncio来提高服务的并发能力。引入重排序Re-ranking在向量检索初步结果后使用一个更精细的交叉编码器模型对结果进行重排序可以显著提升 Top-1 的准确率。建立评估流水线定期用一批标准问题测试你的系统记录回答质量和成本变化驱动持续优化。设计降级策略当核心模型服务不可用时是否有备选方案如切换到更便宜的模型、返回缓存答案、提示用户稍后再试。关注安全与合规输入输出过滤对用户输入和模型输出进行内容安全过滤。数据隐私确保敏感信息不上传到不可控的第三方 API。审计日志记录所有查询和回答便于追溯和审计。AI 工程领域仍在快速演进新的框架、模型和范式不断涌现。保持学习但更要保持批判性思维新技术是否真的解决了你的核心痛点不要为了技术而技术。这张技能图谱的最终目的是帮助你建立一套属于自己的、能够持续交付价值的 AI 应用工程方法论。从解决一个具体的、小规模的问题开始实践、迭代、扩展这才是驾驭 AI 浪潮最可靠的路径。