1. 这个项目到底在做什么AI工程的真实面貌与“从零开始”的底层逻辑如果你混过GitHub、逛过技术社区大概率对这种命名不陌生xxx-from-scratch翻译过来就是“从零实现/从零起步”。当这个词组撞上ai-engineering指向就非常明确了——不是教你三天调通一个聊天机器人Demo也不是背一堆Prompt技巧而是要把AI应用开发这条链路上的核心工程能力从原理到落地全须全尾地走一遍。先说我的判断这个项目的定位大概率是一份面向有一定编程基础、但没系统接触过LLM应用开发人群的学习路线图或者是一份配套代码仓库。它要回答的核心问题只有一个在不依赖黑盒框架的前提下一个人能不能把“大模型应用”这种看起来很高端的东西从请求封装、上下文管理、检索增强生成、Agent工具调用一路做到部署观测每一步都自己掌握。我的答案是能而且必须这么做一次哪怕只是做一个千行以内的玩具项目。为什么“必须手写一次”我见过太多直接上手LangChain、LlamaIndex的开发者框架封装得太好出了问题就抓瞎。比如RAG检索增强生成检索不到有效信息他们第一反应是换个向量库、调个相似度阈值很少有人会去检查切分策略、Embedding模型和检索链路本身。这就是典型的“会用工具但不理解工具”。from-scratch的价值就是把框架代劳的部分全部摊开让你亲手把每个环节搭一遍。这个过程中的踩坑、调试、重读源码、查文档才是真正沉淀下来的工程直觉。所以这篇博客我打算把它当成一份“从零开始AI工程”的项目复盘来写。内容不只讲这个项目本身怎么搭更重要的是把我自己在实际动手过程中的思路、决策、踩坑记录一并放进来。如果你想学AI工程但不知道从哪下手或者已经在用框架但总感觉哪里没打通这篇文章应该能给你一条足够清晰的路线。1.1 什么算AI工程什么只是API调用先做一个非常必要的概念界定因为这直接决定你后面学什么、学到什么程度。很多人把“会调OpenAI接口”当成AI应用开发严格来说那只是API调用。真正的AI工程至少包含四个层面一是模型交互层你要理解Token、上下文窗口、温度、流式输出、函数调用这些概念的底层机制而不是只会填参数二是增强层也就是RAG、记忆管理、知识库问答核心在于怎么把外部知识准确送进模型的上下文里三是编排层也就是Agent让模型能够调用工具、规划步骤、执行动作这涉及复杂的循环控制与状态管理四是工程化层包括模型评测、推理加速、部署上线、监控告警、成本优化。这四个层面层层递进但大量教程把它们混在一起直接给一个LangChain的封装代码就完事。这个项目要拆开的就是这四层。所以你看它确实不是“标题党式”的学习清单而是一个具备完整工程纵深的学习框架。弄明白这个分层你再去看任何AI相关教程都会清晰很多。1.2 为什么两条路线框架先行还是原理先行在AI工程学习这件事上社区里一直有两条路线之争。第一条是“框架先行”拉一个LangChain模板配置好向量库和模型跑通一个Demo再说第二条是“原理先行”先把HTTP请求、Embedding计算、检索排序、Prompt拼接这些底层环节手写一遍理解整条链路之后再回头用框架提升效率。我在这个项目里明确选了第二条路线原因有两个。第一AI工程这个领域还没稳定下来——今天的主流框架半年后可能就大变样了。如果你只学会了框架的用法框架迭代一次你的知识就贬值一次。但底层原理不会变Tokenization的机制、向量检索的数学逻辑、上下文窗口的物理限制无论哪个框架底层都是这些东西。第二AI应用的调试极度依赖对链路的整体理解。RAG回答错了问题可能出在切分、检索、排序、Prompt任何一环没有全局视野你连问题出在哪都不知道。先把原理跑通一遍你以后用任何框架都是在正确心智模型上做效率优化而不是盲人摸象。2. 从零开始的完整学习路径我把这个项目拆成了五个阶段如果你现在打开项目仓库看到的一定不是一堆零散的代码文件而是按阶段组织的清晰目录。因为“从零开始”最大的敌人不是难度而是漫无目的。我把整条学习路径拆成五个阶段每个阶段都有明确的目标产出。这个设计本身就是这个项目最有价值的顶层架构。2.1 第一阶段LLM原理直觉——Token、上下文与采样参数第一阶段不写代码而是要建立对LLM工作方式的操作直觉。这里最核心的三件事Token、上下文窗口、采样参数。Token是模型的“文字颗粒度”它不是按单词或字符切分的而是按模型词汇表里的子词单元切分的。这也是为什么“hello world”可能是2个Token而一段中文可能是十几个Token。你写Prompt时以为自己在控制长度实际控制的是Token数量。上下文窗口则是模型一次性能看到的最大Token数它决定了你的Prompt能塞多少东西——这对后面的RAG设计有直接影响。采样参数里最容易被忽略的是Temperature和Top-P。很多人只知道“调高更随机”但实际项目中比如做知识库问答Temperature通常要压低到0.1甚至0因为你需要确定性答案做创意文案才调高。这些参数不是玄学它们直接决定了解码时从概率分布中选取Token的策略。这个阶段不需要背公式但必须亲手做实验给同一个Prompt设置不同温度和Top-P看输出质量的具体差别建立直觉后再进下一阶段。2.2 第二阶段手写第一个请求——从API到流式解析第二阶段开始写代码。这里很多人犯的错误是一上来就装SDK我建议至少有一次手写HTTP请求的经验。为什么因为SDK是别人封装好的超时、重试、错误码、流式解析这些细节它会帮你挡掉但也会让你对“一个LLM请求到底经历了什么”毫无感知。手写请求的核心难点是流式解析。LLM生成Token是逐个输出的服务端会通过Server-Sent Events持续推送数据。你要做的就是按行读取数据流解析出每个Token并实时渲染。这个体验和传统JSON接口完全不同——不是一口气拿到结果而是边生成边展示。真正写过一遍流式解析你才能理解为什么AI应用前端要用流式体验、为什么中断恢复和超时处理那么麻烦。这些全是后面工程化的基础。我在项目里保留了这个最小实现代码不过三十行但把要点全部覆盖了。2.3 第三阶段RAG系统——从检索到生成的完整链路第三阶段是整个项目最核心的部分。RAG的价值在于让模型在不重新训练的前提下获得外部知识核心链路是文档加载、文本切分、向量化、向量存储、相似度检索、Prompt合成、答案生成。这一阶段的目标不是“跑通一个RAG”而是让你能回答出几个灵魂拷问为什么切分大小会影响检索质量为什么有的Embedding模型对中文效果差相似度阈值应该设多少检索到的片段太多反而让答案变差怎么办这些问题的答案都不能靠背必须靠你亲手调参对比才能形成体感。后面我会单独用一章把这个阶段一步一步带大家走一遍。2.4 第四阶段Agent与工具调用——不止是“调用模型”完成了RAG你已经有能力做知识库问答了。但AI工程还有一个重要方向是Agent也就是让模型具备“行动能力”。这里的核心机制是Function Calling函数调用——模型在生成回复时不是直接输出文本而是先输出一个结构化指令告诉你它想调用哪个工具、参数是什么然后系统执行工具把结果返回给模型模型再基于结果继续推理。这一阶段的关键难点有三个工具定义怎么写才能被模型准确理解、多轮工具调用的循环控制怎么避免死循环、以及Agent的“规划能力”边界在哪里。我自己在动手过程中最深的体会是Agent的可靠性远不如RAG。RAG有固定的检索-生成链路输出相对可控Agent的每一步都有不确定性一个工具返回格式没写好整个链条就可能崩塌。所以这阶段要非常重视防御性编程所有工具调用都要做超时、异常捕获、重试限制。2.5 第五阶段评估、部署、观测——工程化的最后三块拼图很多教程到上面就结束了但真正的AI工程至少要再走三步。第一步是评测你需要建一个测试集把十几个典型问题跑一遍观察回答质量没有评测你后面任何改动都无从判断好坏。第二步是部署这里涉及推理服务的选择——直接调API还是自托管开源模型决定了成本、延迟和隐私边界。第三步是观测你要记录每次请求的Token消耗、延迟、检索到的片段、模型的原始输出这些Log是调试线上问题的一手资料。这三个环节最容易被初学者跳过但它们恰恰是“工程能力”和“demo能力”的分水岭。你可能花三天写出了一个能跑通的RAG但如果没做评测和观测上线后用户问了一个测试集外的问题你会完全不知道它为什么答错。3. 实操实录手写一个最小RAG系统讲完路径我直接把这套思路落在一个最小RAG系统的代码上。这个例子我在项目里保留了完整版本这里挑最关键的几个环节来讲每一步都是我实际调过的。3.1 数据准备与切分策略不是所有文本都能直接进模型先准备几份PDF或Markdown格式的文档比如技术手册、产品说明都可以。第一步是加载文档并做文本切分。切分是RAG里最容易被低估的环节切太碎单个片段信息量不足检索时难以匹配切太长容易混入无关内容且占用宝贵的上下文窗口。我常用的经验是普通文档按800到1200字切分相邻片段保留50字重叠。这个量级对于大多数知识库问答是平衡得比较好的。这里有个容易忽略的细节切分必须尊重文档结构。如果文档有章节标题优先按标题切分如果是表格或代码要单独处理。项目里我写了一个简单的方法按段落分割后再按字符长度合并。合并时如果下一段加上当前段落不超过上限就继续合并超过就另起一段。这能让语义相对完整的片段聚在一起而不是硬生生按字符数切断。3.2 Embedding与检索从向量化到Top-K召回文本片段准备好之后第二步是Embedding。Embedding的作用是把文本转换成一个向量让语义相近的文本在向量空间中距离更近。我建议这里不要用OpenAI的Embedding接口而是选一个本地开源的Embedding模型比如BGE系列或智源的Embedding模型原因很简单本地模型不依赖外网便于调试也方便你理解向量化过程。处理完Embedding后把向量存进支持余弦相似度检索的向量数据库——我用的是ChromaDB作为示例实现因为它Python生态最友好能在本地快速运行。查询时把你这个问题也做同样的Embedding然后计算它与所有文档片段的相似度取Top-K。关于K的取值我的经验是知识库问答一般取3到5个片段。取太少可能漏信息取太多会把无关内容塞进Prompt反而干扰模型判断。这里我必须强调一个很多人会踩的坑Embedding模型一定要和查询意图匹配。如果文档内容是中文技术资料就选在中文语料上训练过的模型如果是英文文档选英文专用模型混着用效果会明显下降。我在实际项目中见过不少部署后效果差、反复调Prompt都没用的情况最后发现是Embedding模型选错了。3.3 Prompt合成与答案生成检索到内容后怎么组织检索到相关片段之后最后一个关键环节是Prompt合成。很多初学者在这一步的写法是“将片段拼接后丢给模型”这基本等于把RAG的效果毁掉一半。合理的做法是在Prompt里明确角色的任务、用户的问题、检索到的片段之间的边界并加入一条指令“如果片段中没有足够信息请直接说明不要编造。”分隔符的使用也很关键。我在项目里用document和/document标签把每个片段包起来这样模型能清楚区分不同来源。这里示范一下Prompt模板的写法你是一个严谨的智能客服助手。请仅根据下面的资料回答问题。 如果资料中没有足够信息请明确回复“资料中未找到相关信息”不要自行推测。 资料 document [片段1内容] /document document [片段2内容] /document 用户问题[用户输入]这段代码不是模板而是真正的工程配置。大家注意看这几个设计点一是把“资料中没有则明说”写进系统指令这会显著降低幻觉概率二是用XML标签区分边界长文档混合时尤其重要——我实测过有无分隔符对模型忠实度的影响肯定是有分隔符更稳定。3.4 一个快速评测回答质量怎么量化RAG系统写完后的第一件事不是上线而是建评测集。我当时的做法是准备15到20个问题覆盖三类——能从文档直接找到答案的、需要跨多个片段综合推理的、以及文档中根本没有答案的。跑完一轮后对每个回答做三种标注是否准确引用片段、是否回答了问题、是否出现幻觉。这个评测结果会给你一个量化的基线用这个基线来验证你的切分参数、Top-K取值、Prompt模板修改是不是生效。注意评测靠人工看就行不一定要上RAGAS之类的自动化评测框架。先把人肉评测做起来自动化评测是后续优化时再考虑的事。顺序不能反否则你连信号都没有谈什么优化。4. 工具选型什么时候手写什么时候上框架前面我一直在强调从零手写但这不代表框架没用。实际上一个成熟的AI工程师最终是要在“手写底层”和“框架效率”之间找到平衡的。这个平衡点怎么把握我分享一下自己的选型原则。4.1 三个阶段的选型手写、半框架、全框架我把AI工程实践分成三个阶段。学习期也就是你正在做的这个项目全部手写。这时目标不是效率是理解。生产期早期可以引入轻量级工具比如用LangSmith做链路追踪但核心逻辑仍然手写。当业务规模扩大、链路复杂度上来了再考虑上LangChain或LlamaIndex这类全功能框架。为什么生产期早期仍然不急着上框架因为框架的抽象层会把问题掩盖掉。线上RAG答错了框架把每一步Log都串起来你得先搞懂框架的抽象概念才能定位问题这比你手写的代码多了一层心智负担。我见过一个团队用LangChain做了半年最后排查问题还要靠打断点看源码。所以选型的核心标准是你的痛点是不是恰好能被框架的抽象解决。链路简单时手写代码更可控链路复杂时框架的组件化和生态优势才真正显现。4.2 核心组件的选型对比基于这个项目经验我把经常需要做的几个选型决策整理一下供参考组件类型学习/实验期建议生产期建议选型核心依据Embedding模型BGE系列/智源开源模型按语言和领域测试后定语料匹配度、上下文上限、维度向量数据库ChromaDBMilvus/pgvector数据规模、并发能力、运维成本推理服务API直调vLLM自托管或API成本、隐私、延迟要求编排框架手写LangChain按需引入链路复杂度、团队维护能力看到没有选型不是“哪个火选哪个”而是先明确你处于什么阶段、核心约束是什么。学习期选最易调试的生产期选最匹配业务约束的。4.3 成本与延迟Token消耗怎么算、流式为什么关键最后一个工程化必修课是成本与延迟。算Token消耗是必须的。RAG场景中进入大模型的Token主要由三部分组成系统Prompt、检索到的片段、历史对话。如果每个片段800字、取4个片段加系统Prompt和用户问题单次请求就可能消耗2000到3000个Token。这个消耗你需要按“月活用户 × 平均请求数 × 单次Token数”估算不然月底账单出来会让人非常惊讶。延迟方面除了选更快的推理框架最亲民的办法是流式输出。把首Token时间控制在1秒内整体感知就流畅很多。这里还有一个小技巧检索和用户请求可以并行处理不必等检索完成才开始请求模型。把耗时的检索阶段嵌入到流式输出的前置环节体验提升明显。5. 常见问题与排查技巧实录最后一个部分我直接把项目推进过程中最常撞上的问题和排查思路整理成一个速查手册。这些内容不是从文档里抄的而是我实际调试过的记录。5.1 检索不到先怀疑切分和Embedding而不是模型症状用户问了一个文档里明明白白写着的问题RAG却回答“没有找到”。90%的情况下问题出在切分或Embedding不是模型。优先检查三件事一是切分是否把关键信息切碎了比如“设备故障码A123的说明”被切断成两段导致检索时无法匹配完整概念二是Embedding模型是否和语料语言匹配中英混排英文模型就是灾难三是检索到的Top-K片段里其实包含答案只是相似度排序后被挤掉了这种情况就调整K值或改用重排序。排查顺序很重要先看检索到的片段列表再决定怎么改。用项目里自带的一个小工具直接打印出每个查询的Top-5片段和相似度分数你就能立刻判断问题在检索还是生成。5.2 上下文爆掉窗口管理实战症状对话轮数一多报错说Token超限。根源是历史对话不断累积把上下文窗口占满了。解决思路有三种截断只保留最近N轮最简单但会丢失早期关键信息摘要每轮对话生成摘要存入记忆效果好但增加一次模型调用成本混合策略窗口充裕时保留全文紧张时启用摘要最复杂但最实用。我建议最小实现阶段用截断就够了固定维护最后N轮对话同时把系统Prompt压缩到最精简。项目里我给出了一个按Token数动态截断的实现——不按轮数切而是按Token预算切这样更精确。5.3 幻觉问题引用溯源与约束生成症状模型回答振振有词但内容根本没出现在资料里。治本的方法是“约束生成”加“引用溯源”。约束生成就是我在Prompt里写的那句“资料中没有就直说”同时把Temperature压到0。引用溯源是诱导模型在回答中标注信息来源比如“根据资料第二段的内容答案是……”。做过消融实验之后你就能发现这两者结合幻觉率能明显下降。这里也提醒一句RAG的幻觉没法完全消除只能压制。这也是为什么生产系统里一定要有“不知道”这个兜底选项而不是强行让模型每问必答。5.4 评测集维护回归测试用真实用户问题症状系统改了一个切分参数旧问题还能答几个冷门问题开始答错。这本质是缺少回归测试。解决办法是维护一个持续扩展的评测集——每次上线用户反馈中那些回答错误的问题都要沉淀进评测集。不是新增完就结束还要给每个问题打标签属于检索失败、理解失败、生成失败还是幻觉。这样你每次改动都能看到对哪个类别产生了影响。这一点是这个项目里最容易被跳过但也是价值最高的环节。评测集是AI应用长期迭代的地基没有地基任何优化都是瞎忙活。这个项目做完一遍我对AI工程最大的感受是它没有想象中那么玄乎但也绝不是调调接口那么简单。真正的门槛不在模型本身而在模型外面那一圈工程细节——怎么把知识喂给它、怎么约束它胡说、怎么控制成本和延迟、怎么在出问题时快速定位。这些能力没有捷径只能靠一次完整的、从零开始的实践去积累。如果你最近也想系统性地入坑AI工程我建议你也给自己做一次类似的项目别急着上框架先让整条链路在自己手里跑通一次。那种“原来如此”的顿悟是看多少教程都换不来的。