长街点灯

固定500字符切分对代码文档基本是灾难，代码片段和表格被拦腰截断后语义就废了。我之前处理类似场景试过按函数/类级别切块，再用tree-sitter先把代码结构解析出来，文本和代码分开处理，效果比无脑切好不少。另外bge-large在通用文本上不错，但代码相关相似度真的不如专门调过的模型，建议试试CodeBERT或者把bge在你们自己的API文档上微调一下。Rerank确实能救召回精度，但前提是候选

试试换bge-m3做dense召回，再配合bm25做混合检索，领域术语多的时候稀疏向量能补不少短板。

试试用小模型做个分类器先判断查询类型，再路由到对应库，比直接用大模型判断靠谱不少。

直接用最后一层做embedding确实不太靠谱，换个专门的轻量模型比如bge-small效果会稳定很多。

这个现象我也遇到过，感觉确实是示例太多会让模型“偷懒”，它更倾向于匹配记忆里的模式而不是自己推理。我现在的经验是，示例控制在5-8个比较稳，关键是每个示例覆盖一个典型的“坑”，而不是事无巨细都塞进去。另外你提到的示例质量也很关键，太具体的场景确实会带偏，试着用一些中等抽象度的对话，让模型学会举一反三会好很多。

你提到的“评估体系重构”这个点，我觉得是当前最被低估的问题。现在行业里还在拿HumanEval、GSM8K这些静态benchmark当圣旨，但实际部署过就知道，上线后的bad case往往跟评测集里的分布差着十万八千里。尤其长尾决策这块，模型在训练数据里见过类似模式，但稍微调个参数组合或者业务规则，就开始出现逻辑断裂——这种“认知失调”光靠扩大参数量根本治不了根。 我这边踩过的坑是：即使把RAG

温度设成0确实会降低随机性，但别指望它能彻底消灭幻觉，因为模型本身的概率分布里，即使top-1的概率也不是100%，尤其当输入稍微模糊或者超出训练分布时，照样会“编”出东西来。Qwen2.5-7B在本地部署时，我踩过类似的坑，核心问题往往不是Prompt写得太随意，而是你对“稳定”的定义可能太理想化了——客服场景里，用户问题千变万化，一个固定的系统提示很难覆盖所有边界。 建议你试试把系统提示分成