一线低代码实验室

我前段时间也踩过这个坑，后来发现让模型只答是/否本身就挺容易翻车的，因为它没有“中间地带”可走，稍微沾点边就往“是”那边靠。我现在的做法是把判断拆细一点，比如让模型先说出这段和问题的关联点是什么，再让它打个1-5分，最后我自己卡阈值，比纯二分类稳不少。另外产品手册这种库，其实可以先用关键词或BM25做一轮粗筛，把明显不相关的先干掉，再让LLM在候选集里判，压力小很多。还有个小技巧是给“否”也加fe

我们之前也踩过这个坑，后来发现纯按字符切确实容易断句，但语义切分又太慢。现在折中方案是用递归切分按标点优先，再设个最小长度兜底，效果还行。表格和代码块一定要单独抽出来，不然embedding出来全是噪音。你们PDF里表格多吗？那种跨页表格处理起来更头疼。

试试把历史对话做摘要压缩再喂回去，上下文能省一大截，亲测有效。

我一般会在项目根目录放个.cursorrules文件，把技术栈和版本要求写清楚，比在注释里临时提醒管用得多。另外它给旧库有时候是因为上下文里没嗅到你的依赖，你可以在对话开头直接贴requirements.txt内容或者提一句“项目用pandas 2.x和requests”。训练数据滞后确实存在，但很多时候是模型偷懒走了老路，明确约束能好不少。

我也遇到过类似情况，感觉问题可能不全在分块上。你这种“如何配置”的query，embedding确实容易偏向语义相似但不含步骤的段落，bge-m3对操作型文本的区分度本来就一般。可以试试在入库前给chunk打上结构标签（比如“步骤”“参数”“背景”），检索时按意图做过滤，比单纯靠rerank硬拉排序更直接。另外query改写值得做，把“如何配置”改写成“配置步骤 操作流程”这类指令化表达，召回方向

学到了，感谢分享！

学到了，感谢分享！

这个思路不错，收藏了。

这个思路不错，收藏了。

我之前也遇到过类似问题，后来换了方案。

写得挺好，建议补充一些性能数据。

学到了，感谢分享！

这个思路不错，收藏了。

学到了，感谢分享！

写得挺好，建议补充一些性能数据。

学到了，感谢分享！

写得挺好，建议补充一些性能数据。

有没有更详细的教程推荐？

这个思路不错，收藏了。

这个思路不错，收藏了。