AI工程这个词最近被反复提但很多人理解成了“用AI写代码”或者“写几个Prompt调通接口”。我见过太多团队Demo做得风生水起一上生产环境就各种翻车模型输出不稳定、数据质量一团糟、成本直线上升、出了问题不知道怎么排查。真正意义上的AI工程是把模型、数据、评估、部署、运维串成一条完整链路的能力而不是训练一个模型或者调一个接口。如果你正在从零开始学AI工程或者你已经会一些Python但不知道下一步该学什么这篇文章就是为你准备的。我会从工程视角拆解AI工程的技术栈给出一条可复现的学习路径再用一个RAG问答系统的实战案例讲清楚核心环节最后把我在实际项目中踩过的坑和排查思路整理成一张速查表。整体内容偏落地不绕理论也不讲玄学。1. AI工程不是“写模型”而是“造系统”1.1 从“调API”到“工程化”的距离很多人觉得AI工程就是调API。拿到一个OpenAI Key写一段Prompt返回结果完事。但如果只是这样AI应用就跑不远。简单调用只考虑输入输出而工程化必须考虑以下这些维度数据数据从哪来怎么清洗、怎么保证质量是不是有标注要不要定期更新。模型怎么在效果、成本、延迟之间做选择怎么评估多个候选模型。输入输出约束怎么让模型稳定输出结构化内容怎么兜底错误输出。链路的可观测性线上出问题是数据问题、模型问题还是代码逻辑问题。成本控制调用频次、Token消耗、缓存策略、模型规模。安全合规用户输入要不要过滤内容要不要做审核日志要保留多久。我自己在这个问题上栽过跟头。当时我用LangChain搭了一个看起来很漂亮的流程Demo阶段给老板演示效果惊艳一连问了七八个问题都答得不错。结果放到真实用户流量下面RAG检索返回的前几个片段全是无关内容模型生成的摘要杂乱无章。排查了大半天发现根因是Embedding模型选择不当文档切分策略也没有适配原文档结构与Prompt本身关系不大。如果不懂整条链路这种问题根本无从下手。这种体验让我把“工程化”的定义改成让模型在不可控的真实环境里持续稳定地完成价值输出。写一个Demo是艺术跑起一个产品是工程。1.2 AI工程的技术栈全景如果给AI工程画一个技术栈大概长这样基础概念层Token、Embedding、Transformer、注意力机制、温度参数、函数调用、RAG、Agent。不需要从零手写Transformer但至少要理解输入输出、能力边界知道什么任务适合什么技术。数据处理层导入、清洗、切分、向量化、缓存。SQL和Pandas至少要熟练一个。模型应用层Prompt Engineering、上下文组装、结构化输出、工具调用、长短记忆管理。检索与记忆层向量数据库、混合检索、重排序、索引管理、会话记忆。服务与部署层FastAPI服务、容器化、限流、重试、缓存、日志。评估与监控层测试集、自动化评估、线上指标收集、反馈循环。这六个板块不是割裂的。工程能力恰恰体现在如何把它们连接在一起从用户输入到最终返回链路中的每一环都有可能出现瓶颈。比如检索质量差会表现为回答事实性错误日志不完整会表现为线上问题无法复盘缓存策略不对会表现为成本飙升。1.3 为什么“从零开始”反而比“半路出家”更快这句话可能会引发争议。毕竟行业里已经有很多懂机器学习的人。但AI工程和传统机器学习的思维模型真的不太一样。传统ML的核心是特征工程、模型训练、超参调优而今天应用型AI工程的核心变成了上下文组织、工具调用、评估循环和产品集成。很多算法工程师会被旧思维拖住。他们习惯“先训练、再上线”遇到问题第一反应是换模型、加数据。但现在的很多应用问题其实是系统问题Prompt写得不清晰、检索召回不对、输出Schema不稳定。解决这些问题不一定要重新训练模型。从零开始的人没有这些包袱直接上手“数据进 → 上下文组装 → 模型推理 → 结果校验 → 反馈优化”这个闭环反而更快建立工程直觉。当然懂机器学习是加分项但不需要把它当成起跑线。我见过不少从非科班转过来的朋友因为会写脚本、会用工具、懂一点数据再加上项目实践三个月左右就能独立做AI原型。2. 从零开始的分阶段学习路线2.1 第一阶段建立“最小必要认知”很多新手容易陷入理论恐惧觉得不把机器学习啃完就不能动手。真没必要。第一阶段只需要建立几个核心概念就能正确理解后续的各种坑。Token模型不是按字母读文本而是按子词切分。比如“输入成本”可能被切成多个Token。所以上下文长度、计费方式、生成延迟都跟Token数量挂钩。Embedding把文本变成一串浮点数语义相近的向量在空间中距离更近。它是向量检索的基础。自回归生成模型逐个预测下一个Token。理解这点就知道为什么输出有随机性为什么Temperature参数会影响结果。Prompt Engineering通过输入文本组织来引导模型输出的技术。它不是几句“魔法话术”而是清晰、结构化、带约束、带示例的工程行为。这个阶段一到两周足够。如果你已经会Python甚至可以压缩到三四天。核心不是记住所有概念而是能用它们解释你看到的现象。比如模型突然答非所问你要能想到是不是上下文里混进了无关片段Token消耗比预期高你要能想到是不是历史记录没有截断。这种解释能力比背概念有用得多。关键是要跑通一个最小API调用。我的建议是写一个终端聊天脚本读取环境变量里的API Key在终端输入问题打印回答并输出Token统计。别小看这个脚本它之后会成为你调试各种Prompt和代码的主战场。你所有的实验、迭代、日志分析都可以从这个小脚本延伸出来。2.2 第二阶段构建数据与评估闭环很多教程会让你直接写Agent、搭RAG但如果你一开始就忽略数据和评估后面会很难受。因为没有评估你根本不知道改动是变好还是变坏。我看过太多人消耗大量时间调Prompt结果只是“感觉变好了”用测试集一跑指标反而下降了。这一阶段准备三类数据场景样例100-200条模拟真实用户输入覆盖正常输入、边界情况比如超长文本、错误输入比如空白、含义不清。期望输出或评分维度不需要每条都有标准答案但要有可判断好坏的指标。比如“是否包含关键信息”“是否忠实于资料”。运行日志每次模型调用的输入、输出、耗时、Token消耗、元数据。然后把评估做成一个脚本。最简单的形式测试集存成JSONL文件逐条运行AI流程生成结果再调用一个规则打分函数或人工打分。这个脚本会成为你迭代的核心工具。我以前常说“没有评估脚本的项目都是在凭感觉优化。”凭感觉优化不是不行但效率太低尤其当你要对比两个Prompt方案时没有数据你根本说不清哪个更好。2.3 第三阶段掌握大模型应用开发的核心模式这个阶段重点练四种模式每一个都值得写一个最小Demo结构化输出让模型返回JSON而不是自由文本。最简单的方式是在Prompt里写“请返回JSON格式{...}”但更可靠的方式是使用函数调用Function Calling或输出Schema校验。上下文组装把系统提示词、用户输入、检索片段、历史记录拼接成一个完整请求。核心是Token预算要确保不会超窗口也不会浪费。工具调用模型在推理时决定是否需要调用外部函数比如查天气、查数据库、做计算。这个机制是Agent的基础。多步Agent工作流模型决策 → 调用工具 → 观察工具结果 → 继续决策直到完成任务。以“查天气”为例写一个get_weather(city)函数让模型根据用户问题决定调用哪个函数拿到函数返回结果后再组织回答。这个Demo只有几十行代码却能让你彻底理解Function Calling的交互过程。很多人一上来就搭复杂的Agent结果遇到一个报错都不知道是模型没触发调用还是函数返回格式不对。先把这类小模式吃透复杂Agent只是这些模式的排列组合。2.4 第四阶段完成一个“完整”的项目到这个阶段挑一个你熟悉领域的小项目。我最推荐的是“个人知识库问答助手”因为它可以串联所有知识点而且结果容易评估。把项目目标写清楚不要做无穷无尽的新功能要关注闭环。需求清单支持上传PDF或Markdown文档自动切分、向量化、写入向量库用户提问时检索相关片段模型基于检索片段回答并给出引用来源增加“点赞/点踩”反馈按钮记录每次查询的日志这个项目看着简单但当你真正动手做完就会理解“端到端”是什么概念从文件上传到文本解析到向量检索到Prompt组装到模型生成再到结果展示和数据回流。中间每一步都有可能有坑。做完之后不要停继续收集几个测试集看看当前系统的检索命中率是多少、回答忠实度如何、单次成本多少。把这些数字都记录下来才叫完整项目。3. 实操要点从零搭一个RAG问答系统3.1 需求定义与方案选型我建议第一版RAG不要一上来就上LangChain先用Python手写最简版本理解每个环节后再用框架减少重复代码。先定义需求输入用户一个问题输出一个带引用的答案知识来源本地一批文档约束回答只基于文档内容不确定时明确说“不知道”方案选型上Embedding模型我试过开源的BGE-M3也用过OpenAI的text-embedding-3-small。如果你追求低成本和离线能力BGE系列很不错如果追求简单OpenAI API更方便。关键是先跑通再谈优化。很多人在选型上纠结很久其实第一版用哪个都行重要的是把整条链路走通拿到真实数据后再替换也不迟。3.2 数据准备与向量化这一步决定系统上限。数据预处理基本就是三件事第一清洗。把原始文本里的多余换行、空字符、乱码清掉。PDF转出来的文本尤其需要小心经常夹杂各种异常字符。我踩过一个大坑PDF转出的文本里原本的标题和正文被打散成无数个短行向量化之后检索质量惨不忍睹。后来加上一行简单的换行合并逻辑效果立刻改善。清洗规则不需要很复杂先做“合并连续换行、去除孤立空行、统一编码”这三步就能解决大部分问题。第二切分。不要固定字数切块。虽然很多人用200字、300字一刀切但这样会把语义割裂。更好的做法是按语义单元切优先以标题、段落为边界。比如Markdown文档可以写一个简单的解析函数按#、##、空行切分。如果文档结构复杂还可以用递归切分策略先尝试按段落切段落太长再按句子切。切分粒度需要根据文档类型调整没有万能参数。第三向量化并保存元数据。每个片段用Embedding模型转成向量同时保存来源文件、章节标题、页码等元数据。这一步的好处是你可以在检索时按元数据过滤比如只看某个章节也能在引用时给出准确来源。不要只存向量的裸文本元数据会帮助你做后续的权限控制、统计分析和引用回显。3.3 检索与生成的串联RAG流程本身很简单用户问题向量化 → 在向量库中做相似度检索取Top-KK一般取3-5→ 把问题和检索片段组装成Prompt → 调生成模型 → 得到回答。再加上重排序就是更完整的链路。下面是一个极简Python实现适合跑通链路import numpy as np from openai import OpenAI client OpenAI() def embed(text): resp client.embeddings.create( modeltext-embedding-3-small, input[text] ) return resp.data[0].embedding def search(query, corpus, k4): q_vec np.array(embed(query)) scores [] for item in corpus: doc_vec np.array(item[embedding]) # 如果embedding已经归一化内积等价于余弦相似度 scores.append(np.dot(q_vec, doc_vec)) top_idx np.argsort(scores)[::-1][:k] return [corpus[i] for i in top_idx] def generate_answer(query, context_items): context \n\n.join( [f[{i1}] {item[text]} for i, item in enumerate(context_items)] ) prompt f仅根据以下资料回答问题。 资料 {context} 问题{query} 如果资料中没有相关信息请回答“资料中没有提到”。回答时逐个列出你使用的片段编号。 resp client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}] ) return resp.choices[0].message.content这段代码虽然简单但已经把核心链路完整覆盖了Embedding召回、相似度排序、上下文组装和生成。实际工程中你需要在这个骨架上加日志、缓存、重试、并发、失败兜底。我强烈建议你自己动手把这段代码敲一遍再试着加一个“输出JSON引用来源”的后处理步骤。只有手写过一遍你才能真正理解RAG编排的含义后面再引入LangChain或LlamaIndex时也不会被抽象层绕晕。3.4 评估与迭代最容易被忽略的一环RAG系统不是搭完就结束后续迭代才是真正的工程。你需要建立三个层面的评测检索质量检索到的Top-K片段是否真的包含答案。用命中率评估。生成质量答案是否忠实于检索片段、是否完整、是否有事实性错误。端到端体验用户点不点赞、问题能否解决。具体做法准备100个“问题-预期片段-预期回答要点”三元组。跑完整链路后先看检索命中的片段是否包含预期片段再看生成答案是否覆盖要点。可以用一个小的LLM做初筛再人工抽样复核。一开始不用追求复杂指标先看几个数字命中率、事实错误率、无答案率。这里有个反直觉经验很多生成质量问题根因其实是检索质量问题。你改Prompt改到嘴秃不如回头调整切分策略和Embedding模型。所以每次迭代前先看检索结果再看生成结果。如果检索命中率只有60%你无论怎么优化Prompt生成质量都会受限。把检索命中率提到85%以上生成质量往往会有肉眼可见的提升。4. 工具选型解析如何搭出趁手的工作台4.1 模型层API优先还是开源优先我的建议是第一版项目用API优先。省时间、免运维、效果有保障。你只需要关心应用逻辑。等要控制成本或数据合规时再换开源模型。开源模型这几年进步很快但部署、调优、运维成本并不低对一个从零开始的项目不是最优选择。常用的模型选型表场景推荐模型快速原型GPT-4o-mini / Claude Haiku高质量摘要GPT-4o / Claude Sonnet离线/私有化Qwen / Llama 3 等开源模型Embeddingtext-embedding-3-small / BGE-M3选模型不要只看基准分数最好让自己的一小批测试集同时跑两三个模型用评估脚本对比输出。模型A在公开榜单上很强但可能在你的具体任务上并不比模型B好这事很常见。把测试集固定下来谁的输出在你的指标上得分最高就用谁这才是工程决策。4.2 编排层框架 vs 手写代码很多人纠结LangChain好还是LlamaIndex好。我的看法是LangChain组件多、生态大但抽象层多、版本变动快适合复杂Agent和工具调用。LlamaIndex对索引和检索更专注适合知识库问答。手写代码适合理解原理、定制化强的小项目也适合排查问题时不至于一头雾水。坦白讲我见过太多人陷入“LangChain Release Notes”的泥潭。如果你已经理解了完整链路手写几百行代码一点都不难。框架的价值在后期比如处理工具循环、并发、重试等。新手前期最好少依赖框架免得报了错却不知道黑盒里发生了什么。我自己的习惯是先裸写跑通再根据重复度和维护成本决定要不要引入框架。框架是提升效率的不是掩盖理解缺口的。4.3 部署与观测不翻车的关键部署阶段至少要解决五个问题服务化用FastAPI把AI流程包成一个接口。用Pydantic做请求和响应的Schema验证。限流与重试模型调用要加指数退避和最大重试次数对外API要加限流防止被刷爆。日志每次请求记录输入、检索到的上下文片段、输出、耗时、Token数和成本。这是排查问题的命根子。缓存相同问题在短期窗口内命中缓存能省大量成本。我习惯用Redis存最近几天的问答结果。监控设置错误率和延迟告警。关键告警走即时通知避免半夜才发现系统挂了。我推荐一套朴素的起步方案FastAPI Pydantic SQLite日志表。不需要一上来就上Kubernetes、分布式追踪先把“跑起来、能观测”做到后面再演进。先动手再谈扩展。5. 常见问题与排查技巧实录5.1 上下文窗口不够怎么办出现“上下文窗口不够”时先看日志确认是哪一步把窗口撑爆了。常见的三个来源检索片段太多或太长。解法减少Top-K、限制每个片段的最大长度或者做重排序后只取最相关的片段。多轮历史记录无限膨胀。解法只保留最近N轮或对历史做摘要压缩。系统提示词太长。解法精简提示词把不常用的说明移到单独文档。如果长文档确实必须塞进去可以使用“分治”思路一次性问不出答案就先把文档拆成目录每章单独提问再汇总。或者对文档做摘要把摘要作为上下文。经验是与其想办法扩大上下文窗口不如从源头减少不必要的内容。保存Token就是省钱减少噪声就是提高质量。你可以在检索阶段就过滤掉不相关片段而不是把整个文档都塞进Prompt也可以在历史管理里只保留用户问题和最终答案丢弃中间过程。这既能控制成本还能降低模型被无关信息干扰的概率。5.2 生成结果不稳定怎么管模型输出天然有随机性Temperature设为0并不等于每次结果都一致。工程上要做的是把随机性控制在可接受范围并用校验和重试兜底。推荐做法设置较低Temperature比如0-0.3。用结构化输出或函数调用把模型回答限定在固定字段。在后处理中做Schema校验不满足要求就重试一次或返回默认值。在Prompt里给出输出格式的示例能显著减少格式混乱。我见过一个很实际的例子让模型生成JSON偶尔会在JSON外面夹一段解释文字导致解析失败。后来用函数调用强制返回结构化字段问题基本消失。不要相信“模型一定会遵守格式”要把它当成“大多数时候会遵守所以你需要兜底”。每次调用都做好异常捕获和默认分支比追求模型绝对稳定更现实。5.3 检索质量差怎么调检索质量差通常有五个原因按优先级排查切分不当导致一个片段里包含多个主题检索向量代表“平均值”。Embedding模型与领域不匹配比如通用模型对专业术语理解不够。查询与文档表达差异大比如用户说“离职”文档里写“离开公司”。Top-K不合适太小漏掉相关信息太大混入噪声。缺少重排序向量检索的第一候选不一定是语义上最相关的。解决方案也很直接先看具体失败案例再动手。比如查询“小张的离职时间”文档里写“2023年5月31日离开公司”向量检索可能排在后面。此时可以考虑混合检索让关键词命中参与排序或者用重排序模型精排。不要盲目换模型先找出“差”的具体表现。把失败案例聚成几类比如“问题含专有名词”“文档表达口语化”“片段边界切错了”再针对每一类做策略调整。5.4 成本失控与性能优化AI应用的钱主要花在API调用和向量化上。成本失控的常见原因全程都用最强模型、做了大量不必要调用、没有缓存、Agent级联反复调用同一个模型。优化手段简单任务用小型模型复杂任务用大型模型。增加短期缓存相同问题当天不再重复调用。批量处理Embedding请求减少请求次数。对Prompt做瘦身减少系统提示词和历史占用的Token。使用流式输出可以改善首字延迟但总Token不会减少。性能优化则优先看延迟瓶颈。如果是检索慢换HNSW索引如果是生成慢换小模型或减少max_tokens。不要上来就优化和横向扩展先找到最慢的1秒在哪。用日志里的耗时分布数据说话而不是靠猜。6. 最后分享几点经验从零开始到能独立搭建AI应用我最大的体会是工程化是一种“让模型可被预测地工作”的能力而不是追求模型本身的神奇效果。你不需要把每个模型论文都读懂但你需要有能力控制模型在业务中的行为边界。第一务必先搭评估闭环哪怕很粗糙。我有段时间觉得“差不多就行”导致每次优化都在原地打转。后来强迫自己每改一次就用同一批测试集跑一遍记录数字。这样我才能清晰地说“切分改小之后检索命中率上升了8%但回答完整度下降了一点。”这种数据化反馈特别重要能帮你避开很多主观感受的陷阱。第二日志从一开始就埋好。结构化的日志模板在前期看起来很“浪费”但后面做监控、排查、复盘会特别省力。加日志这十分钟能帮你省下后期几天。我甚至会在每个AI调用前后加耗时和Token统计成本核算全靠它。第三别迷信最强模型。我一开始总想用最强的模型结果成本高、延迟大。后来把简单任务切给小型模型效果差别不大成本却降了七成。模型选型是持续迭代的过程不是发布会后一次决定。你手上的测试集和日志才是选型最可靠的依据。希望这些经验能帮你少走弯路。AI工程现在还很新没有一套标准答案但真正动手做过完整项目的人一定比看教程多的人走得更远。祝你早日把第一个端到端的项目跑起来。 AI工程这个词最近被反复提但很多人理解成了“用AI写代码”或者“写几个Prompt调通接口”。我见过太多团队Demo做得风生水起一上生产环境就各种翻车模型输出不稳定、数据质量一团糟、成本直线上升、出了问题不知道怎么排查。真正意义上的AI工程是把模型、数据、评估、部署、运维串成一条完整链路的能力而不是训练一个模型或者调一个接口。如果你正在从零开始学AI工程或者你已经会一些Python但不知道下一步该学什么这篇文章就是为你准备的。我会从工程视角拆解AI工程的技术栈给出一条可复现的学习路径再用一个RAG问答系统的实战案例讲清楚核心环节最后把我在实际项目中踩过的坑和排查思路整理成一张速查表。整体内容偏落地不绕理论也不讲玄学。1. AI工程不是“写模型”而是“造系统”1.1 从“调API”到“工程化”的距离很多人觉得AI工程就是调API。拿到一个OpenAI Key写一段Prompt返回结果完事。但如果只是这样AI应用就跑不远。简单调用只考虑输入输出而工程化必须考虑以下这些维度数据数据从哪来怎么清洗、怎么保证质量是不是有标注要不要定期更新。模型怎么在效果、成本、延迟之间做选择怎么评估多个候选模型。输入输出约束怎么让模型稳定输出结构化内容怎么兜底错误输出。链路的可观测性线上出问题是数据问题、模型问题还是代码逻辑问题。成本控制调用频次、Token消耗、缓存策略、模型规模。安全合规用户输入要不要过滤内容要不要做审核日志要保留多久。我自己在这个问题上栽过跟头。当时我用LangChain搭了一个看起来很漂亮的流程Demo阶段给老板演示效果惊艳一连问了七八个问题都答得不错。结果放到真实用户流量下面RAG检索返回的前几个片段全是无关内容模型生成的摘要杂乱无章。排查了大半天发现根因是Embedding模型选择不当文档切分策略也没有适配原文档结构与Prompt本身关系不大。如果不懂整条链路这种问题根本无从下手。这种体验让我把“工程化”的定义改成让模型在不可控的真实环境里持续稳定地完成价值输出。写一个Demo是艺术跑起一个产品是工程。1.2 AI工程的技术栈全景如果给AI工程画一个技术栈大概长这样基础概念层Token、Embedding、Transformer、注意力机制、温度参数、函数调用、RAG、Agent。不需要从零手写Transformer但至少要理解输入输出、能力边界知道什么任务适合什么技术。数据处理层导入、清洗、切分、向量化、缓存。SQL和Pandas至少要熟练一个。模型应用层Prompt Engineering、上下文组装、结构化输出、工具调用、长短记忆管理。检索与记忆层向量数据库、混合检索、重排序、索引管理、会话记忆。服务与部署层FastAPI服务、容器化、限流、重试、缓存、日志。评估与监控层测试集、自动化评估、线上指标收集、反馈循环。这六个板块不是割裂的。工程能力恰恰体现在如何把它们连接在一起从用户输入到最终返回链路中的每一环都有可能出现瓶颈。比如检索质量差会表现为回答事实性错误日志不完整会表现为线上问题无法复盘缓存策略不对会表现为成本飙升。1.3 为什么“从零开始”反而比“半路出家”更快这句话可能会引发争议。毕竟行业里已经有很多懂机器学习的人。但AI工程和传统机器学习的思维模型真的不太一样。传统ML的核心是特征工程、模型训练、超参调优而今天应用型AI工程的核心变成了上下文组织、工具调用、评估循环和产品集成。很多算法工程师会被旧思维拖住。他们习惯“先训练、再上线”遇到问题第一反应是换模型、加数据。但现在的很多应用问题其实是系统问题Prompt写得不清晰、检索召回不对、输出Schema不稳定。解决这些问题不一定要重新训练模型。从零开始的人没有这些包袱直接上手“数据进 → 上下文组装 → 模型推理 → 结果校验 → 反馈优化”这个闭环反而更快建立工程直觉。当然懂机器学习是加分项但不需要把它当成起跑线。我见过不少从非科班转过来的朋友因为会写脚本、会用工具、懂一点数据再加上项目实践三个月左右就能独立做AI原型。2. 从零开始的分阶段学习路线2.1 第一阶段建立“最小必要认知”很多新手容易陷入理论恐惧觉得不把机器学习啃完就不能动手。真没必要。第一阶段只需要建立几个核心概念就能正确理解后续的各种坑。Token模型不是按字母读文本而是按子词切分。比如“输入成本”可能被切成多个Token。所以上下文长度、计费方式、生成延迟都跟Token数量挂钩。Embedding把文本变成一串浮点数语义相近的向量在空间中距离更近。它是向量检索的基础。自回归生成模型逐个预测下一个Token。理解这点就知道为什么输出有随机性为什么Temperature参数会影响结果。Prompt Engineering通过输入文本组织来引导模型输出的技术。它不是几句“魔法话术”而是清晰、结构化、带约束、带示例的工程行为。这个阶段一到两周足够。如果你已经会Python甚至可以压缩到三四天。核心不是记住所有概念而是能用它们解释你看到的现象。比如模型突然答非所问你要能想到是不是上下文里混进了无关片段Token消耗比预期高你要能想到是不是历史记录没有截断。这种解释能力比背概念有用得多。关键是要跑通一个最小API调用。我的建议是写一个终端聊天脚本读取环境变量里的API Key在终端输入问题打印回答并输出Token统计。别小看这个脚本它之后会成为你调试各种Prompt和代码的主战场。你所有的实验、迭代、日志分析都可以从这个小脚本延伸出来。2.2 第二阶段构建数据与评估闭环很多教程会让你直接写Agent、搭RAG但如果你一开始就忽略数据和评估后面会很难受。因为没有评估你根本不知道改动是变好还是变坏。我看过太多人消耗大量时间调Prompt结果只是“感觉变好了”用测试集一跑指标反而下降了。这一阶段准备三类数据场景样例100-200条模拟真实用户输入覆盖正常输入、边界情况比如超长文本、错误输入比如空白、含义不清。期望输出或评分维度不需要每条都有标准答案但要有可判断好坏的指标。比如“是否包含关键信息”“是否忠实于资料”。运行日志每次模型调用的输入、输出、耗时、Token消耗、元数据。然后把评估做成一个脚本。最简单的形式测试集存成JSONL文件逐条运行AI流程生成结果再调用一个规则打分函数或人工打分。这个脚本会成为你迭代的核心工具。我以前常说“没有评估脚本的项目都是在凭感觉优化。”凭感觉优化不是不行但效率太低尤其当你要对比两个Prompt方案时没有数据你根本说不清哪个更好。2.3 第三阶段掌握大模型应用开发的核心模式这个阶段重点练四种模式每一个都值得写一个最小Demo结构化输出让模型返回JSON而不是自由文本。最简单的方式是在Prompt里写“请返回JSON格式{...}”但更可靠的方式是使用函数调用Function Calling或输出Schema校验。上下文组装把系统提示词、用户输入、检索片段、历史记录拼接成一个完整请求。核心是Token预算要确保不会超窗口也不会浪费。工具调用模型在推理时决定是否需要调用外部函数比如查天气、查数据库、做计算。这个机制是Agent的基础。多步Agent工作流模型决策 → 调用工具 → 观察工具结果 → 继续决策直到完成任务。以“查天气”为例写一个get_weather(city)函数让模型根据用户问题决定调用哪个函数拿到函数返回结果后再组织回答。这个Demo只有几十行代码却能让你彻底理解Function Calling的交互过程。很多人一上来就搭复杂的Agent结果遇到一个报错都不知道是模型没触发调用还是函数返回格式不对。先把这类小模式吃透复杂Agent只是这些模式的排列组合。2.4 第四阶段完成一个“完整”的项目到这个阶段挑一个你熟悉领域的小项目。我最推荐的是“个人知识库问答助手”因为它可以串联所有知识点而且结果容易评估。把项目目标写清楚不要做无穷无尽的新功能要关注闭环。需求清单支持上传PDF或Markdown文档自动切分、向量化、写入向量库用户提问时检索相关片段模型基于检索片段回答并给出引用来源增加“点赞/点踩”反馈按钮记录每次查询的日志这个项目看着简单但当你真正动手做完就会理解“端到端”是什么概念从文件上传到文本解析到向量检索到Prompt组装到模型生成再到结果展示和数据回流。中间每一步都有可能有坑。做完之后不要停继续收集几个测试集看看当前系统的检索命中率是多少、回答忠实度如何、单次成本多少。把这些数字都记录下来才叫完整项目。3. 实操要点从零搭一个RAG问答系统3.1 需求定义与方案选型我建议第一版RAG不要一上来就上LangChain先用Python手写最简版本理解每个环节后再用框架减少重复代码。先定义需求输入用户一个问题输出一个带引用的答案知识来源本地一批文档约束回答只基于文档内容不确定时明确说“不知道”方案选型上Embedding模型我试过开源的BGE-M3也用过OpenAI的text-embedding-3-small。如果你追求低成本和离线能力BGE系列很不错如果追求简单OpenAI API更方便。关键是先跑通再谈优化。很多人在选型上纠结很久其实第一版用哪个都行重要的是把整条链路走通拿到真实数据后再替换也不迟。3.2 数据准备与向量化这一步决定系统上限。数据预处理基本就是三件事第一清洗。把原始文本里的多余换行、空字符、乱码清掉。PDF转出来的文本尤其需要小心经常夹杂各种异常字符。我踩过一个大坑PDF转出的文本里原本的标题和正文被打散成无数个短行向量化之后检索质量惨不忍睹。后来加上一行简单的换行合并逻辑效果立刻改善。清洗规则不需要很复杂先做“合并连续换行、去除孤立空行、统一编码”这三步就能解决大部分问题。第二切分。不要固定字数切块。虽然很多人用200字、300字一刀切但这样会把语义割裂。更好的做法是按语义单元切优先以标题、段落为边界。比如Markdown文档可以写一个简单的解析函数按#、##、空行切分。如果文档结构复杂还可以用递归切分策略先尝试按段落切段落太长再按句子切。切分粒度需要根据文档类型调整没有万能参数。第三向量化并保存元数据。每个片段用Embedding模型转成向量同时保存来源文件、章节标题、页码等元数据。这一步的好处是你可以在检索时按元数据过滤比如只看某个章节也能在引用时给出准确来源。不要只存向量的裸文本元数据会帮助你做后续的权限控制、统计分析和引用回显。3.3 检索与生成的串联RAG流程本身很简单用户问题向量化 → 在向量库中做相似度检索取Top-KK一般取3-5→ 把问题和检索片段组装成Prompt → 调生成模型 → 得到回答。再加上重排序就是更完整的链路。下面是一个极简Python实现适合跑通链路import numpy as np from openai import OpenAI client OpenAI() def embed(text): resp client.embeddings.create( modeltext-embedding-3-small, input[text] ) return resp.data[0].embedding def search(query, corpus, k4): q_vec np.array(embed(query)) scores [] for item in corpus: doc_vec np.array(item[embedding]) # 如果embedding已经归一化内积等价于余弦相似度 scores.append(np.dot(q_vec, doc_vec)) top_idx np.argsort(scores)[::-1][:k] return [corpus[i] for i in top_idx] def generate_answer(query, context_items): context \n\n.join( [f[{i1}] {item[text]} for i, item in enumerate(context_items)] ) prompt f仅根据以下资料回答问题。 资料 {context} 问题{query} 如果资料中没有相关信息请回答“资料中没有提到”。回答时逐个列出你使用的片段编号。 resp client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}] ) return resp.choices[0].message.content这段代码虽然简单但已经把核心链路完整覆盖了Embedding召回、相似度排序、上下文组装和生成。实际工程中你需要在这个骨架上加日志、缓存、重试、并发、失败兜底。我强烈建议你自己动手把这段代码敲一遍再试着加一个“输出JSON引用来源”的后处理步骤。只有手写过一遍你才能真正理解RAG编排的含义后面再引入LangChain或LlamaIndex时也不会被抽象层绕晕。3.4 评估与迭代最容易被忽略的一环RAG系统不是搭完就结束后续迭代才是真正的工程。你需要建立三个层面的评测检索质量检索到的Top-K片段是否真的包含答案。用命中率评估。生成质量答案是否忠实于检索片段、是否完整、是否有事实性错误。端到端体验用户点不点赞、问题能否解决。具体做法准备100个“问题-预期片段-预期回答要点”三元组。跑完整链路后先看检索命中的片段是否包含预期片段再看生成答案是否覆盖要点。可以用一个小的LLM做初筛再人工抽样复核。一开始不用追求复杂指标先看几个数字命中率、事实错误率、无答案率。这里有个反直觉经验很多生成质量问题根因其实是检索质量问题。你改Prompt改到嘴秃不如回头调整切分策略和Embedding模型。所以每次迭代前先看检索结果再看生成结果。如果检索命中率只有60%你无论怎么优化Prompt生成质量都会受限。把检索命中率提到85%以上生成质量往往会有肉眼可见的提升。4. 工具选型解析如何搭出趁手的工作台4.1 模型层API优先还是开源优先我的建议是第一版项目用API优先。省时间、免运维、效果有保障。你只需要关心应用逻辑。等要控制成本或数据合规时再换开源模型。开源模型这几年进步很快但部署、调优、运维成本并不低对一个从零开始的项目不是最优选择。常用的模型选型表场景推荐模型快速原型GPT-4o-mini / Claude Haiku高质量摘要GPT-4o / Claude Sonnet离线/私有化Qwen / Llama 3 等开源模型Embeddingtext-embedding-3-small / BGE-M3选模型不要只看基准分数最好让自己的一小批测试集同时跑两三个模型用评估脚本对比输出。模型A在公开榜单上很强但可能在你的具体任务上并不比模型B好这事很常见。把测试集固定下来谁的输出在你的指标上得分最高就用谁这才是工程决策。4.2 编排层框架 vs 手写代码很多人纠结LangChain好还是LlamaIndex好。我的看法是LangChain组件多、生态大但抽象层多、版本变动快适合复杂Agent和工具调用。LlamaIndex对索引和检索更专注适合知识库问答。手写代码适合理解原理、定制化强的小项目也适合排查问题时不至于一头雾水。坦白讲我见过太多人陷入“LangChain Release Notes”的泥潭。如果你已经理解了完整链路手写几百行代码一点都不难。框架的价值在后期比如处理工具循环、并发、重试等。新手前期最好少依赖框架免得报了错却不知道黑盒里发生了什么。我自己的习惯是先裸写跑通再根据重复度和维护成本决定要不要引入框架。框架是提升效率的不是掩盖理解缺口的。4.3 部署与观测不翻车的关键部署阶段至少要解决五个问题服务化用FastAPI把AI流程包成一个接口。用Pydantic做请求和响应的Schema验证。限流与重试模型调用要加指数退避和最大重试次数对外API要加限流防止被刷爆。日志每次请求记录输入、检索到的上下文片段、输出、耗时、Token数和成本。这是排查问题的命根子。缓存相同问题在短期窗口内命中缓存能省大量成本。我习惯用Redis存最近几天的问答结果。监控设置错误率和延迟告警。关键告警走即时通知避免半夜才发现系统挂了。我推荐一套朴素的起步方案FastAPI Pydantic SQLite日志表。不需要一上来就上Kubernetes、分布式追踪先把“跑起来、能观测”做到后面再演进。先动手再谈扩展。5. 常见问题与排查技巧实录5.1 上下文窗口不够怎么办出现“上下文窗口不够”时先看日志确认是哪一步把窗口撑爆了。常见的三个来源检索片段太多或太长。解法减少Top-K、限制每个片段的最大长度或者做重排序后只取最相关的片段。多轮历史记录无限膨胀。解法只保留最近N轮或对历史做摘要压缩。系统提示词太长。解法精简提示词把不常用的说明移到单独文档。如果长文档确实必须塞进去可以使用“分治”思路一次性问不出答案就先把文档拆成目录每章单独提问再汇总。或者对文档做摘要把摘要作为上下文。经验是与其想办法扩大上下文窗口不如从源头减少不必要的内容。保存Token就是省钱减少噪声就是提高质量。你可以在检索阶段就过滤掉不相关片段而不是把整个文档都塞进Prompt也可以在历史管理里只保留用户问题和最终答案丢弃中间过程。这既能控制成本还能降低模型被无关信息干扰的概率。5.2 生成结果不稳定怎么管模型输出天然有随机性Temperature设为0并不等于每次结果都一致。工程上要做的是把随机性控制在可接受范围并用校验和重试兜底。推荐做法设置较低Temperature比如0-0.3。用结构化输出或函数调用把模型回答限定在固定字段。在后处理中做Schema校验不满足要求就重试一次或返回默认值。在Prompt里给出输出格式的示例能显著减少格式混乱。我见过一个很实际的例子让模型生成JSON偶尔会在JSON外面夹一段解释文字导致解析失败。后来用函数调用强制返回结构化字段问题基本消失。不要相信“模型一定会遵守格式”要把它当成“大多数时候会遵守所以你需要兜底”。每次调用都做好异常捕获和默认分支比追求模型绝对稳定更现实。5.3 检索质量差怎么调检索质量差通常有五个原因按优先级排查切分不当导致一个片段里包含多个主题检索向量代表“平均值”。Embedding模型与领域不匹配比如通用模型对专业术语理解不够。查询与文档表达差异大比如用户说“离职”文档里写“离开公司”。Top-K不合适太小漏掉相关信息太大混入噪声。缺少重排序向量检索的第一候选不一定是语义上最相关的。解决方案也很直接先看具体失败案例再动手。比如查询“小张的离职时间”文档里写“2023年5月31日离开公司”向量检索可能排在后面。此时可以考虑混合检索让关键词命中参与排序或者用重排序模型精排。不要盲目换模型先找出“差”的具体表现。把失败案例聚成几类比如“问题含专有名词”“文档表达口语化”“片段边界切错了”再针对每一类做策略调整。5.4 成本失控与性能优化AI应用的钱主要花在API调用和向量化上。成本失控的常见原因全程都用最强模型、做了大量不必要调用、没有缓存、Agent级联反复调用同一个模型。优化手段简单任务用小型模型复杂任务用大型模型。增加短期缓存相同问题当天不再重复调用。批量处理Embedding请求减少请求次数。对Prompt做瘦身减少系统提示词和历史占用的Token。使用流式输出可以改善首字延迟但总Token不会减少。性能优化则优先看延迟瓶颈。如果是检索慢换HNSW索引如果是生成慢换小模型或减少max_tokens。不要上来就优化和横向扩展先找到最慢的1秒在哪。用日志里的耗时分布数据说话而不是靠猜。6. 最后分享几点经验从零开始到能独立搭建AI应用我最大的体会是工程化是一种“让模型可被预测地工作”的能力而不是追求模型本身的神奇效果。你不需要把每个模型论文都读懂但你需要有能力控制模型在业务中的行为边界。第一务必先搭评估闭环哪怕很粗糙。我有段时间觉得“差不多就行”导致每次优化都在原地打转。后来强迫自己每改一次就用同一批测试集跑一遍记录数字。这样我才能清晰地说“切分改小之后检索命中率上升了8%但回答完整度下降了一点。”这种数据化反馈特别重要能帮你避开很多主观感受的陷阱。第二日志从一开始就埋好。结构化的日志模板在前期看起来很“浪费”但后面做监控、排查、复盘会特别省力。加日志这十分钟能帮你省下后期几天。我甚至会在每个AI调用前后加耗时和Token统计成本核算全靠它。第三别迷信最强模型。我一开始总想用最强的模型结果成本高、延迟大。后来把简单任务切给小型模型效果差别不大成本却降了七成。模型选型是持续迭代的过程不是发布会后一次决定。你手上的测试集和日志才是选型最可靠的依据。希望这些经验能帮你少走弯路。AI工程现在还很新没有一套标准答案但真正动手做过完整项目的人一定比看教程多的人走得更远。祝你早日把第一个端到端的项目跑起来。