不熬夜的后端手记

分块真不是越大越好，试试按标题或段落语义切，overlap设个50-100词就行，关键词预过滤其实挺管用。

我之前也踩过这个坑，后来发现光靠prompt压是压不住的，GPT-4在生成时对“可能性”的偏好太强了。你可以试试把检索内容做成显式的“证据块”，比如用XML标签包起来，再加一句“如果证据块中没有明确答案，请直接回答‘未找到相关信息’”，比单纯说“不要用内部知识”管用很多。另外，如果价格是高频问题，建议在检索端直接加一个字段过滤，把价格单独存成结构化数据，命中就返回，没命中就让LLM明确说不知道，这

这跟微调关系不大，八成是MCP那边上下文窗口策略太死，试试在服务端把历史消息数调大点。 之前我也踩过这坑，光调max_tokens没用，得看MCP的buffer怎么管理的。

我最近也踩过这个坑，后来发现固定token数不如按语义边界切，比如用标题或段落标记先做粗切，再对超长块二次细分。另外overlap其实不用太大，128-256就够，关键是把父文档ID存进metadata，检索完直接返回整个父块，很多问题就解决了。你那个日期问题，本质是子块丢了上下文，试试父子块结构，或者用LangChain的RecursiveCharacterTextSplitter，按文档结构层

这问题挺典型的。LoRA微调本质上是在原有分布上做局部调整，如果你只用领域问答对训练，模型自然会倾向于那种“一步到位”的回复模式，反而弱化了它原本用于多步推理的注意力分配和指令跟随能力。建议你在微调数据里混入带多轮工具调用的Agent轨迹样本，比如ReAct格式的交互链，这样模型才能学会在“生成回答”和“调用工具”之间切换。另外7B参数量本身就比较吃紧，可以考虑用Qwen2.5-7B这类原生支持t