推理加速研究笔记

HNSW稳但吃内存，你这数据量直接上HNSW吧，efConstruction设200-400够用，别纠结IVF了。

50万向量真不算大，你这配置单机跑200QPS应该有余量，问题大概率出在IVF_FLAT的探测开销上，nprobe调到64以上并发时CPU肯定炸。既然允许精度损失，直接上PQ或者IVF_PQ，量化后内存占用和计算量都降一个量级，QPS翻倍很轻松。另外建议查下Milvus的线程池和连接数配置，16核机器默认参数往往吃不满CPU。GPU我觉得没必要，先试试把索引换成HNSW再加个缓存层，命中率高的话响

2.x的loss在微调LLaMA里真不算离谱，尤其是生成任务，交叉熵损失本身就偏高，重点得看生成样本的质量而不是数字。你试过调低学习率但没提训练步数，2万条数据跑十几个epoch对LoRA来说可能有点过拟合了，建议试试early stopping或者加大一点rank到16。另外垂直领域问答如果问题模板太统一，模型确实容易学会复述问题，可以混一些通用语料进去平衡一下。 我上次做法律问答也遇到类似情

500条样本对7B模型来说确实偏少，LoRA虽然省显存但数据量不够时loss plateau很正常，我试过类似规模的任务，起码得1500-2000条效果才稳。另外[INST]标记一般不会有大影响，但建议你检查下模板是否和基座预训练格式完全一致，不一致会让模型更懵。你可以先试试把学习率降到1e-4，再加个warmup和余弦衰减，看看loss能不能再往下走一点。如果还是卡住，直接去看生成样本的bad

这个问题我太有感触了，之前用LangGraph做类似的多工具调用时也踩过同样的坑。我的做法是彻底抛弃了把中间结果全塞prompt的思路，改成在外部维护一个显式的结构体，比如用Pydantic定义好每个步骤的输入输出字段，再让Agent每一步只读取当前需要的那个节点数据，而不是把整段历史都摊开给它看。这样token消耗直接降了大概三分之一，关键是“记忆混乱”基本消失了，因为模型每次看到的都是它该看的

第三条太真实了，闭环没反馈的时候，agent跑起来跟开盲盒似的。

试试让模型先输出“检索内容是否相关”的判断再作答，不相关就直接拒答，能压住编造。 温度调到0.2以下，top_p设0.1，再给两个带答案的few-shot例子，稳定很多。

说实话你师兄们的选择已经说明问题了，现在CV方向新论文基本都带PyTorch代码，复现起来省太多事。TF的静态图折腾半天，等你调通别人都跑完实验了。至于大厂算法岗，面试更看重你对模型和原理的理解，框架只是工具，真进去了很多团队也在转PyTorch。移动端部署确实TF有优势，但一般算法岗不背这个锅，那是推理引擎团队的事。先专心把PyTorch吃透，等你能熟练写自定义层和训练循环，再花两周摸下TF的K

我最近也踩过这个坑，后来发现把需求拆成小步骤确实管用，比如先让它生成读取CSV的代码，再单独让它写清洗逻辑，每一步都验证一下。另外给它一个输入输出的具体例子，哪怕是一小段假数据，比说一百句“要完整”都有效。模型随机性没法完全消除，但把任务拆细之后，出错概率会低很多，改起来也容易定位。你可以试试把字段名直接贴给它，别让它猜，错误率能降一半。

我之前也踩过类似的坑，最后发现不是缓存也不是chunk的问题，而是ReAct的prompt里对“当前时间”和“数据更新状态”的暗示太弱了。Agent在推理时其实会优先依赖对话上下文里的旧信息，因为那些token距离更近、权重更高，你新文档就算索引重建了，它也可能在tool selection阶段压根没把“查新文档”当成一个候选动作。你可以试着在system prompt里明确加一句“优先检索最近2

我也踩过类似的坑，折腾半天发现根子可能不在模板本身。Claude对MCP返回的prompt参数解析，本质上还是靠它自己那套自然语言理解逻辑，你光在description里写“必须是字符串路径”其实挺虚的，它未必当回事。我后来是直接在模板里把参数占位符改成更明确的伪代码格式，比如写成`<file_path>这里填绝对路径，不要带引号</file_path>`，效果比单纯描述好很多，Claude至少不

八成是模板把模型的注意力带偏了，先试试只让它直接摘原文数字，别加那些“专业易懂”的修饰词。 你这模板里“建议查看原文”算是给模型指了条偷懒的路，改成强制要求必须引用检索片段里的原句试试。

1亿条768维这个量级，单机跑IVF确实有点吃力了，但也不至于掉到一秒吧。你确认下是不是数据没做归一化或者metric算错了，有时候余弦距离和IP搞混会直接影响索引的搜索效率。另外nprobe按经验调到10-20就差不多了，再高CPU必然爆炸，你不如试试把IVF_FLAT换成IVF_PQ，虽然会有精度损失但速度能拉回来不少，一般推荐场景够用了。 至于分片，单机到瓶颈后肯定得上集群，但Milvus

这问题太真实了，我最近也被折磨过。后来发现最有效的办法是把项目里那些关键决策写进一个专门的“开发日志”文件，每次改需求前先让Agent读一下这个文件再动手，相当于给它一个外部记忆。另外就是每次只提一个非常具体的改动点，别把多个需求混在一起说，不然它很容易自作主张重构。还有个小技巧，如果它改了不该改的部分，直接说“恢复这个函数到上一版”往往比手动回滚快得多。

说实话我踩过类似的坑，现在基本是先把状态依赖关系用文字画出来，比如“部门变化→重置日期和关键字”，然后明确告诉AI不要用useEffect，直接写在事件处理函数里。这样比贴伪代码稳，因为AI对伪代码的理解容易跑偏。另外建议在prompt里加一句“所有联动必须在触发事件内同步完成”，能有效减少多余渲染。

说实话我觉得这真不是玄学，至少不完全算。你观察到的“请”字带来的稳定性，我倾向于理解为它确实在微调模型的“角色预期”——模型内部对“礼貌指令”和“专业角色”的表征是分开的，你加“请”相当于在提示里额外标注了一个“这是社交场景”，模型就会更倾向于激活它学过的礼貌回应模式，而不是单纯靠后面的任务词去猜。 我自己做过类似的小实验，在代码生成任务里加“请”几乎没差别，但在客服、翻译这种涉及人际语气的场景

强烈建议建copilot-instructions.md，比喂代码省心多了，版本锁死它就不乱来了。工具类冲突直接删它生成的，别惯着。

相似度阈值配合时间戳挺管用的，我直接设了个0.95的cosine阈值，查重后再存摘要，目前没影响召回精度。

几十条数据确实太少了，LoRA对这种格式敏感的任务，至少得准备几百条覆盖各种边界情况的样本，而且你的JSON schema里最好把字段名和类型都写成强约束的prompt模板。另外试试把工具定义的描述写得更详细些，比如明确标注“order_id是字符串，不是数字”，小模型对隐含规则的泛化能力真的弱。我之前用7B模型也遇到过类似问题，后来把训练数据里的参数名改成完全一致的占位符，再配合一点点dropo

说实话单卡40G跑6B还爆显存有点意外，瓶颈大概率不在模型本身而在推理框架的显存管理上。我之前用Transformers原生加载也遇到过类似问题，后来换vLLM做continuous batching，5-6路并发显存占用能压到30%左右，生成速度反而更快。Int4量化在A100上收益有限，毕竟显存带宽瓶颈在那儿，不如先试试vLLM的PagedAttention，配置没你想的那么复杂，官方文档有现