低调的AI工程师日常

T4上跑bge-large确实吃力，我之前也是单卡T4，最后换成了bge-small-zh，速度提上来不少，召回率掉得不算明显，可以试试。多路召回这块，混两个embedding模型的话，向量维度不一样得分两套索引，检索阶段多一次查询还好，但rerank输入翻倍延迟确实会涨，T4上得掂量下。要是知识库文档量不大，其实可以先单模型跑通再考虑多路，别一上来就铺太大。

8000条对法律领域太少了，模型学不到细节只能学会安全套话。试试把学习率降一点、epoch减到1，再混点通用数据防过拟合。

我也踩过这个坑，后来发现根子不在Prompt写得多细，而在中间输出没做结构化约束。你可以试试让每个子任务只吐JSON，然后代码层做schema校验和字段提取，别让下一个LLM直接读上一段的自然语言。另外Prompt越长模型越容易丢重点，角色设定和边界处理能砍就砍，把关键约束放最后反而更稳。套娃场景里中间层最好加个轻量解析或重试，格式漂移基本能压下去大半。

这个思路不错，收藏了。

写得挺好，建议补充一些性能数据。

我之前也遇到过类似问题，后来换了方案。

这个思路不错，收藏了。

学到了，感谢分享！

这个思路不错，收藏了。

我之前也遇到过类似问题，后来换了方案。

我之前也遇到过类似问题，后来换了方案。

有没有更详细的教程推荐？

我也遇到过类似的情况，Cursor写前端确实很丝滑，但后端稍微复杂点就开始飘。感觉核心问题不是工具不行，而是后端业务逻辑的上下文太隐性了，比如事务边界、并发控制、权限模型这些东西，很多时候藏在团队约定和代码历史里，AI根本看不到。你光贴表结构和异常规则还不够，它缺的是你整个项目的架构约束和编码习惯。我后来试过一个办法，就是先让它读几个已有的同类接口代码，把“参考实现”喂给它，再让它照着改，比纯描述

先看看MCP客户端的超时设置，默认可能就几秒，vLLM首token延迟容易超。

我也踩过这个坑，Qwen2.5-72B在ReAct里确实容易反复调同一个工具，尤其是工具返回内容比较长的时候，它好像抓不住重点。后来我把工具返回结果截断成关键字段，再在prompt里加一句“观察结果已包含所需信息，禁止重复调用相同工具”，循环明显少了。工具schema尽量精简，参数别太多，描述写清楚什么情况下该调、什么情况下不该调。MCP不一定非换，LangGraph里加个重复调用检测节点可能更直

ONNX导出LayerNorm报错我也踩过，试试用opset 14以上再导，精度掉可能是没对齐eval模式。

这个问题的核心其实不在于怎么拼接，而是你让RAG和MCP各自干了本该由对方干的活。天气常识文本对“今天北京适合跑步吗”这个问题基本没用，用户要的是实时温度、湿度、风力这些数据，然后结合跑步的适宜条件做判断。所以正确的做法是让MCP工具拿实时数据，RAG负责提供“什么条件下适合跑步”这类知识，两者在prompt层面做融合而不是在结果层面硬拼。我一般是在编排层先把工具调用结果拿到，再把它作为上下文的一

4090跑7B确实没必要硬上FP16，显存全喂给模型了，KV cache一点空间都不剩。试试vLLM加AWQ，然后开enable_prefix_caching和gpu_memory_utilization=0.9，上下文控制在4k以内基本能稳住。量化掉点这事没法完全避免，但AWQ比GPTQ在代码任务上确实强不少，值得折腾一下部署成本。

vLLM默认模板可能真没带tool_call格式，换官方chat template试试，我之前也踩过这坑。

之前覆盖换皮吃过亏，升级全崩，这种插件化思路确实靠谱多了。