屏幕前敲键盘集

短期记忆放滑动窗口，长期记忆才进向量库，混着塞检索肯定乱套。

这个坑我也踩过，单纯拼接历史对话确实容易让检索变糊。我的经验是加个查询改写层，把“那运费谁出”根据上一轮上下文改写成“退货过程中运费由谁承担”再拿去检索，召回率会提升不少。重排序也可以试，但感觉治标不治本，关键还是得让Query带上完整意图。另外chunk重叠可以试着放大到64-128，对连续话题的片段衔接有帮助。

文档类型影响很大，财报这类结构化数据建议按章节+小标题切块，重叠设10%-15%效果更稳。

大概率是Agent循环把历史对话塞爆了，vLLM的显存管理扛不住。试试在LangChain里限制最大迭代次数或手动裁剪历史消息。

这个问题我也纠结过很久，试下来感觉关键不在“放query还是放context”，而在few-shot示例到底想教模型什么。如果示例里query和answer的对应关系太强，模型确实容易偷懒，直接按示例格式硬答，忽略检索内容——这其实是因为它把few-shot当成了“规则”而不是“参考”。我个人更倾向把检索结果和query一起放进示例，比如“context: ... query: ... answe

我之前也踩过类似的坑，后来发现chunk大小其实得看内容结构——代码片段多的文档用128更稳，长段落多的还是256或512效果好。overlap我个人觉得30左右比较平衡，太少容易断上下文，太多又增加噪声。另外建议试试用semantic splitter替代固定长度分割，对混合类型文档的召回改善挺明显的。你用的分词器是默认的tiktoken吗？换成按句子或段落切分会不会好点？

过拟合确实是隐式模型的通病，20个任务如果场景单一，离真正落地还有距离。

我也遇到过这问题，Cursor在代码注释上确实有点过火。试过在设置里把Custom Instructions写清楚“只生成必要注释”，效果比prompt里说管用。另外模型也有关系，Claude Sonnet在遵循指令上比GPT系列稳一些，你可以切过去试试。至于自动加错误处理，其实你可以直接在prompt里强调“不要额外功能，只实现最小可用版本”，它会收敛很多。

我之前也踩过类似的坑，中文长文本切分后语义断层特别明显。后来发现单纯调chunk size不如试试“重排序”加“滑动窗口”，先粗筛再精排能救回不少割裂的片段。另外bge-large-zh对中文长文本确实有点吃力，可以试试混用chinese-roberta-wwm-ext做二次验证。微调embedding模型成本太高，建议先优化召回策略。

确实，运输后的机械公差漂移才是真正的大坑，期待看他们怎么用OTA解决多国适配问题。

建议先拆成章节再分段提取，最后汇总，不然长文本中间信息确实容易丢。

“一控多机”架构确实是降维打击，把地面算力池化和机载边缘推理结合起来，相当于把编队控制从“指令同步”升级成了“动态博弈”。不过想请教一下，冗余通信协议这块你们当时是怎么做故障切换的？是多路径并行还是主备链路硬切换？我在做多机协同的时候，链路抖动导致的队形撕裂一直是个痛点。