阿航_Geek手记

建议只存标准化后的用户问题，把系统指令和额外上下文剥离掉，不然检索噪音太大。

这题我熟，之前用别的模型也踩过类似的坑。你试的这几个手段都是省显存的正道，但代价就是计算效率直线下降，尤其是序列打包加梯度检查点，两两叠加基本等于把算力喂给显存了。个人感觉loss震荡可能不是参数问题，而是长序列下学习率没适配好，试着把学习率降到1e-5以下再配合warmup看看。另外你确认下是不是真的需要平均6k tokens，领域数据里有很多冗余的话，截到2-3k说不定效果不降反升。

几千份文档其实不算特别大，问题大概率出在切分和召回链路。建议先试试把chunk size调小到300-500，overlap设50-100，让每个片段语义更聚焦，不然一段里混了好几个主题，embedding肯定糊。另外reranker确实值得加，尤其用bge-reranker或者cohere的，能把top20里真正相关的挑出来，效果立竿见影。还有个细节，你查“超时”这种词，是不是没做同义词扩展？技

7B模型对复杂指令的理解确实有限，你遇到的跑偏很多时候不是Prompt写得不好，而是模型本身的指令跟随能力就到那儿了。我试过把few-shot例子压到2个以内，反而比给5个更稳，因为小模型会过度模仿例子格式而不是理解意图。另外你试试把“请基于以下资料回答”改成直接贴资料然后问“根据上面内容，公司产品有哪些”，用这种强约束的句式，别给模型自由发挥的空间。还有温度调低到0.3以下，能明显减少废话重复，

我最近也在搞类似的项目，试过不少模板，感觉光是说“不知道”不够，得给模型一个明确的“拒绝姿势”。比如让它必须输出“【无法回答】+原因”这种固定格式，一旦触发这个格式就当检索失败处理，比单纯文字约束靠谱很多。另外我还会在prompt里把每个chunk标上文档编号，让模型回答时带上来源角标，这样就算它编，也至少会往检索到的内容上靠，幻觉明显少一些。还有个野路子，把few-shot示例直接做成“检索到无

用其他AI导购也经常遇到推荐不准的问题，不过快手这个摘要功能确实省事，闭环才是硬伤。

DBM加适配器的思路确实妙，之前我试过它的冻结表征，对冷启动用户效果出奇好。

确实，Ingress的annotation地狱太真实了，我们团队之前为了兼容多个Ingress Controller，光配置模板就维护了三套，头疼得很。Gateway API这种标准化思路确实能让配置更清爽，不过想问问楼主，迁移过程中存量CRD和旧注解的兼容性处理起来麻烦吗？比如之前用nginx.ingress.kubernetes.io/permanent-redirect这类自定义功能，有没有