生产级智能体落地指南

我之前也踩过这个坑，后来发现光调chunk和模型不够，得先看文档结构。技术手册里配置步骤经常跨段落，按固定长度切肯定断，试试按标题或语义切，保留点overlap。embedding用bge-m3没毛病，但检索时加个rerank或者混合关键词搜索，效果会稳很多。你问SSL证书返回安装步骤，可能是query和chunk的语义匹配太泛了，加点元数据过滤或者query改写试试。

这个现象其实挺典型的，LoRA微调小数据集时确实容易把模型往垂直领域带偏。rank=8本身不是罪魁祸首，1e-4的学习率配3个epoch在5k数据上反而更值得怀疑，模型可能过拟合到你的问答格式里了，导致原本的指令跟随能力被覆盖掉。我试过类似配置，掉通用能力最明显的就是代码和数学推理，因为这些任务对权重扰动特别敏感。你可以在训练集里混10%到20%的通用指令数据，比如alpaca或者开源的中文指令集

可以试试在项目根目录放个CLAUDE.md写明结构和工具函数，Cline会自动读。

确实，单看推数据这事儿，自己写回调完全够用，我一开始也这么觉得。但MCP的价值我觉得不在传输层，而在于它把“监控什么”和“怎么监控”解耦了——你的训练脚本只负责按协议暴露资源，换监控后端不用改代码。自己写回调的话，每接一个新工具就得改一遍训练逻辑，项目一多就挺烦的。当然如果你场景固定、就一个InfluxDB用到死，那回调确实更省事，没啥本质区别。

这其实不是提示词的问题，也不是工具选错的问题，而是数据处理这类任务本身就对AI不太友好。你想想，Excel表格处理看着简单，但里面全是隐性知识，比如列名的语义、空值怎么处理、日期格式是哪种，这些你自己心里门儿清，但AI完全靠猜。你贴表头给它看，它确实看到了，但它没法像人一样去理解每列数据的业务含义，所以猜错列名太正常了。Cursor和Copilot本质上都是代码补全工具，它们擅长的是写函数、补逻辑

跨章节召回不全大概率不是切块太细的问题，反而是切太碎导致上下文断裂，模型抓不到完整语义。text-embedding-3-small中文其实还行，但几千页PDF解析出来的表格和段落错位才是隐形杀手，建议先抽查一下原始文本质量。混合检索你这个场景绝对值得加，BM25能兜住那些专有名词和缩写的精确匹配，纯向量很容易漏。另外可以试试按标题层级做父子块检索，召回子块但喂给LLM父块，跨章节问题会好很多。

50万条数据用pgvector的HNSW其实够用了，召回混进不相关结果，我觉得大概率是embedding的锅。OpenAI的embedding对“苹果公司”和“苹果水果”这种一词多义本身就容易混淆，换bge-large-zh也未必能根治，因为模型不知道你的业务语境。你可以试试在检索前加一层query改写或者用LLM做意图识别，把“苹果公司”明确成“Apple Inc. 科技公司”再embeddin

试试把NCCL_IB_DISABLE=1加上，4090机器有时就是IB网卡在捣乱。

50并发8张A10够了，但别硬堆batch，试试调小max_num_seqs配合chunked prefill，显存能省不少。

微调确实可能改变模型的表征空间，尤其LoRA动了attention层之后，隐藏状态分布会偏移，检索器拿到的query embedding跟之前对不上了。我之前也踩过类似坑，生成微调后连原始语义相似度都受影响了。建议试试把微调后的模型只用来做生成，检索query还是走原始基座编码，或者干脆把query改写成关键词再喂给bge。

我一般不让Copilot直接补全整段逻辑，只拿它写重复性高的样板代码，比如循环、异常处理这类。防幻觉最有效的办法是把相关模块的代码开在同一个窗口里，它能看到上下文，瞎编的概率会低不少。至于风格问题，我是在项目根目录放个`.editorconfig`和`pyproject.toml`，再配合ruff格式化，基本能压住。不过说实话，涉及业务逻辑的地方我还是逐行看，毕竟它不懂你的数据结构。

同感，把工具定义和few-shot拆成独立轮次注入试试，别全塞系统里，旧记忆被当指令多半是位置太靠前了。

7B参数单卡放不下就FSDP，显存够DDP更省心，MCP上通信开销也得考虑。

API文档这种结构化内容直接按500字切块确实容易把方法签名和参数说明切散，检索出来经常缺上下文。你可以试试按类或方法为粒度切，把方法名、参数、返回值拼成一个完整块，再在metadata里带上类名和继承关系。另外bge-large对代码类文本未必是最优的，可以对比下专门做代码检索的embedding模型，效果可能差挺多。top-k=5可能也不够，API调用往往需要跨好几个方法看，试试加大到10再重

这个问题我也踩过，LangChain的Agent确实容易这样，光靠prompt里写“只调用必要工具”基本没用，模型该乱调还是乱调。后来我改成在工具层面做硬约束，比如把检索工具的description写得更窄，明确说“只用于查询报销、考勤等制度类问题”，反而比在系统提示里唠叨更管用。另外你可以试试把用户信息API单独拆成另一个Agent或者用Router先做意图分类，别让主Agent手里握着一堆它能

我之前也踩过这个坑，光靠Prompt写“忽略无关内容”基本没用，模型分不清哪些是干扰项。后来在检索端加了个bge-reranker做重排，Top-K先拉到10再重排取前3，效果立竿见影。另外Prompt里可以要求模型先逐段标注“相关/不相关”再回答，比直接让它挑有用的稳一些。

几百条数据确实少了点，7B模型很容易过拟合，loss降不代表生成变好。你试试把rank降到4、学习率调到1e-4，再混一些通用指令数据进去，别只喂目标风格那批。另外检查下推理时的prompt格式跟训练时是不是一致，Alpaca模板差个空格都可能让模型犯迷糊。合并权重本身不用额外处理，但建议先单独加载LoRA跑一遍对比，排除合并环节的干扰。

这问题太真实了，我前段时间做合同抽取也踩过一模一样的坑。我的经验是别指望Prompt能兜住所有边界情况，外面套一层校验逻辑基本是必须的，比如指代消解单独拎出来先做一轮，再喂给抽取模型。另外可以试试让模型输出置信度或者reasoning字段，逼它显式说明依据，瞎编的概率会低不少。few-shot确实容易过拟合，示例格式太整齐反而让模型学到表面模式，适当加几个带噪声的反例可能更有用。

这问题挺常见的，Cursor默认就爱加一堆解释性注释，尤其你写中文prompt它就用中文回你。我一般会在项目根目录放个.cursorrules文件，写明“代码简洁优先，除非逻辑复杂否则不加注释，避免中间变量”，比在对话里说管用多了。另外可以试试让它先出方案再写代码，或者直接选中冗余部分按Cmd+K让它精简。实在不行就换Claude模型，感觉它在代码风格上更克制一些。

我也遇到过这问题，Cursor默认会按它训练数据里的最新版本来写，根本不管你本地啥情况。后来我在项目根目录放了个.cursorrules，把Python版本和几个核心包的版本号写死，情况好很多。另外可以在对话开头就让它先跑pip freeze，把结果贴给它当上下文，这样它就不会瞎猜了。不过rules也不是万能的，偶尔还是会飘，关键依赖还是得自己盯一下。