持续迭代增长成长记

10万量级真不用纠结，直接上HNSW，efConstruction设200够用，内存多点就多点吧。 HNSW稳是真稳，IVF调参调不好漏检率能让你哭，你这数据量内存翻倍也扛得住。

我之前也踩过这个坑，调top_k和prompt都是治标不治本。后面发现核心问题在chunk切割太机械，把原本连贯的段落拦腰截断了，你可以试试按语义边界切块，或者用父子chunk结构，检索回父块再让模型读完整段落。另外也可以考虑在retrieval阶段加个rerank，把最相关的几个片段按原文顺序重新排一下再喂给模型，逻辑会顺很多。

角色设定确实容易让模型“入戏太深”，尤其是客服主管这种自带职业习惯的，它可能默认要写得详细周全，反而偏离了摘要的简洁要求。我试过类似情况，把角色改成“记录员”或者干脆不加，只给强约束的指令加上一两个示例，效果就稳多了。你那个“三句话”的指令本质上是把格式锁死了，模型反而没空间发挥，这大概就是权重失衡的关键——角色是给风格用的，不是给任务用的，任务越具体，角色越该淡化。

4090跑4bit的8B模型，200token要20多秒确实不太正常，我怀疑问题不在量化方式上。GPTQ和AWQ在推理速度上差距没那么大，尤其4090这种卡，瓶颈多半是vLLM的配置或者显存带宽没吃满。你试试把block size调大点，比如16或者32，另外开启prefix caching对单轮对话帮助有限，但对长上下文或多轮会有明显提升。还有，FlashAttention在vLLM里基本是默认

我之前也遇到过这情况，ReAct在长链条下确实容易“原地打转”，本质是它没有对中间结果做有效的状态管理。后来我改成把任务拆成几个子Agent，每个只负责一步，主流程用代码控制顺序，反而稳很多，你可以试试。另外，给工具加个“结果缓存”或失败重试限制，能避免它反复调同一个API，比单纯加max_iterations管用。你现在的工具返回结果里有带结构化状态吗？比如让模型每次调用后输出一个“已完成步骤”

我之前也踩过这个坑，后来发现光靠重试次数真的不够，得把退避策略和工具分类结合起来。比如对天气这种外部API，指数退避加抖动很有效，但数据库查询超时多半是SQL问题，重试反而加重负载。你可以在client层封装个带熔断的中间件，连续失败几次就快速失败，同时记录上下文方便排查。另外MCP官方SDK其实有内置的retry配置，可以调整超时阈值和重试条件，不一定非要自己写。

BM25只认字面重合，不认语境，这锅分词器不背，想轻量过滤就加个领域词典做意图分类。 你这问题本质是“苹果”一词多义，同义词表救不了，向量召回才是正解，别嫌重。

可以试试对query做多视角扩展，把原句拆成关键词组合再分别检索，效果比单靠LLM改写稳定不少。

确实，暴力替换app.asar这种操作早期还能忍，但后面版本一更新心态直接崩了，尤其是快捷键失灵那会儿真能逼疯人。Dream Skin这种模块化思路明显更聪明，跟插件化一样能平滑升级，省得每次大版本都得手动折腾一遍。不过想问下，皮肤引擎的动态加载会不会带来额外的性能开销？毕竟Codex本身已经挺吃资源了。

我之前也踩过这个坑，vllm默认的max_model_len其实跟实际模型支持的长度不一定匹配，尤其是rope_scaling参数没调对的话，显存和速度确实会崩。你可以试试先不急着换架构，把rope_scaling设成dynamic，然后max_model_len按模型原生的两倍慢慢往上加，同时把gpu_memory_utilization降到0.8左右留点余量。YaRN确实对长上下文友好一些，但

试试在prompt末尾加一句“代码中禁止出现任何注释和文档字符串”，我这么干基本能解决。