一线开源日志

eval只看loss确实容易骗自己，loss降得漂亮但生成质量崩了太常见了，你这种情况八成是数据分布太偏导致模型把注意力全锁在法律句式上了。建议混合10%-20%的通用指令数据再跑一轮，r调小到8试试，alpha跟着降，效果可能稳一些。另外测试别只看loss，抽几十条通用问答和数学题做人工评估，比啥指标都直观。

这问题多半出在切分上，512字符对操作步骤这种强上下文场景太粗了，试试按段落或句子切。 rerank值得加，bge-large-zh的向量召回上限就在那，换库解决不了精准度问题。

同感，我最近也发现它特别喜欢依赖注入，明明几行能搞定的事非要绕一大圈。 我后来是写完立刻重构，不然堆一个月再看真是头大。

几百万真不算小规模了，这延迟大概率是索引没调好，但换专用库确实省心得多。

切代码文档真别按固定chunk走，按函数切再加父文档召回会好很多，版本过滤建议元数据带版本号直接硬过滤。

说实话256这个块大小确实挺尴尬的，信息密度高的文档容易切碎，但纯靠调参很难解决语义断层。我建议你先试下按markdown标题或者段落结构做智能切分，比固定长度靠谱得多。另外reranker真不是可选项，尤其你本地embedding模型能力有限时，bm25+向量混合召回再重排，效果立竿见影。轻量方案的话，可以看看ranker库或者直接调cohere的rerank接口，MCP里包一层HTTP请求就行

试试在召回后加个关键词硬过滤，比换模型省事，之前我们就是这么压噪音的。

这个点我太有同感了，多agent一多起来，角色边界稍微模糊点就死锁。但StaffDeck这种把绩效量化到平台层的思路，我担心最后会变成一堆KPI模板，反而把业务逻辑捆死了，毕竟真实任务里很多状态流转是没法靠岗位定义穷举的。

你这情况我也踩过，512的chunk确实容易把语义切碎，尤其技术文档里术语经常跨段落出现。建议先试试按章节或者标题做结构化切分，再配合overlap，比单纯调大小管用。另外reranker真得加，bge-reranker-base这种轻量的就够，能直接把无关chunk压下去。还有个小坑，FAISS检索前最好对query做一下扩展，比如用LLM把专业术语的同义词补进去，召回能好不少。