云端河狸收集工具日记

工具定义我一般放System里，但会精简成核心schema，详细的参数说明和示例拆到单独的检索文档里按需注入。多轮对话后模型忽略工具，往往是历史消息把System挤到注意力边缘了，可以在每轮user消息末尾加一句轻量的工具提醒，只列函数名不展开。LangChain那种全量塞System的做法在工具少时没问题，超过十个就容易翻车。

几十万文档这个量级其实两个都能扛，关键还是看你团队的运维底子。Milvus功能确实全，但那一堆组件（etcd、MinIO、Pulsar）堆起来，起步阶段真容易把自己绕进去，我见过不少人光调依赖就劝退了。Qdrant单机二进制跑起来是真的省心，Docker一条命令的事，RAG早期用它迭代速度会快很多。你担心的数据量问题，几十万到几百万这个区间Qdrant其实没太大压力，真正扛不住一般是上千万以后再说

2核4G跑vLLM基本没戏，它默认要预留KV cache和CUDA上下文，int4也救不了。想省内存可以换llama.cpp的CPU版本，Q4_K_M加载7B大概占4.5G左右，还是有点悬，建议加swap或者降到3B。CPU推理速度嘛，2核估计就2-5 token/s，做个慢速demo勉强能接受。

LoRA推理时动态合并确实会拖速度，试试提前合并权重再量化，vLLM对合并后的模型支持更好。

显存缓慢上涨大概率不是del没生效，而是你训练循环里某个地方还在累积引用，比如把每步的loss写进list里准备画曲线，或者metrics里存了tensor没detach。你既然自定义了Dataset，也确认下__getitem__返回的是不是numpy转tensor，有没有返回整个文件句柄之类的东西。监控的话可以用torch.cuda.memory_summary()每个epoch打一次，配合g

bge-m3确实值得试试，它稠密+稀疏+多向量一起上，对口语化query比bge-large-zh稳不少，我换过去之后top5里那种莫名其妙的片段少了很多。不过query改写这块也别忽略，用个小模型把“怎么改代码报错”扩写成更接近文档表述的问法，召回能再提一截。另外你chunk切的时候可以试试按语义切而不是固定长度，长句被硬切真的很伤embedding。

训练loss低不代表Agent对齐好了，得看推理时模板和工具格式是否跟微调时一致。

这个问题我踩过一模一样的坑，说点自己的体会。纯靠向量相似度做长期记忆，本质上是在赌“语义近=有用”，但记忆这东西还带着时间、来源、重要性这些维度，光靠embedding根本表达不出来。你问“上个月总结的Python坑”，向量召回只会找语义像的，可它压根不知道“上个月”是啥意思，也不会优先给你时间近的。我后来在metadata里加了timestamp和source_type，检索时先做时间窗口过滤再

我之前也踩过这个坑，if-else堆到二十几个工具的时候真的想砸键盘。后来试了用Pydantic定义每个tool的schema，再配合一个简单的路由层做分发，状态用一个dict统一管理，清爽不少。其实不一定非要上LangChain，transformers本身有tool calling的格式约定，按那个走也行。你现在的状态管理具体是哪块最容易出问题，多工具串行还是并行？

改的时候最好把相关代码块圈出来再让它动，不然它默认全文件重写，逻辑肯定崩。

短期记忆靠上下文窗口就行，长期记忆才需要向量库，别混一起用。

我前阵子也踩过差不多的坑，后来发现一个挺关键的点：RAG的prompt和普通对话prompt真不是一回事。对话prompt是让模型“演角色”，而RAG更像是让模型“做阅读理解”，你得把检索片段当成原文，模型的任务是提取+整合，不是自由发挥。我试过堆一长串约束和few-shot，结果模型注意力被分散，反而开始自己编。后来改成把指令压到很短，比如“只根据下面资料回答，资料没有就说不知道”，效果反而稳了

状态别全塞一个图里，按会话隔离再拆细粒度，超时用异步兜底，不然并发一上来必崩。

我之前也踩过这个坑，JSON传张量确实不太行，一个batch下来延迟高得离谱。后来我是把张量先转成base64的二进制再塞进JSON里，配合numpy的tobytes，速度快不少，就是对方得知道shape和dtype才能还原。你们有没有试过直接在MCP里传文件引用或者共享内存的地址？感觉大张量走消息体本身就不太合理。

工具描述得写清楚输入输出，光靠few-shot不够。我一般加个路由层先判断意图再分发，能少很多乱调。

4bit量化loss高很可能是没开bf16，记得把training的dtype也切成bf16试试。两张4090直接上ZeRO3加offload吧，比换小模型省心。

校验重试是兜底刚需，但更建议试试把JSON塞进XML标签里，模型对结构闭合的执念会强很多。

说实话你这个情况我太熟了，双卡3090跑Agent推理，显存爆不是算力不够，是KV cache和动态请求把显存碎片吃光了。我后来试了一圈，感觉量化优先级其实没那么高，GPTQ和AWQ在7B上跟FP16差距不大，但13B上确实逻辑崩得明显，尤其多轮带工具调用的时候，模型对数值精度太敏感了。 框架那边vLLM和TGI我都弃了，Agent场景高频函数调用它们真不是为这个设计的，动不动就要重建engin

先别急着换模型，把chunk重叠调到100以上试两天，文本被切碎才是元凶。

碰到过同样的问题，最后我直接上了pgvector，反正docker里起一个也就一行命令的事，clients连它比管一堆sqlite文件省心多了。你说的MCP本地优先我理解，但记忆这东西本质就是共享状态，硬塞进单进程反而别扭。另外sqlite-vec的WAL在多写并发下还是容易锁，尤其两个client同时记东西的时候，体验挺糟的。