1. 从零搭建AI工程能力一个后端老兵的踩坑与复盘ai-engineering-from-scratch这个标题第一次看到的时候我愣了一下。不是因为陌生恰恰相反——过去两年里我身边至少有七八个后端、前端甚至运维的朋友问过我类似的问题我想转AI工程但不知道从哪下手是不是得先把线性代数重新学一遍这个项目标题背后要解决的核心问题其实很明确一个没有机器学习背景的普通开发者如何从零开始构建一套能真正落地干活的AI工程能力体系。注意是AI工程不是AI研究。这两者之间的差别比很多人想象的要大得多。AI工程的核心不是推导反向传播公式也不是手撸Transformer。它的核心是把已有的模型能力通过工程手段稳定、高效、可维护地交付到业务场景中去。这包括数据处理管线的搭建、模型服务的部署与扩缩容、推理性能的优化、提示词的管理与版本控制、评测体系的建立、成本控制等等。这些事情一个有过后端开发经验的人其实上手比纯算法背景的人还要快。这篇文章适合谁看如果你是后端、全栈、数据工程师想系统性地补齐AI工程能力或者你是刚入行的算法工程师发现学校教的东西和实际工作差距很大再或者你是技术负责人想给团队规划一条从零到一的AI工程学习路径——那这篇内容应该能给你一些直接能用的参考。我自己的背景是后端开发做了六年微服务架构两年前开始系统性地接触AI工程。踩过的坑不算少从环境配置到模型部署从提示词管理到线上推理的延迟优化几乎每个环节都交过学费。下面我把整个从零搭建的过程拆开来讲尽量把每一步的为什么说清楚让你少走弯路。2. 整体学习路径设计与技术选型思路2.1 为什么不能按传统ML课程的路子走市面上大部分AI学习资源走的是机器学习导论→深度学习→NLP/CV→大模型这条线。这条路本身没问题但它的目标函数是培养研究者不是工程师。你会花大量时间在数学推导、论文复现、模型结构创新上而这些在实际AI工程工作中占比可能不到10%。我试过按这条路走了三个月学完了吴恩达的机器学习课程啃了一半《深度学习》花书结果发现面对一个把公司客服系统接入大模型的需求我依然不知道从哪下手。因为真正的工程问题——怎么管理API密钥、怎么处理超时重试、怎么设计提示词模板、怎么评估输出质量、怎么控制token成本——这些课程里根本不讲。所以我的建议是如果你目标是AI工程就不要从数学开始从跑通一个最小可用系统开始。先建立工程直觉再按需补理论。这跟学Web开发是一个道理——你不会先学TCP/IP协议栈再写第一个HTML页面。2.2 分阶段的能力建设路线我把整个学习路径分成四个阶段每个阶段都有明确的产出物避免学了很多但什么都做不出来的困境。第一阶段基础环境与API调用能力1-2周这个阶段的目标很简单能熟练调用主流大模型的API理解请求/响应的基本结构能处理常见的错误情况。产出物是一个命令行小工具比如一个能读取本地文档并回答问题的脚本。第二阶段应用开发框架与RAG基础3-4周掌握至少一个AI应用开发框架理解检索增强生成RAG的基本原理和实现方式。产出物是一个能基于私有知识库问答的Web应用。第三阶段工程化与生产部署4-6周这个阶段是区分玩具项目和生产系统的关键。你需要掌握提示词版本管理、输出质量评测、推理性能优化、成本监控、日志与可观测性。产出物是一个有完整监控和评测体系的AI服务。第四阶段进阶与专项深入持续根据你的业务方向选择深入模型微调、Agent系统、多模态应用、推理加速等。2.3 技术选型的几个关键决策在工具选型上我踩过一些坑这里直接给结论和理由。编程语言Python为主但不要放弃你原有的语言Python是AI工程的事实标准生态最完善。但如果你原本是Java或Go背景不要觉得需要完全转语言。很多生产系统的架构是Python做模型推理服务Java/Go做业务编排层。我现在的做法就是Python写推理和数据处理Go写API网关和业务逻辑。开发框架LangChain vs LlamaIndex vs 裸写我的建议是先用裸写再用框架。裸写的意思是直接用OpenAI SDK或类似的库自己管理提示词、上下文、工具调用。这样你能真正理解每一步在发生什么。等你把RAG的每个环节都手写过一遍之后再用LangChain或LlamaIndex去提效这时候你就能判断哪些抽象是合理的哪些是过度封装。我见过太多人一上来就用LangChain结果出了问题完全不知道从哪排查因为框架把太多细节藏起来了。向量数据库从最简单的开始新手最容易犯的错是一上来就上Milvus或Weaviate这种重型向量数据库。实际上如果你的数据量在百万级以下用FAISS或者甚至PostgreSQL的pgvector扩展就完全够了。我第一个RAG项目用的是Chroma本地文件存储零配置跑起来再说。等数据量真的上来了再迁移迁移成本远比你想象的低。模型选择不要一上来就追求最强模型GPT-4级别的模型确实强但成本也高。实际工程中大量任务用中小模型就能做好。我的策略是先用最强模型跑通流程、建立评测基线然后逐步降级到更便宜的模型看效果损失是否可接受。很多时候一个精心设计的提示词加上小模型效果比粗糙提示词加大模型还好。3. 核心环节拆解与实操要点3.1 环境搭建比你想象的简单但有几个坑AI工程的环境搭建其实比传统后端开发简单因为大部分工作是通过API完成的不需要本地GPU。但有几个坑我必须提前说。Python环境管理不要用系统自带的Python。用pyenv或conda管理多版本用venv或poetry管理项目依赖。我推荐pyenv poetry的组合前者管Python版本后者管包依赖。# 安装pyenvmacOS/Linux curl https://pyenv.run | bash # 安装指定Python版本 pyenv install 3.11.6 pyenv global 3.11.6 # 项目初始化 mkdir ai-engineering-lab cd ai-engineering-lab poetry init poetry add openai tiktoken python-dotenv为什么强调版本管理因为AI领域的库更新极快不同项目依赖的版本经常冲突。我有个项目因为transformers版本不对排查了整整一个下午。API密钥管理这是新手最容易忽视的安全问题。绝对不要把API密钥硬编码在代码里也不要提交到Git仓库。用.env文件加python-dotenv管理并且把.env加入.gitignore。# config.py import os from dotenv import load_dotenv load_dotenv() OPENAI_API_KEY os.getenv(OPENAI_API_KEY) if not OPENAI_API_KEY: raise ValueError(OPENAI_API_KEY not set in environment)注意即使是在个人项目里也要养成密钥管理的习惯。我见过有人把密钥推到公开仓库几分钟内就被扫到并盗用账单直接飙到几百美元。网络与代理配置调用海外模型API时网络稳定性是个现实问题。我的做法是在代码层面做好超时和重试而不是依赖网络层面的方案。from openai import OpenAI import httpx client OpenAI( api_keyOPENAI_API_KEY, timeouthttpx.Timeout(30.0, connect5.0), max_retries3 )超时设置很关键。连接超时设短一点5秒读取超时设长一点30秒因为大模型生成响应本身就需要时间。重试次数设3次配合指数退避。3.2 提示词工程不是玄学是工程提示词工程经常被神秘化好像是什么独门秘籍。其实它本质上就是用自然语言做编程有章法可循。结构化提示词模板我习惯把提示词拆成几个固定部分角色定义、任务描述、输入数据、输出格式、约束条件。这样便于管理和复用。PROMPT_TEMPLATE 你是一个{role}。 ## 任务 {task} ## 输入 {input_data} ## 输出格式 {output_format} ## 约束 {constraints} 为什么要这么拆因为当输出效果不好时你能快速定位是哪个部分的问题。是角色定义不清晰还是输出格式没约束好如果提示词是一大段散文排查起来就很痛苦。Few-shot示例的选择给示例不是越多越好。我的经验是2-3个高质量示例覆盖边界情况比10个相似示例效果好。而且示例的顺序有影响把最典型的放在最后因为模型对靠近生成位置的上下文更敏感。提示词的版本管理这是很多个人项目忽视的环节。提示词应该像代码一样管理存在文件里用Git追踪每次修改记录原因和效果变化。prompts/ qa_system/ v1_basic.txt v2_with_citation.txt v3_strict_format.txt CHANGELOG.mdCHANGELOG里记录每次修改的动机和评测结果。这样当线上效果波动时你能快速回滚到之前的版本。3.3 RAG系统的核心检索质量决定一切RAG检索增强生成是当前AI工程最核心的应用模式。但很多人把精力花在生成端忽视了检索端。实际上RAG系统效果的上限由检索质量决定。文档切分策略切分不是简单地按固定字数切。我试过几种策略效果最好的是按语义边界切分配合重叠窗口。from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap100, separators[\n\n, \n, 。, , , ., , ] )chunk_size设500个字符左右overlap设100。为什么太小了语义不完整太大了检索精度下降。overlap是为了避免关键信息刚好被切在边界上。Embedding模型的选择不要盲目追求最大的embedding模型。我对比过几个常用模型在中文场景下BGE系列和M3E系列性价比很高。关键是embedding模型必须和你的业务语料匹配。通用模型在专业领域比如医疗、法律效果会打折扣。检索策略向量检索不够要加关键词检索纯向量检索有个问题对精确匹配不敏感。比如用户搜GPT-4的上下文窗口是多少向量检索可能返回一堆关于大模型上下文的泛泛内容而漏掉精确提到GPT-4和128k的文档。我的做法是混合检索向量检索 BM25关键词检索然后用RRF倒数排名融合合并结果。def hybrid_search(query, vector_store, bm25_index, top_k5): vector_results vector_store.search(query, top_ktop_k*2) bm25_results bm25_index.search(query, top_ktop_k*2) # RRF融合 scores {} for rank, doc in enumerate(vector_results): scores[doc.id] scores.get(doc.id, 0) 1/(60 rank) for rank, doc in enumerate(bm25_results): scores[doc.id] scores.get(doc.id, 0) 1/(60 rank) sorted_docs sorted(scores.items(), keylambda x: x[1], reverseTrue) return [doc_id for doc_id, _ in sorted_docs[:top_k]]这个RRF的常数60是原论文推荐的实测下来确实比简单加权求和稳定。重排序Rerank检索出候选文档后用一个交叉编码器做重排序能显著提升精度。我常用的是BGE-reranker部署简单效果提升明显。代价是增加一点延迟但在大多数场景下值得。4. 完整实操流程从零搭建一个可用的RAG问答系统4.1 项目结构与依赖先看整体结构这样你心里有个全局图。rag-qa-system/ ├── config/ │ ├── settings.py │ └── prompts/ │ └── qa_v1.txt ├── data/ │ ├── raw/ # 原始文档 │ └── processed/ # 处理后的chunk ├── src/ │ ├── ingestion/ # 文档摄入 │ │ ├── loader.py │ │ ├── splitter.py │ │ └── embedder.py │ ├── retrieval/ # 检索 │ │ ├── vector_store.py │ │ ├── bm25.py │ │ └── hybrid.py │ ├── generation/ # 生成 │ │ └── qa_chain.py │ └── evaluation/ # 评测 │ └── evaluator.py ├── tests/ ├── pyproject.toml └── README.md依赖清单[tool.poetry.dependencies] python ^3.11 openai ^1.10.0 chromadb ^0.4.22 rank-bm25 ^0.2.2 sentence-transformers ^2.3.0 pypdf ^4.0.0 python-dotenv ^1.0.0 tiktoken ^0.6.04.2 文档摄入管线文档摄入分三步加载、切分、向量化。# src/ingestion/loader.py from pathlib import Path from pypdf import PdfReader def load_documents(data_dir: str) - list[dict]: docs [] for path in Path(data_dir).rglob(*): if path.suffix .pdf: reader PdfReader(path) text \n.join(page.extract_text() for page in reader.pages) docs.append({source: str(path), text: text}) elif path.suffix in (.md, .txt): text path.read_text(encodingutf-8) docs.append({source: str(path), text: text}) return docs切分时保留元数据很重要这样生成回答时能标注来源。# src/ingestion/splitter.py from langchain.text_splitter import RecursiveCharacterTextSplitter def split_documents(docs: list[dict], chunk_size500, overlap100): splitter RecursiveCharacterTextSplitter( chunk_sizechunk_size, chunk_overlapoverlap, separators[\n\n, \n, 。, , , ., , ] ) chunks [] for doc in docs: for i, chunk_text in enumerate(splitter.split_text(doc[text])): chunks.append({ id: f{doc[source]}::{i}, text: chunk_text, source: doc[source], chunk_index: i }) return chunks向量化用sentence-transformers本地跑不花钱。# src/ingestion/embedder.py from sentence_transformers import SentenceTransformer class Embedder: def __init__(self, model_nameBAAI/bge-small-zh-v1.5): self.model SentenceTransformer(model_name) def embed(self, texts: list[str]) - list[list[float]]: # BGE模型建议加instruction前缀 prefixed [f为这个句子生成表示以用于检索{t} for t in texts] return self.model.encode(prefixed, normalize_embeddingsTrue).tolist()注意BGE系列模型在检索任务上query和document的处理方式不同。query需要加instruction前缀document不需要。这个细节很多人忽略导致检索效果差一截。4.3 混合检索实现向量库用ChromaBM25用rank-bm25库。# src/retrieval/vector_store.py import chromadb class VectorStore: def __init__(self, persist_dir./chroma_db): self.client chromadb.PersistentClient(pathpersist_dir) self.collection self.client.get_or_create_collection( namedocuments, metadata{hnsw:space: cosine} ) def add(self, chunks, embeddings): self.collection.add( ids[c[id] for c in chunks], documents[c[text] for c in chunks], metadatas[{source: c[source]} for c in chunks], embeddingsembeddings ) def search(self, query_embedding, top_k10): results self.collection.query( query_embeddings[query_embedding], n_resultstop_k ) return list(zip(results[ids][0], results[documents][0]))BM25索引# src/retrieval/bm25.py from rank_bm25 import BM25Okapi import jieba class BM25Index: def __init__(self, chunks): self.chunks chunks self.tokenized [list(jieba.cut(c[text])) for c in chunks] self.bm25 BM25Okapi(self.tokenized) def search(self, query, top_k10): tokens list(jieba.cut(query)) scores self.bm25.get_scores(tokens) top_indices sorted(range(len(scores)), keylambda i: scores[i], reverseTrue)[:top_k] return [(self.chunks[i][id], self.chunks[i][text]) for i in top_indices]中文分词用jieba英文场景可以用简单的空格切分。BM25对中文的效果分词质量影响很大这是很多人踩的坑。4.4 生成与引用标注生成环节的关键是强制模型基于检索到的内容回答并标注来源。# src/generation/qa_chain.py from openai import OpenAI QA_PROMPT 你是一个严谨的问答助手。请仅基于以下参考资料回答问题。 ## 参考资料 {context} ## 问题 {question} ## 要求 1. 如果参考资料中没有相关信息直接回答根据现有资料无法回答该问题 2. 回答时用[1][2]标注引用的资料编号 3. 不要编造任何资料中没有的信息 ## 回答 class QAChain: def __init__(self, client, retriever): self.client client self.retriever retriever def answer(self, question: str) - dict: docs self.retriever.search(question, top_k5) context \n\n.join( f[{i1}] {text} for i, (_, text) in enumerate(docs) ) prompt QA_PROMPT.format(contextcontext, questionquestion) response self.client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0.1 ) return { answer: response.choices[0].message.content, sources: [doc_id for doc_id, _ in docs], usage: response.usage.total_tokens }temperature设0.1因为问答任务需要稳定和准确不需要创造性。这个参数很多人设太高导致同一个问题每次回答都不一样。4.5 评测体系没有评测就没有优化这是最容易被忽视但最重要的环节。你需要一套自动化的评测流程否则每次改提示词或换模型都是盲猜。# src/evaluation/evaluator.py class RAGEvaluator: def __init__(self, qa_chain, test_cases): self.qa_chain qa_chain self.test_cases test_cases # [{question: ..., expected_keywords: [...]}] def evaluate(self): results [] for case in self.test_cases: output self.qa_chain.answer(case[question]) # 关键词命中率 hit sum( 1 for kw in case[expected_keywords] if kw in output[answer] ) / len(case[expected_keywords]) results.append({ question: case[question], answer: output[answer], keyword_hit_rate: hit, tokens: output[usage] }) return results测试用例至少准备20-30条覆盖事实性问题、需要多文档综合的问题、资料中没有答案的问题测试拒答能力、边界问题。每次修改系统后跑一遍看指标变化。5. 常见问题与排查技巧实录5.1 检索相关的问题问题检索到的文档和问题不相关排查顺序先看embedding模型是否适合你的语料。如果是专业领域通用embedding模型效果会差。其次看chunk_size是否合适太大导致语义稀释太小导致信息不完整。最后检查query是否加了正确的instruction前缀。问题明明文档里有答案但检索不到这通常是关键词匹配的问题。纯向量检索对精确术语不敏感。解决方案是加BM25混合检索。另外检查文档切分时是否把关键信息切断了适当增加overlap。问题检索结果重复度高多个chunk来自同一文档的相邻位置内容高度相似。解决方案是在检索后做去重或者用MMR最大边际相关性算法选择多样性结果。5.2 生成相关的问题问题模型编造资料中没有的信息这是RAG最常见的失败模式。解决方案提示词里明确约束仅基于参考资料回答temperature调低加few-shot示例展示正确的拒答行为。如果还是不行考虑在生成后加一个验证步骤检查回答中的每个事实是否能在检索文档中找到依据。问题回答格式不稳定用结构化输出。OpenAI的API支持response_format参数指定JSON schema或者用function calling强制格式。不要指望提示词能100%约束住格式。问题长文档处理时超出上下文窗口不要把所有检索结果都塞进上下文。按相关性排序取top_k个并且对每个chunk做长度限制。如果单个chunk太长做二次摘要。5.3 性能与成本问题问题响应太慢瓶颈通常在embedding计算和LLM生成。embedding可以本地GPU加速或批量处理。LLM生成可以换更快的模型或者用流式输出改善用户体验首token时间比总时间更重要。问题成本失控监控token消耗设置预算告警。优化策略用更小的模型处理简单问题路由策略缓存常见问题的回答压缩提示词减少输入token。问题类型排查方向快速验证方法检索不相关embedding模型、chunk策略手动检查top_k结果检索漏召回关键词匹配、overlap加BM25对比效果生成编造提示词约束、temperature构造无答案测试用例格式不稳定结构化输出检查API参数响应慢模型选择、流式输出分段计时成本高token监控、模型路由统计每次调用token5.4 几个我踩过的坑坑一忽视文档预处理质量PDF提取的文本经常有乱码、断行、页眉页脚。直接拿来做embedding效果很差。必须做清洗去除页眉页脚、合并断行、处理特殊字符。我有个项目因为PDF提取质量差检索效果一直上不去后来花了一天做文本清洗效果提升明显。坑二embedding模型和生成模型不匹配有些embedding模型是在英文语料上训练的用在中文场景效果打折。选embedding模型时一定要在你的实际语料上测试检索效果不要只看排行榜。坑三没有做query改写用户的原始问题往往口语化、有歧义。加一步query改写把用户问题转成更适合检索的形式能显著提升召回率。比如用户问那个新出的模型多少钱改写成最新模型API定价再检索。坑四忽视缓存很多问题是重复的。加一层语义缓存相似问题直接返回缓存结果能省大量token。用embedding做相似度匹配阈值设0.95以上比较安全。6. 从能用走向好用工程化进阶要点6.1 可观测性建设生产系统和玩具项目的区别很大程度在于可观测性。你需要知道每次请求的检索结果是什么、生成了什么、消耗了多少token、延迟分布如何。import logging import time logger logging.getLogger(rag) def traced_answer(chain, question): start time.time() result chain.answer(question) latency time.time() - start logger.info({ question: question, retrieved_ids: result[sources], answer_length: len(result[answer]), tokens: result[usage], latency_ms: latency * 1000 }) return result这些日志积累起来就是你优化的依据。哪些问题检索效果差、哪些问题token消耗高一目了然。6.2 提示词与配置的版本管理把提示词、模型参数、检索参数都抽到配置文件里用Git管理。每次变更记录效果指标。这样当效果回退时能快速定位是哪个变更导致的。# config/qa_config.yaml version: 1.2.0 model: name: gpt-4o-mini temperature: 0.1 max_tokens: 1000 retrieval: top_k: 5 use_rerank: true hybrid_alpha: 0.5 prompt: file: prompts/qa_v3.txt6.3 持续评测与回归测试每次修改系统后自动跑评测集对比关键指标。指标下降超过阈值就告警。这套流程建立起来后你就能放心地迭代优化不用担心改坏。评测指标建议关注检索命中率Recallk、回答准确率、拒答准确率、平均延迟、平均token消耗。前三个衡量质量后两个衡量成本和性能。6.4 安全与合规考量生产系统必须考虑输入过滤防止提示词注入、输出过滤防止敏感信息泄露、访问控制、审计日志。提示词注入是当前很现实的风险用户可能在输入里嵌入指令试图操控模型行为。基本的防护是在系统提示词里明确边界并对用户输入做检测。我在实际项目中的体会是AI工程最难的不是某个技术点而是建立一套可持续迭代的工程体系。模型会更新提示词会调整业务需求会变化只有把评测、监控、版本管理这些基础设施建好你才能快速响应变化而不失控。从零开始的时候不要追求一步到位先跑通最小闭环再逐步加固。每加一个环节都要问自己这个环节解决什么问题没有它行不行。这样能避免过度工程也能确保每一步都是必要的。