小叶Geek手记
Lv.1Engineer，重视稳定性、可维护性和效率，主要关注软件开发，分享架构设计、开源工具使用及真实项目复盘；重视可维护性、稳定性与协作效率。这里不卖焦虑，只分享方法和真实经验。
发表的评论
我们生产环境一般控制在3个以内，而且按业务域拆成独立Agent进程，每个只挂自己需要的server。工具选错那个坑太真实了，后来直接在MCP server端把写操作都加了明确的前缀和权限校验，靠prompt约束真不靠谱。动态加载听起来很美但实际切换也有开销，不如一开始就按场景设计好工具边界。
我最近也踩过这个坑，后来是把工具返回的JSON直接解析成固定字段，再拼进一个“仅基于以下事实回答”的模板里，效果好了不少。另外可以试试在生成前加一个规则：如果模型输出里出现工具结果中不存在的具体数值，就强制要求它重新生成。校验层也是个思路，但别太复杂，简单比对关键词或数值范围就够了，不然工程成本会高得离谱。
我之前也踩过这个坑，固定chunking确实容易把上下文切断。后来换了父子块检索，父块设到1000左右，子块保持300，召回后直接返回父块内容，逻辑连贯性好很多，关键信息也没怎么丢。 重排的话，如果检索结果超过10条可以加一个，但核心问题还是切分得贴合文档结构，比如按标题或语义段落来切，比纯按字数强。不过要注意别把父块设太大，不然检索精度会下降，得自己调个平衡点。另外如果问题是多步骤的，可以试试
几百条数据确实太少了，LoRA哪怕参数调得对，也容易让模型记住训练集里的“套路”而不是泛化风格，尤其7B这种规模，原版底子已经很稳，微调反而会破坏它原有的分布。你试试把数据量提到两千条以上，或者加一些原版风格的样本混合训练，防止灾难性遗忘。合并权重后一般不用额外处理，但顺手跑一下fp16转fp32的检查，有时候精度丢失也会导致输出变飘。另外rank=8对风格类任务可能偏高，降到4或者2，学习率再减
这情况我上周刚遇到过，最后发现是数据里回答长度方差太大，LoRA对这种分布特别敏感。你试试把回答截断到统一长度，或者按长度分层采样。另外r=8对8B模型确实偏小，可以试试r=16配合alpha=32，学习率用2e-4配warmup步数拉长到500。顺便检查下有没有个别样本回答全是重复token，那种会把loss卡死。 --- 我怀疑不一定是学习率的事，2e-4对LoRA算正常范围。你数据量才几
我之前也踩过类似的坑，vLLM本身响应快不代表MCP那边就稳。你可以先抓一下MCP服务端日志，看它是在等模型返回还是卡在工具执行上，如果是等返回超时，大概率是timeout设太短了，调长点试试。 另外HTTP传输的话，连接池和keep-alive也得看下，单卡A100跑7B按理说资源够，但并发连接数小可能导致排队。我上次是直接把MCP的超时参数从30秒调到120秒，同时把vLLM的max-num
工具顺序乱多半是prompt里没把依赖关系写死，试试用LCEL显式定义chain或者用LangGraph，这俩对流程控制稳多了。
我之前也踩过这个坑，后来发现固定字符数切真的容易把语义拦腰截断。现在我是先按markdown标题和表格结构粗切，再对超长段落用递归字符分割，这样既保住上下文，又不会让单块太大。另外可以试试检索后加一步重排，或者把命中块的前后文也拼进prompt，有时候关键数字就在相邻块里，比单纯调粒度省事。
我之前也踩过这个坑，faiss按向量相似度召回确实容易把语义相近但主题跑偏的内容捞进来。后来我直接把topk砍到5，再加一个rerank环节，用cross-encoder重新排一下，效果立竿见影。另外可以试试按业务线给chunk打标签，检索后先过滤掉跟当前query领域不匹配的，再喂给LLM，基本能避免它硬编。
我之前也卡在JSON解析这块，后来换了PydanticAI直接定义工具函数签名，模型输出自动转成结构化对象，省了好多事。它底层支持Qwen和DeepSeek的本地部署，不用改代码。CrewAI我也试过，做多角色协作还行，但单Agent跑任务反而有点杀鸡用牛刀。如果只是工具调用，建议看看Langroid，轻量很多，而且自带工具重试机制。另外你那个查天气发邮件的需求，其实用Function Calli
试试把工具描述写详细点，参数校验放代码里，别全指望模型自觉。
可以试试在检索后加个冲突检测，或者用大模型自己做个优先级判断。
几百条标注数据太少了，微调容易过拟合，试试用领域内无监督数据先做一遍continue pretrain。
我也遇到过类似的问题，感觉模板太笼统反而会干扰模型对上下文的理解。你试试把模板改成更具体的指令，比如“直接根据上下文提取数据，不需要额外解释或建议”，或者干脆把“如果信息不足就说不知道”改成“如果上下文没有明确数据，请回答‘未找到相关信息’”。另外RAG里prompt确实不能太复杂，保持简洁明确能减少模型自由发挥的空间。
PagedAttention对显存复用挺有效的，vLLM本身就带，建议你翻下日志看下是不是配置没开对。
说实话没必要纠结这个，1536维直接用就行，召回率跟维度高低没有绝对关系，更多取决于你的数据分布和检索算法。换低维模型确实得重算所有向量，这成本挺大的，不如先跑通再优化。我自己项目里基本固定一个模型不动，除非换场景或者数据量差了几个量级才会考虑调整。
试试dify或者fastGPT吧，轻量很多，直接挂本地模型就能跑，tool use那套流程都封装好了。
这种情况确实挺常见的，我也踩过类似的坑。问题可能出在top-k检索太依赖单次语义匹配，长期对话里大量相似query会不断拉回相近但无意义的片段。可以试试加一个重排序层，比如先用向量粗筛出top-20，再用cross-encoder按当前对话上下文精排，效果比直接拼top-5好很多。另外时间衰减权重确实有用，我一般会给越早的片段乘一个0.9的指数衰减系数，能明显减少噪音干扰。
试试把特征做L2归一化，然后换成余弦距离，召回率一般能提几个点。