通用AI助手ChatGPT、Claude等已经在全球多个市场的应用榜单头部占据固定位置。对普通用户来说它们是搜索、写作、编程的默认入口对开发者来说它们是同一个API背后的巨大能力池。问题是当通用模型能力快速趋同中小开发者再做一个“像ChatGPT一样聊天”的产品几乎没有胜算。真正的机会反而在更窄的地方把AI放进某个行业的具体流程用私有知识、业务规则和结果闭环做出通用助手不愿意做、也做不好的产品。下面先看通用AI的内卷到底卷在哪里再给出垂直场景的筛选方法接着用一个“内部技术资料问答助手”的最小可运行项目演示RAG落地最后讨论评测、排查和生产化改造。这套思路既适合独立开发者也适合小团队在现有业务系统里增加一个AI入口。1. 通用AI内卷的本质能力趋同之后竞争转向成本和规模1.1 头部助手抢占“通用入口”中小开发者的通用聊天产品越来越难做ChatGPT、Claude这类产品能在全球多市场畅销榜头部站稳靠的不只是模型能力强还包含了多端同步、免费额度、插件生态和品牌信任。用户已经习惯了这些产品作为“通用问答入口”这时候再做一个开放对话助手无论底层接哪个大模型用户都很难感知到差异。中小开发者遇到的问题不是“模型不够好”而是模型能力已经变成标准件。调用同一个API、写同一套提示词出来的体验高度相似。最后能竞争的只剩价格、界面和投放而这些恰恰不是小团队的优势。通用AI的内卷本质是能力趋同之后竞争从“模型效果”转移到了“算力成本”和“渠道规模”。在这个维度上独立开发者和中小团队很难赢。1.2 通用助手在垂直场景里并不“聪明”通用助手擅长开放问题不擅长“限定业务范围”的问题。它知道“设备无法开机可以先检查电源”但它不知道你所在公司手册里写的故障码含义也不知道这张工单应该流转给哪个班组更无法直接查询历史维修记录。对比维度通用AI助手垂直AI助手知识范围互联网公开知识企业私有文档、历史案例、业务规则权限控制基本没有可以按角色、部门、项目做细粒度隔离结果可信度内容流畅但无法溯源答案必须能引用资料和来源交付方式聊天窗口嵌入业务系统、生成工单、回写状态评测标准主观打分命中率、准确率、拒答率、耗时所以垂直场景的机会不是“模型更强”而是“答案更准、来源可查、结果能对业务负责”。这种产品不需要比ChatGPT博学只需要在一个足够窄的领域里比它可靠。1.3 垂直场景的“正确答案系统”才是机会通用模型适合“开放问答”垂直产品适合“限定域问答加任务执行”。对中小开发者来说最值得做的方向包括企业内部知识库问答、售后故障诊断、合规审核、领域创作辅助、设备运维助手等。这些场景有一个共同点正确答案是可验证的。既然答案可验证就可以建立评测集不断衡量产品变好还是变坏既然答案可溯源用户就愿意信任既然信任建立起来业务的闭环才可能发生。ChatGPT、Claude再强也不会替某个企业长期维护一份专属故障知识库更不会把回答结果回写到工单系统里。2. 垂直场景突围先用“三有”标准筛项目再谈技术2.1 有数据、有流程、有代价很多人在选垂直场景时只问“AI能不能做”其实更关键的是先问“这个场景有没有商业和技术上的承接条件”。可以按“三有”标准做初筛。有数据是否能够合法地拿到足够多的领域数据比如操作手册、FAQ、工单记录、历史案例。有流程用户的使用流程是否稳定。问完AI之后下一步是查工单、开审批、写报告还是只停留在聊天。有代价回答错误会不会带来明确损失。比如售后误判可能多派一次上门合规误判可能产生罚款。代价越明确用户越愿意为准确率付费。没有数据技术再强也跑不起来没有流程AI只能停留在聊天层面没有代价用户很难为“更准”付费最终会把它当成一个可有可无的玩具。2.2 从“聊天”到“闭环”的三个价值层级垂直助手的价值可以分成三层不是每一层都要一步到位但做产品时应提前规划。层级形态价值难度L1问答客服可以更快找到答案低L2问答加引用用户能核实答案依据可信度大幅提升中L3问答加执行加回写AI直接创建工单、生成报告、更新知识库高L1 是大多数RAG项目的起点但也是竞争最激烈、边际价值最低的形态。L2 必须做因为垂直助手如果没有来源引用就很难和通用助手拉开差距。L3 才是真正的壁垒因为它需要接入业务系统涉及权限、流程和异常处理这些都不是靠一个更大的模型能替代的。2.3 一个适合练手也适合上线的选题内部技术资料问答助手内部技术资料问答助手是典型的“三有”场景产品手册、维修记录、FAQ都是现成数据售后、客服、运维用户有清晰提问路径答错会产生误判和额外工单因此用户愿意接受“必须有引用来源”的限制。这个选题还适合作为第一个垂直AI产品验证。它不需要海量历史数据一份产品手册就能跑通业务价值清晰能直接缩短新员工培训时间错误影响可控回答时只要带上资料名称客服可以二次确认。更重要的是这个项目可以平滑扩展成“售后故障诊断助手”或“运维知识库”不需要推翻重做。3. 最小闭环用RAG构建“技术资料问答助手”3.1 技术选型为什么用RAG而不是继续调“更大模型”RAG检索增强生成核心流程是先检索再生成。用户提问后先从知识库里检索最相关的片段再把这些片段和问题一起交给大模型生成回答。RAG 对垂直场景的价值非常明确知识更新快。文档变化后重建向量库即可不需要重新训练模型。来源可追溯。回答可以引用文档名称和原文片段。私有数据可控。文档不需要进入大模型训练集。幻觉更容易被约束。Prompt 里明确“只根据资料回答”能显著减少编造。模型选型可以用本地模型配合 Ollama这样数据不出内网也方便后续私有化部署。文本向量化、生成模型、向量库和API层都要在项目初期就确定否则后面替换成本很高。组件选型建议说明运行环境Python 3.10 或 3.11语言和依赖生态稳定模型运行Ollama本地拉起模型适合内网部署文本向量化nomic-embed-text中文项目建议换成更好的中文embedding模型生成模型qwen2.5:7b中文效果较好资源占用中等文档解析LangChain TextLoader / PyPDFLoader企业场景可叠加OCR和结构化解析向量库Chroma轻量起步数据量大后可迁移到Milvus或pgvectorAPI层FastAPI便于对接前端和业务系统3.2 环境和项目结构建议先建虚拟环境再安装依赖。以下命令适用于 Linux 和 macOSWindows 下激活虚拟环境的命令改为.venv\Scripts\activate。python -m venv .venv source .venv/bin/activate pip install langchain langchain-community langchain-core chromadb fastapi uvicorn ollama接着拉取需要使用的基础模型。embedding模型用于向量化生成模型用于最终回答。ollama pull nomic-embed-text ollama pull qwen2.5:7b项目目录可以按下面的结构组织rag_assistant/ ├── app.py ├── build_kb.py ├── api.py ├── requirements.txt ├── docs/ │ ├── product_manual.txt │ └── faq.md ├── chroma_db/ └── eval_set.json目录结构不需要一开始就很大但要分清楚“构建知识库”“加载问答链路”“对外API”三个模块。后面调试和升级时这种拆分能省很多时间。3.3 构建知识库文档加载、切分、向量化知识库构建是整个RAG项目的基石。文档加载失败、切分不合理、embedding选得不对都会直接造成检索结果变差。下面是一个最小的知识库构建脚本默认读取docs目录下的文本文件。# build_kb.py from pathlib import Path from langchain_community.document_loaders import TextLoader from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma from langchain_text_splitters import RecursiveCharacterTextSplitter docs_dir Path(docs) all_docs [] for file in docs_dir.glob(*.txt): loader TextLoader(str(file), encodingutf-8) all_docs.extend(loader.load()) splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, separators[\n\n, \n, 。, , , , , , ], ) chunks splitter.split_documents(all_docs) embedding OllamaEmbeddings(modelnomic-embed-text) vectorstore Chroma.from_documents( documentschunks, embeddingembedding, persist_directory./chroma_db, ) print(f向量库构建完成共 {len(chunks)} 个片段)这段代码里最关键的是文本切分。chunk_size500表示每个片段控制在500字符左右chunk_overlap80表示相邻片段有80个字符重叠。重叠的目的是避免一个完整语义被硬切成两段。中文场景不要只按空格切可以把句号、问号、感叹号、分号、逗号都加入分隔符。注意Chroma.from_documents的persist_directory参数在不同版本中可能有差异。实际落地前先确认你使用的 chromadb 版本优先按当前官方文档调整。如果文档是 PDF可以把TextLoader换成PyPDFLoaderfrom langchain_community.document_loaders import PyPDFLoader loader PyPDFLoader(docs/product_manual.pdf) pages loader.load()PDF解析在扫描件场景下会失效需要先接 OCR。这里先不展开但项目进入生产前必须把“文档解析成功率”作为一个监控指标。3.4 检索增强生成把检索结果塞进Prompt构建完向量库后下一步是组装问答链路。查询时先通过向量检索拿到最相关的片段再把这些片段作为上下文交给大模型。# app.py from langchain_community.chat_models import ChatOllama from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma from langchain_core.output_parsers import StrOutputParser from langchain_core.prompts import ChatPromptTemplate from langchain_core.runnables import RunnablePassthrough embedding OllamaEmbeddings(modelnomic-embed-text) vectorstore Chroma( persist_directory./chroma_db, embedding_functionembedding, ) retriever vectorstore.as_retriever(search_kwargs{k: 4}) llm ChatOllama(modelqwen2.5:7b, temperature0) template 你是售后技术知识库助手。请只根据下面的资料回答问题。 资料 {context} 问题 {question} 要求 1. 如果资料中没有明确答案请回答资料中未找到相关信息请提供更多关键词。 2. 不要编造数据和操作步骤。 3. 回答尽量简洁并给出资料来源文件的名称。 prompt ChatPromptTemplate.from_template(template) rag_chain ( {context: retriever, question: RunnablePassthrough()} | prompt | llm | StrOutputParser() ) if __name__ __main__: print(rag_chain.invoke(设备无法开机怎么办))这里把temperature设为0目的是降低回答的随机性。垂直助手更需要稳定输出而不是每次给出不同表达。k4表示每次取4个最相关片段片段太少可能漏掉答案太多会让模型被无关内容干扰实际项目里可以按准确率调成3到6之间的值。Prompt 的作用也很关键。RAG 不是简单把资料拼接进去而是要在提示词里限定模型“只根据资料回答”并要求在资料缺失时明确拒答。这样做不能完全消灭幻觉但能把幻觉控制在一个容易发现的范围内。3.5 对外提供API问答链路组装好之后可以直接在脚本里测试但真正进入业务场景需要对外暴露API。用 FastAPI 包一层即可。# api.py from fastapi import FastAPI from pydantic import BaseModel from app import rag_chain app FastAPI(title内部技术资料问答助手) class AskRequest(BaseModel): question: str app.post(/ask) def ask(req: AskRequest): answer rag_chain.invoke(req.question) return {question: req.question, answer: answer}启动服务uvicorn api:app --host 0.0.0.0 --port 8000学习环境可以加--reload参数这样修改代码后会自动重启。生产环境不要这样用后面会单独讲。4. 运行验证与问题排查垂直助手好不好不能靠“感觉”4.1 先做一次手动验证服务启动后用 curl 发一个查询请求curl -X POST http://127.0.0.1:8000/ask \ -H Content-Type: application/json \ -d {question: 设备无法开机怎么办}预期结果有两种一种是回答中包含知识库里的故障排查步骤另一种是明确回答“资料中未找到相关信息”。如果返回的是一段泛泛的通用建议说明检索到的上下文没有被模型正确使用或者知识库里根本没有相关文档。验证时不要只看最终答案。建议在rag_chain中间加一层日志打印检索到了哪些片段、每个片段来自哪个文件。这样能够快速判断是“没检索到”还是“检索到了但没回答好”。4.2 建立最小评测集垂直场景必须知道哪些问题是必须答对的。不能凭感觉说“回答得不错”要把关键问题固化成一个评测集。[ { question: 设备无法开机可能有哪些原因, expected_keywords: [电源, 保险丝, 主板], expected_source: product_manual.txt }, { question: 如何升级固件, expected_keywords: [U盘, 固件包, 恢复模式], expected_source: faq.md } ]评测脚本不需要很复杂核心逻辑是遍历问题、调用链路、检查关键词是否出现在回答中def evaluate(eval_set, chain): for item in eval_set: answer chain.invoke(item[question]) missing [kw for kw in item[expected_keywords] if kw not in answer] print(item[question]) print(缺失关键词:, missing if missing else 无) print(---)这个评测集是垂直助手最重要的数据资产。模型可以换知识库可以改prompt可以调但评测集要一直保留用来判断每次改动是变好还是变坏。4.3 看四个核心指标垂直助手上线后建议每天关注四个指标。指标含义起步建议检索命中率正确文档是否出现在检索结果前k个目标至少70%以上答案准确率回答与事实是否一致需人工抽检越高越好但允许拒答拒答率回答“资料中未找到”的比例不该拒答时拒答说明知识库覆盖不足延迟从请求到返回的耗时内部工具可接受10秒内对外要尽量低于3秒准确率和拒答率需要结合看。如果拒答率长期很高不代表模型变差了更可能说明知识库覆盖不够用户问的问题没有被切分或筛选出来。如果拒答率太低同时准确率也在下降说明模型开始“硬答”这是更危险的状态。4.4 常见问题排查RAG项目最常见的坑集中在检索、Prompt、模型参数和向量库更新上。问题现象常见原因检查方式解决建议检索结果不相关chunk过大导致语义被稀释、embedding模型与中文不匹配、文档加载失败打印chunks数量打印检索到的前几个chunk换中文embedding模型调整chunk_size增加文档预处理回答出现幻觉Prompt没有限定资料、温度过高、上下文没被正确注入打印context和prompt模板使用明确指令“只根据资料回答”temperature设为0增加后置校验同样问题每次回答不同温度过高、检索结果不稳定多次调用观察降低temperature固定检索k值测试时记录检索结果文档更新后向量库没变化没有重新建库或增量写入查看chroma_db目录和chunk数量重建向量库或给文档增加版本号和时间戳本地模型回答太慢CPU推理、模型过大、向量检索慢查看Ollama日志观察耗时分布换更小模型使用GPU推理接入云API增加缓存注意不要只验证程序能启动还要验证“正确文档是否被检索出来”“该拒答的问题是否拒答”“更新文档后结果是否同步变化”。这些才是RAG项目能否长期稳定运行的真正检查项。5. 从演示到生产中小开发者要补的工程能力5.1 私有数据安全与权限隔离Demo阶段可以不管权限生产环境必须管。内部技术资料问答助手的核心是私有数据所以权限隔离不能放在回答之后而要在检索之前完成。也就是说用户问“A项目的故障记录”系统要先判断该用户是否有权限查看A项目资料再决定把哪些文档纳入检索范围。不能让模型先检索全量资料再在回答时过滤这样既危险又不可靠。另外建议做这几件事对上传文档按目录、项目或部门打标签。用户提问时带上身份信息检索链路按身份过滤数据范围。对敏感文档做访问审计记录“谁在什么时间问了哪些问题系统检索了哪些文档”。明确知识库数据的使用边界不在未经允许的情况下把问答记录用于模型训练。5.2 日志、监控与成本治理生产环境至少要记录四类信息请求内容、检索结果、模型回答、耗时和反馈。有了这些日志才能复现问题也才能持续构建评测集。每个/ask请求都建议记录{ user_id: u_001, question: 设备无法开机怎么办, retrieved_docs: [product_manual.txt_chunk_12], answer: 先检查电源线和保险丝再检查主板指示灯。, latency_ms: 3200, feedback: useful }成本治理方面本地模型是固定资源成本云API则按token计费。无论哪种方案都要优先减少无效计算。对于高频重复问题可以直接加一层缓存对于知识库已有明确答案的简单查询可以跳过大模型生成直接返回标准化答案对于超出范围的问题优先拒答而不是硬答。5.3 从单助手走向多工具和多Agent垂直场景不会停留在问答。一个售后技术问答助手最终要能自动查询工单、生成故障报告、把维修工单派给对应班组。这里不建议一开始就引入复杂Agent框架而是先做意图分流。def handle_question(question): intent classify_intent(question) if intent faq: return rag_chain.invoke(question) if intent create_ticket: return ticket_api.create( titlequestion, sourceai_assistant, ) if intent check_order: return order_api.get_status(question) return 当前版本还无法处理该请求意图分流的好处是稳定可控每个分支都可以单独测试和回滚。当单条链路表现稳定后再逐步引入工具调用、多轮规划和状态管理。对中小开发者来说技术上的“新”不是第一优先级业务的“稳”才是第一优先级。6. 突围后的护城河持续积累评测集、领域知识与用户反馈6.1 垂直场景的资产是“数据飞轮”不是模型权重大模型会持续迭代今天调用的模型明天可能被更强的模型替代。但垂直助手真正沉淀下来的资产是评测集、历史问答对、用户反馈、业务规则库和文档间的关联关系。这些数据有很强的领域属性。通用助手不会替某个企业长期维护“哪类故障常见、哪段回答被用户标记为无用、哪个文档已过期”这些信息。中小开发者如果能持续积累即使底层换模型产品价值也不会归零。6.2 每周迭代节奏垂直助手要用版本迭代的方式持续优化而不是一次性交付后就不管。建议按下面的节奏运作每周收集真实问题标记为“答对”“答错”“该拒答未拒答”“不该拒答却拒答”。把错误样本加入评测集至少保证每个错误类型都有对应用例。修复知识库问题比如补充缺失文档、修正切分方式、优化embedding。调整Prompt或检索参数后跑一次完整评测集观察指标变化。发布版本记录改动日志和指标变化。这个过程看起来简单但大多数垂直AI项目都会在“没有评测集”的情况下反复改Prompt最后无法判断哪个改动真正有效。6.3 可复用的开工检查清单如果要用同样的思路做其他垂直场景可以按下面的清单逐项确认场景是否有明确用户和付费方。是否有可合法使用的领域数据。是否正确答案有清晰边界比如“哪些问题必须答对”“哪些问题必须拒答”。是否已经建立最小评测集。是否明确权限和数据安全边界。是否规划了日志、监控和反馈入口。是否设计了回答之后的业务闭环比如建单、派单、报告生成。是否预留了模型升级和知识库更新的运维路径。通用AI再强也只会让垂直场景玩家的门槛变低而不是变高。中小开发者真正的壁垒不是模型而是“知道这个行业哪里会答错”的经验以及随之积累的数据和评价体系。与其追着ChatGPT、Claude的新版本做同质化工具不如先去一个具体行业里把一本手册、一组FAQ和一个能让用户点击“这个回答有用”的界面做扎实。