最近科技圈关于“某巨头花天价年薪挖AI人才”“95后技术学霸离职创业”的讨论热度一直很高。很多人盯住的是薪资数字本身但从技术社区视角看更值得拆解的是另一个问题被高薪追逐的AI工程师到底掌握了什么能力如果一位资深后端或算法工程师也想走同样的路甚至准备离职做AI创业他需要补齐哪些技术短板、避开哪些工程坑这篇文章不聊人物八卦也不讨论薪资是否合理而是把这类新闻背后的大模型工程化链路拆开讲清楚。从核心技术栈、创业技术选型、环境准备到一套可运行的“文档智能问答MVP”完整代码再到成本和风险控制尽量做到看完能动手、落地能少踩坑。1. 现象背后的技术逻辑高薪AI人才到底“贵”在哪里1.1 从热搜话题到技术稀缺性每隔一段时间AI领域总会出现几条“高薪挖角”或“技术大牛离职创业”的新闻。如果只看表面会觉得这是人才个人选择问题但如果结合技术市场来看这其实是行业从“PPT演示大模型”走向“规模化落地大模型”的一个信号。前几年团队只要做一个ChatBot Demo或简单调用API就能向管理层证明“我们已经拥抱大模型”。但到了今天单纯调用API已经很难形成竞争壁垒。真正有门槛的工作变成了怎么让模型在特定业务领域稳定工作、怎么控制推理成本、怎么让检索结果可靠、怎么处理私有数据、怎么评估模型上线前后的效果变化。这些工作不是会写prompt就能解决的它需要一套相对完整的工程能力。于是市场上出现了明显的供需错位大量开发者停留在“能调用大模型接口”的阶段但企业真正需要的是能把模型微调、检索增强、部署推理、数据回流串成闭环的工程师。能独立负责这类项目的人才非常稀缺自然会出现高薪争夺现象。1.2 顶级工程师解决的其实是“工程问题”一个常见的误解是AI工程师的收入高是因为他们懂数学公式、懂Transformer结构。这个说法只对了一半。在真实业务中模型结构往往不是瓶颈真正的瓶颈在于如何把大量业务文档清洗成高质量训练或检索数据集。如何让模型在私有知识领域减少幻觉、保持专业口吻。如何用有限的GPU或API预算支撑足够大的并发访问。如何设计一套评测集让模型每次迭代都有可量化的效果提升。如何把处理失败的问题自动识别出来并回流修正。这些问题综合起来对人才的要求远高于“会写Python”或“背过几个模型结构”。它更像是“算法能力 后端工程能力 数据工程能力”的叠加。这也是为什么有能力独立负责AI项目落地的工程师在任何公司都容易拿到溢价。所以如果你也想往这个方向成长与其关注别人拿了多少年薪不如先检查自己的技术栈是否能独立完成一条完整链路数据准备 → 模型微调/检索增强 → 离线评估 → 在线部署 → 效果监控。这也是后文所有内容围绕的主线。2. 顶级AI工程师需要掌握的四条核心链路2.1 模型微调与对齐从通用模型到业务模型很多业务场景只靠通用模型是不够的。比如企业内部的技术问答需要回答中带上公司特有的框架版本、命名规范和部署流程。通用大模型没见过这些私有知识回答就会模糊甚至编造。这时候有两种主流方案微调用一批高质量指令数据继续训练模型让模型学会某种回答风格或特定领域知识。检索增强生成RAG每次提问时先到知识库中检索相关内容再让模型基于检索结果回答。微调适合“调整模型的行为和风格”RAG适合“给模型补充动态更新的外部知识”。两者不是互斥关系很多成熟产品会把两者结合起来先微调出更贴合业务语气的基础模型再用RAG补充最新资料。在微调技术中LoRA和QLoRA是目前工程上最常用的参数高效微调方式。它只训练一小部分低秩矩阵参数显存占用远低于全参数微调效果在很多场景下已经足够。理解LoRA的原理、训练脚本、数据格式是AI工程师的基本功之一。2.2 推理加速与部署把模型变成高可用服务模型训练出来以后还需要面对一个很残酷的问题怎么低成本地把它跑起来。推理阶段最明显的两个瓶颈是显存和时延。一个7B参数的模型用FP16加载需要大约14GB显存如果还没有做量化显存成本会非常高。为了服务更多并发请求工程上通常会用以下手段量化把权重从FP16压到INT8、INT4显存占用和推理速度都能明显改善代价是效果可能略有下降。连续批处理把多个请求动态拼成一个batch提高GPU利用率。KV Cache管理减少重复计算提升长对话场景的吞吐。推理框架优化很多框架对常见模型做了算子级优化可以直接提升吞吐。如果你想走AI工程方向至少要学会把一个开源模型用当前主流的推理框架跑起来并理解“吞吐量”“首Token时延”“显存占用”这几个核心指标。不要停留在只会调用别人封装好的接口层面。2.3 工程化应用RAG与AgentRAG是目前落地最广的大模型应用形态。它的核心思路很简单把企业文档切块并向量化存入向量数据库。用户提问时把问题转为向量在向量库中检索最相关的几个片段。将相关片段注入Prompt让大模型参考这些内容作答。这样做的最大价值在于模型不需要记住所有细节只需要学会“怎么阅读参考资料并回答问题”。当知识库更新时不需要重新训练模型重新索引文档即可。Agent则是更进一步的编排层。它让大模型根据用户意图主动决定调用哪些工具、查询哪些数据库、执行哪些操作。比如“查一下今天订单量并生成图表”在Agent架构中模型会先调用订单查询工具再调用绘图工具。理解Agent的规划、工具调用、记忆管理是AI应用复杂度提升后的必备能力。2.4 数据工程与评估体系大模型项目的天花板往往由数据决定而不是模型决定。微调需要高质量指令数据RAG需要干净的文档切块评测需要覆盖业务常见问题的测试集。一个只停留在“调参”层面的工程师很难把模型效果持续做上去。真正有价值的AI工程师会花大量时间处理数据分布、清洗噪声、设计评测集。评测体系的作用容易被低估。没有评测集你很难判断一次Prompt调整是变好了还是变坏了没有badcase回流机制模型上线后的问题无法被发现和修正。一个成熟的AI应用团队应该像维护自动化测试一样维护模型的评测集。3. 从高薪岗位到离职创业先做技术选型3.1 创业公司与大厂做AI的技术差异如果你考虑离职做AI创业第一条要认清的现实是大厂能烧钱自研基础模型创业公司通常不能。创业公司做AI的正确姿势往往是找到细分场景用成熟的开源模型或商业API快速搭建产品验证真实需求。这个阶段最重要的不是训练一个大模型而是把“数据收集 → 知识处理 → 用户反馈 → 产品迭代”这个飞轮转起来。从技术架构上看创业项目前期应尽量控制基础设施复杂度。能用托管服务就不自建能用Serverless就不买GPU机器。把时间花在用户价值和场景理解上比过早追求“全栈自研”更稳妥。3.2 开源模型选型建议如果你决定使用开源模型需要先理解自己的资源约束。以下是常见选型思路具体版本请以开源社区当前发布情况为准模型规模典型显存参考适用场景说明0.5B ~ 3BCPU/4GB~6GB简单问答、文本分类、日志解析本地可跑响应快但复杂推理能力有限7B ~ 9B8GB~24GB客服、知识库问答、通用对话质量与资源比较均衡14B ~ 32B24GB~64GB复杂指令理解、代码生成、深度分析对部署成本和运维能力要求高70B以上多卡集群强推理场景多数创业公司不建议直接自建这里特别提醒开源模型迭代速度很快不要只看发布时的宣传指标。选择模型时要拿自己的业务评测集跑一遍重点测试中文语义理解、指令遵循、输出格式稳定性。评测结果比参数数量更有说服力。3.3 最小MVP技术栈推荐对于一个“私有知识库问答”类MVP我会推荐一个相对克制但完整的组合向量化模型使用中文语义向量模型如bge-small-zh-v1.5系列。向量存储数据量小时用 FAISS 足够数据量大且需要丰富过滤能力时再引入专业向量数据库。文本切块按标题、段落、句子进行结构化切分避免硬切。大模型推理前期可以接入Ollama本地推理或使用闭源API通过统一接口隔离实现。后端服务Python FastAPI 或 Spring Boot暴露查询接口。这套组合的好处是依赖少、成本可控、代码逻辑清晰适合快速验证产品方向。后面我会用这套组合写一个完整可运行案例。4. MVP实战前准备环境与项目结构4.1 建议环境本文案例是一个基于“检索增强生成”的文档智能问答MVP核心依赖是中文向量模型、FAISS和一个可选的本地大模型推理服务。建议环境如下操作系统Windows 10/11、Ubuntu 20.04、macOS 均可。Python版本3.10或更高。硬件要求CPU可以完成索引和检索如果要体验本地大模型对话需要至少8GB内存推荐16GB以上。推理服务可选Ollama用于本地生成最终回答不想安装时代码也能纯检索模式运行。建议先创建一个独立的Python虚拟环境避免污染其他项目依赖python -m venv venv # Windows venv\Scripts\activate # Linux / macOS source venv/bin/activate4.2 项目结构与依赖创建如下目录结构ai-doc-assistant/ ├── data/ │ ├── spring_security.md │ ├── rag_intro.md │ └── vector_db.md ├── build_index.py ├── query.py └── requirements.txt其中requirements.txt内容如下sentence-transformers faiss-cpu numpy requests安装依赖pip install -r requirements.txt如果你的设备支持GPU也可以把faiss-cpu替换为faiss-gpu对应代码逻辑不变。4.3 准备示例数据为了演示索引和检索效果在data目录下创建三个Markdown文件内容尽量与后面查询问题相关。第一个文件data/spring_security.mdSpring Security 是 Spring 生态中用于认证与授权的主流安全框架。 它通过一组过滤器链完成请求的拦截、认证和权限判断。 在前后端分离项目中通常使用 JWT 实现无状态登录并在 Spring Security 中配置 JWT 认证过滤器。 权限控制方面可以通过 PreAuthorize 注解或自定义 AccessDecisionManager 实现细粒度授权。第二个文件data/rag_intro.mdRAGRetrieval-Augmented Generation是一种结合检索与大模型生成的技术架构。 它的基本流程是先把文档切块并向量化用户提问时检索相关片段再将片段拼入 Prompt 让大模型生成回答。 RAG 适合处理企业私有知识库、产品说明书、客服文档等需要回答准确来源的问题。 RAG 与微调的区别在于RAG 不改变模型参数而是动态补充上下文微调则需要准备训练数据并重新训练模型。第三个文件data/vector_db.md向量数据库用于存储和检索文本的向量表示是大模型知识库常用组件。 常见方案包括 FAISS、Milvus、Chroma、Weaviate 等。 选型时需要考虑数据量、单机或分布式、过滤能力、查询延迟和运维成本。 轻量场景下 FAISS 已经足够它既可以本地运行也不依赖独立的数据库服务。这样准备数据是为了后面可以查询“Spring Security如何做无状态登录”“RAG和微调的区别”“向量数据库怎么选”等相关问题。5. 完整实战从0实现一个文档智能问答MVP5.1 编写索引构建脚本索引构建脚本负责读取文档、切块、生成向量并保存索引。文件路径ai-doc-assistant/build_index.py# -*- coding: utf-8 -*- 将 data 目录下的文档切块并构建 FAISS 向量索引 import pickle import re from pathlib import Path import faiss from sentence_transformers import SentenceTransformer BASE_DIR Path(__file__).parent DATA_DIR BASE_DIR / data INDEX_PATH BASE_DIR / doc_index.bin CHUNKS_PATH BASE_DIR / chunks.pkl EMBEDDING_MODEL BAAI/bge-small-zh-v1.5 MAX_CHARS 500 def split_text(text: str, max_chars: int MAX_CHARS) - list[str]: 将文本按段落拆分为不超长的小块。 优先保留完整段落只有超长段落才做硬切。 paragraphs [p.strip() for p in re.split(r\n, text) if p.strip()] chunks [] current for para in paragraphs: if len(current) len(para) 1 max_chars: current current \n para if current else para else: if current: chunks.append(current) current while len(para) max_chars: chunks.append(para[:max_chars]) para para[max_chars:] current para if current: chunks.append(current) return chunks def load_documents() - list[dict]: 读取 data 目录下的 txt/md 文件并拆分为文本块。 docs [] for file_path in DATA_DIR.rglob(*): if file_path.suffix.lower() not in {.txt, .md, .markdown}: continue text file_path.read_text(encodingutf-8) for chunk in split_text(text): docs.append({ source: str(file_path.relative_to(DATA_DIR)), text: chunk, }) return docs def main(): print(开始读取文档...) docs load_documents() if not docs: print(没有找到任何文档请先在 data 目录中放入 .md 或 .txt 文件。) return chunks [item[text] for item in docs] sources [item[source] for item in docs] print(f共切分为 {len(chunks)} 个文本块开始生成向量...) model SentenceTransformer(EMBEDDING_MODEL) embeddings model.encode( chunks, batch_size16, normalize_embeddingsTrue, show_progress_barTrue, ) dimension embeddings.shape[1] index faiss.IndexFlatIP(dimension) index.add(embeddings) faiss.write_index(index, str(INDEX_PATH)) with open(CHUNKS_PATH, wb) as f: pickle.dump({chunks: chunks, sources: sources}, f) print(f索引构建完成。向量维度{dimension}文本块数量{len(chunks)}) if __name__ __main__: main()这段代码的关键点有三个第一split_text尽量按段落切块避免把语义完整的段落拆碎。第二使用SentenceTransformer生成向量normalize_embeddingsTrue后可以用内积等价表示余弦相似度。第三同时保存文本块和来源信息便于后续查询时定位原文。5.2 运行索引构建在虚拟环境中执行python build_index.py首次运行会下载BAAI/bge-small-zh-v1.5模型权重需要保持网络畅通。正常情况下会看到类似输出共切分为 12 个文本块开始生成向量... Batches: 100%|████████████| 1/1 [00:0000:00, ...] 索引构建完成。向量维度512文本块数量12如果下载模型超时建议先在命令行手动执行一次SentenceTransformer下载或根据实际网络情况配置镜像源。5.3 编写智能问答脚本索引构建完成后查询脚本负责接收用户问题从向量索引中检索相似文本块再通过本地大模型生成答案。文件路径ai-doc-assistant/query.py# -*- coding: utf-8 -*- 基于 FAISS 索引的知识库问答脚本 支持两种模式 1. 纯检索模式只输出命中的知识片段 2. RAG 模式如果本机启动了 Ollama则会基于知识片段生成回答 import pickle from pathlib import Path import faiss import requests from sentence_transformers import SentenceTransformer BASE_DIR Path(__file__).parent INDEX_PATH BASE_DIR / doc_index.bin CHUNKS_PATH BASE_DIR / chunks.pkl EMBEDDING_MODEL BAAI/bge-small-zh-v1.5 TOP_K 3 # 以下参数用于可选的大模型本地推理 USE_OLLAMA True OLLAMA_URL http://localhost:11434/api/chat OLLAMA_MODEL qwen2.5:1.5b def load_resources(): 加载向量模型、索引、文本块和来源。 model SentenceTransformer(EMBEDDING_MODEL) index faiss.read_index(str(INDEX_PATH)) with open(CHUNKS_PATH, rb) as f: data pickle.load(f) return model, index, data[chunks], data[sources] def retrieve(model, index, chunks, sources, question: str): 检索与问题最相关的 TOP_K 个文本块。 query_embedding model.encode( [question], normalize_embeddingsTrue, ) scores, ids index.search(query_embedding, TOP_K) results [] for score, idx in zip(scores[0], ids[0]): if idx 0: continue results.append({ source: sources[idx], score: round(float(score), 4), text: chunks[idx], }) return results def generate_with_ollama(question: str, context: str) - str: 调用本地 Ollama 服务生成回答。 payload { model: OLLAMA_MODEL, messages: [ { role: system, content: ( 你是一个严谨的技术助手。请只根据参考资料回答问题。 如果参考资料中没有足够信息请直接回答‘资料中未找到相关内容’。 ), }, { role: user, content: f参考资料\n{context}\n\n问题{question}, }, ], stream: False, } resp requests.post(OLLAMA_URL, jsonpayload, timeout120) resp.raise_for_status() return resp.json()[message][content] def main(): question input(请输入你的问题).strip() if not question: print(问题不能为空。) return print(正在加载模型和索引...) model, index, chunks, sources load_resources() print(正在检索相关知识片段...) results retrieve(model, index, chunks, sources, question) if not results: print(没有检索到相关内容请调整提问方式或补充知识库。) return context_text \n\n.join( f[来源{item[source]}]\n{item[text]} for item in results ) print(\n 检索片段 ) for item in results: print(f来源{item[source]}相似度{item[score]}) print(item[text]) print(- * 50) if not USE_OLLAMA: return print(正在调用本地大模型生成回答...) try: answer generate_with_ollama(question, context_text) print(\n 模型回答 ) print(answer) except requests.RequestException: print(\n无法连接 Ollama 服务因此只输出检索结果。) print(如果希望使用大模型生成回答请先执行ollama pull qwen2.5:1.5b) if __name__ __main__: main()这个脚本的逻辑可以看作一个简化版RAG流程用户问题先转为向量。FAISS在已有的文档向量中查找最相似的3个片段。如果启动了Ollama就将这些片段作为上下文发送给本地模型。系统Prompt限制模型不要联想到外部知识减少幻觉。5.4 运行与预期结果先启动Ollama并拉取一个小参数模型ollama serve # 新开一个终端运行 ollama pull qwen2.5:1.5b然后执行问答脚本python query.py输入问题请输入你的问题RAG和微调有什么区别如果一切正常会先检索到rag_intro.md中的相关片段相似度分数会在0.5到0.9之间。接着模型会基于检索片段自动组织一段回答大概内容会包含“RAG不改变模型参数、通过补充上下文来实现动态知识引入微调需要准备训练数据并更新模型参数”等关键差异。如果你不想安装Ollama也可以把脚本中的USE_OLLAMA改为False脚本会直接输出检索片段。这样虽然少了一个“生成”步骤但对于验证切块策略和检索效果已经非常有用。6. 如果要做得更专业从MVP到产品的技术演进6.1 数据层增强MVP阶段用几个Markdown文件足够但真实企业知识库往往包含PDF、Word、Excel、网页、数据库记录等异构数据。每种格式都需要对应的解析方案PDF需要提取布局和标题避免文字乱序。Word文档需要保留表格上下文。HTML网页需要过滤导航、广告等噪声信息。数据库内容需要按业务对象组装成一段有语义的文本。在切块层面单纯按固定字符数是粗糙做法。更稳妥的策略是按文档标题层级切分并保留“章节路径”作为元数据。这样检索时不仅能拿到文本片段还能知道这段内容属于哪个章节、哪个产品线方便回答时附带来源链接。6.2 检索层增强纯向量检索的短板在于对关键词和精确短语不敏感。比如代码中的报错信息ClassNotFoundException用语义向量检索可能不如直接关键词匹配可靠。更成熟的方案是混合检索向量检索负责召回语义相似的内容BM25或关键词检索负责召回精确匹配内容两路结果经过合并和去重后再交给重排模型Reranker排序。Reranker会逐条计算“问题-文档片段”的相关性分数能明显提升Top N质量。加入这一层后知识库问答的准确率通常会明显改善但也会增加计算成本和系统复杂度。我建议先在小流量和评测集上验证收益再决定是否投入。6.3 生成层增强生成层需要关注的不只是Prompt还有“模型能力边界”和“人类审核接口”。一个常见设计是要求模型在回答中标注引用编号例如“[1]”。同时在返回数据中附带对应的知识片段ID和原文地址前端可以把引用显示成可点击的卡片。用户看到回答后能直接验证来源信任度会大幅提升。当系统判断回答置信度偏低时不建议强行给用户一个不确定的答案。更合理的做法是主动提示“当前资料不足以准确回答建议人工客服介入”或直接转人工。这种“拒答能力”对B端客户尤为重要。6.4 评测与监控体系从MVP走向正式产品最核心的转折点是建立评测集。建议团队为知识库产品准备三类数据常见问题集覆盖大多数真实用户提问。边界问题集包括模糊问题、多轮追问、错误拼写、超纲问题。回归问题集每次修改Prompt、切块策略或模型版本后全量回归对比。线上还需要记录每一次用户查询、检索片段、模型回答和用户反馈。每天观察badcase按周汇总问题分布再针对性调整数据、检索策略或生成模板。对AI应用来说没有评测和监控体系优化就相当于盲人摸象。7. 离职创业前必须想清楚的工程与成本问题7.1 算力成本模型很多人对AI创业的第一反应是“买卡”。但在产品尚未验证用户付费意愿之前重资产投入风险极高。一个替代思路是分阶段规划验证期用API或小型本地模型按请求付费总成本最低。增长期当调用量足够稳定后评估是继续用API还是用GPU服务器跑开源模型。成熟期对核心场景做推理性能调优例如量化、批处理、缓存再把成本压到可接受范围。无论选择哪条路都应该基于“单次请求成本”来估算。你需要知道每次回答平均消耗多少输入Token和输出Token以及每月预计的请求量。没有这个数字买GPU还是买API都会变成靠感觉拍板。7.2 数据与合规安全做知识库产品时数据合规是第一优先级而不是“等产品上线后再处理”。以下几点需要特别重视用户数据授权任何进入知识库的文档都要确认你是否有权使用和展示。最小权限原则开发和测试环境要使用脱敏后的样例数据不要直接拉取生产客户数据。数据出境与第三方调用如果调用第三方API要明确数据是否会被服务方保存和用于训练必要时通过本地部署或私有化方案规避风险。出口审计AI应用的日志中可能包含敏感信息访问和导出的权限要独立控制。举一个典型场景企业内部做的“知识库问答”如果产品化后服务给外部客户模型会把A客户的信息学习到参数中或检索缓存里导致越权泄露。因此知识库问答系统通常必须在查询维度上做租户隔离绝不能把多租户数据放进同一个索引。7.3 风险控制与降级方案AI服务天然存在不确定性和外部依赖风险。一个稳健的架构应该有降级方案。如果大模型服务突然不可用后端应该能自动切换到“仅检索”模式返回给用户最相关的文档片段而不是让整个问答页面报错。如果某个模型效果不达标应该能在配置中心快速切换回退版本而不是一行一行改代码。向量索引和配置文件都应该版本化一旦召回效果下降可以回滚到上一份稳定索引。另一个容易被忽略的风险是“提示词注入”。当你的知识库中包含用户上传或网络中抓取的文本时这些文本可能包含恶意指令诱导模型输出系统设定之外的内容。因此需要进行输入过滤、输出过滤并对模型权限做限制避免它具备执行敏感操作的Agent能力。8. 常见问题与排查思路我把这套MVP最容易遇到的问题整理成了一个对照表方便大家快速定位。问题现象常见原因解决思路首次运行下载模型超时本机无法稳定访问模型下载源预先下载模型到本地缓存或配置镜像源构建索引时提示没有文档data目录为空或后缀不对检查文档扩展名和目录路径CUDA out of memoryGPU显存不足或batch过大改用CPU或调小batch_sizeFAISS索引与chunks文件不匹配上次构建失败或文件被清理删除两个文件后重新执行build_index.py检索结果完全不相关切块过碎、问题太口语化调整切块长度增加同义词改写或采用混合检索Ollama连接失败服务没启动或端口不对执行ollama serve并确认端口是11434模型返回model not found本地没有对应模型执行ollama pull qwen2.5:1.5b回答出现明显编造内容检索上下文里没有可靠答案调低生成温度增加系统Prompt中的拒答指令中文问题效果不理想使用通用英文向量模型改用中文向量模型如bge系列Python版本太低导致语法错误使用了3.9及以下版本建议升级到Python 3.10在实际排查问题时我会建议按“数据层 → 检索层 → 生成层 → 服务层”的顺序逐层检查。先确认“知识库里到底有没有这个问题的答案”。这一步可以去查索引文本块内容也可以直接跑到向量库里找最相似片段。如果连检索都召回不到正确答案那后续生成质量再高也没用。再确认“检索到了为什么模型答不对”。这时需要看Prompt里参考资料的格式是否清晰有没有被截断有没有混入来源冲突的矛盾信息。最后才检查模型参数和服务稳定性。很多初学者把问题归结为“模型能力不行”但实际案例中绝大多数badcase出在数据清洗和检索策略上。9. 给普通开发者的建议不做看客动手积累9.1 从调用者逐渐走向创造者看到“天价年薪”新闻时普通开发者最容易陷入两种心态要么觉得“这行离自己太远”要么觉得“我随时可以学会”。实际上大模型时代的工程门槛已经比传统深度学习时代降低了很多。过去想做一个像样的NLP应用要从分词、词向量、模型训练一步步来现在开源模型、开源向量库和推理框架已经非常成熟一个普通后端工程师只要愿意花一到两周时间就能把前面这套MVP跑起来。在动手过程中重点不是把代码原样跑通而是要追问几个问题切块策略不同最终回答会有什么差异为什么向量模型要用normalize_embeddingsRAG里检索和生成哪个环节出了问题最难发现如果把知识库换成客服工单、产品说明书、合同条款代码需要改哪些地方每回答一个问题你对AI应用工程化的理解就会深一层。9.2 学习路线建议如果你想系统性地往这个方向成长可以参照下面这条路线掌握Python基础与数据处理能力能够用Pandas、正则表达式处理常见文本数据。了解机器学习基础概念理解Embedding和相似度计算的含义不一定需要从头推导数学公式。学会使用Transformers和SentenceTransformers加载开源模型完成文本向量化和简单推理。跑通一个RAG项目理解切块、索引、检索、重排、生成全流程。尝试用统一接口封装不同大模型供应商做一个可配置切换的后端服务。研究LoRA微调流程用一份公开中文指令数据完成一次小型微调实验。深入推理部署学会量化、批处理、KV Cache等优化手段。参与或自建一个Agent项目理解工具调用和任务编排。这个过程中最重要的是“持续用一个真实场景驱动学习”。如果你在公司可以主动承接内部文档问答、工单分类、日志分析这类小需求。如果没有业务场景就自己造一个把常用的技术笔记、开源项目文档作为知识库做一个私人技术助手。眼下的AI创业窗口并不是只属于“被高薪挖走的人”。每个能完整解决一个业务问题的工程师都有机会把自己积累的数据、场景和工程能力变成产品。关键是不要停留在看新闻、刷热点的状态而是尽早动手把你正在经历的业务问题改造成第一个属于自己的AI项目。未来回看时你会感谢今天开始动手的自己。