企业级RAG落地指南

我也遇到过这问题，Cursor确实容易越改越乱。后来我干脆把要改的文件单独复制到一个临时目录里，让它在那边操作，完事再手动合并回去。另外用.cursorrules文件写死几条硬规矩，比如禁止改动service层签名，比在prompt里临时强调管用多了。不过说到底code review还是得做，AI改完我基本都会git diff过一遍才敢提交。

操作步骤类问题光靠稠密向量确实容易飘，试试加BM25做混合检索再重排，往往比换模型管用。

这问题太真实了，我上个月也踩过一模一样的坑。MCP本身只是个协议层，它管的是怎么把工具暴露给模型调用，至于向量库那边索引怎么更新、切片怎么重跑，它压根不掺和，所以你现在这个半自动状态其实挺正常的，不算姿势不对。我当时的做法是在文档源那边加了个webhook，文件一变更就丢进消息队列，后台consumer负责重新切片和upsert，MCP那层只负责查询，更新链路完全解耦出去。增量的话可以看下你用的向

小batch微调JAX真不占优，编译开销大还容易把收益吃掉，先试试把step包进jit别反复重编。

这问题太真实了，我上周让它写个Redis连接池，直接给我整出个`redis.connect_pool_async()`，文档里翻半天根本没这玩意。感觉模型对主流框架的API记忆就是半桶水，风格模仿得越像越容易让人放松警惕。我现在养成的习惯是让它先只写函数签名和注释，确认调用的库方法真实存在后再让它填实现，能省不少返工。另外可以在prompt里贴官方文档片段或者明确说“只用标准库和已安装依赖”，稍微

5万条指令这规模，rank影响确实不明显，瓶颈更可能在数据质量上。

1. 这明显是数据标签太糙，类间边界没划清，先查标注一致性吧。 2. loss降但效果差，多半是学偏了，试试把rank砍半或者加验证集早停。 3. 建议看下预测错例的置信度，可能是数据分布不均，建议重采样。

先确认下是不是真把显存吃满了，nvidia-smi看下峰值，我怀疑是KV cache的预留和prefill峰值叠加了。max_model_len设4096但并发请求多的话，每个请求的prefill显存是动态分配的，A100 80G理论够但vLLM默认的chunked prefill可能没开，建议试试加--enable-chunked-prefill。另外tensor_parallel_size=1

试试把每个片段前面加个“来源N：”标注，再让模型逐条判断相关性，比一股脑拼接强多了。

我之前也卡在这块很久，后来发现关键不是让模型“别做什么”，而是明确告诉它“每步该输出什么”。比如把“总结再行动”改成“先输出JSON格式的总结字段，再调用工具”，稳定性会好很多。另外，别指望一套Prompt通吃，不同模型对指令的敏感度差异挺大的，我一般会先拿三个典型case去测，看它在哪一步容易跑偏，再针对性加约束。你试过把few-shot例子按“错误示范+正确示范”的对比结构写吗？感觉比单纯给正

建议用同一条prompt在不同模型上跑同一批测试集，看输出差异点再针对性加约束，比盲目堆few-shot效率高。 每个模型对指令的敏感点不一样，干脆按模型类型各维护一套模板，反正开源模型更新快，通用设计原则追不上版本变化。

你这问题太典型了，Agent跑长链路就是容易“断片”，建议把每个步骤的结果强制存成文件再传给下一步，别让它靠上下文记。 多步任务还是别全指望Agent，试试用代码把流程串成管线，只在每步出错时让Agent来修，稳定得多。

之前调过类似的，bge-m3确实偏重，可以先量化一下模型或者换个小点的embedding，速度能提不少。FAISS几万条其实不算慢，瓶颈多半在embedding推理上，建议用缓存或者异步预计算。MCP那边可以自己加个简单的LRU缓存，query相似度高的直接复用结果，能省一大截时间。另外pgvector如果走索引，性能未必比FAISS差，但运维省心，看你们团队熟悉哪个。