深夜大模型成长录

感觉像是ReAct的检索决策问题，试试把新文档强制注入一次对话上下文验证下。 你拆成子查询后，每个query的topK太小了，新文档排不到前面，调大点试试。

我之前也踩过这个坑，后来加了rerank环节，用bge-reranker重排一下top-k结果，效果立竿见影，基本能滤掉那些纯关键词匹配的噪声。另外试试把chunk切小点，然后对召回结果按source文档去重，只保留每个文档里最相关的一段，生成时上下文干净很多。还有个土办法，把用户问题拆成几个子意图，分别检索再合并，比单次大top-k聚焦多了。

后一种更稳，但得把示例跟当前检索内容解耦，用通用结构代替具体文档，不然换领域就废了。

手动打标确实不现实，但可以换个思路：给每个代码片段自动提取“框架名”作为元数据字段，检索时直接按这个字段过滤再加向量相似度，双条件筛下来基本能避开混用。另外prompt里写死“只参考Flask相关代码”对模型约束效果有限，不如把过滤结果直接拼进上下文，让它没机会看到FastAPI的示例。你可以试试用正则或者关键词匹配来预分类，不用人工介入，准确率也够用了。

说实话你这问题太典型了，我一开始也这样。关键不是你给的信息不够，而是你让AI“自由发挥”的空间太大了。我现在的做法是直接丢给它我CSV的前几行真实数据，然后明确要求“只输出完整代码，不要解释”，再加一句“用函数封装，参数是文件路径和输出路径”，基本一次到位。 另外你说的思维链其实没那么玄乎，本质就是把你的数据清洗规则拆成“空值判断标准”和“异常值定义”这两步，分开写进prompt里。如果你连异常

说实话你这个情况我太熟了，之前调RAG的时候也是卡在“召回好但生成拉胯”这个点上。后来发现问题往往不在prompt模板本身，而在你怎么把检索结果“结构化成上下文”。我试过把每个片段前面加上类似[文档1-来源：xxx]的标签，并且明确告诉模型“回答时优先引用编号靠前的片段”，效果比单纯拼接要好不少，模型至少知道该往哪儿看。另外一个坑是，如果top3的片段本身有信息冲突，模型就会选择性失忆，这时候我建

我们团队试过几十版模板，最终发现角色设定越具体越容易翻车，简洁指令加一两个示例反而最稳。 模板固定下来后还得针对badcase微调，别指望一套走天下，推理速度影响其实很小。

我一般是先写伪代码卡死逻辑，再明确告诉它别用useEffect做联动，效果稳很多。

同感啊，WAIC的展台和真实的产线确实是两个世界。你提到的视觉SLAM在光照变化下丢帧，这个我太有体会了——我们做AGV调度的时候，仓库里那种高架货架下的阴影区，还有叉车开过时扬尘造成的反光，直接让定位跳变，最后逼得我们不得不在算法里加了一个“场景置信度”的开关，低置信度时强制切换到里程计推算，但这样精度又掉下来了。你们后来是怎么处理光照鲁棒性的？是走多传感器融合路线，还是换更抗干扰的硬件方案？