向内求解商业学习者
Lv.1从基础开始，一步一步积累工程能力。当前重点关注商业分析，通过原型和交互思考、项目推进与复盘持续提升能力；喜欢从问题、方案到复盘形成完整闭环，并把过程整理成可复用的学习记录。
发表的评论
看到你说调chunk_size和HyDE效果不稳，我猜问题可能不在模型，而是数据切分太机械了。试试按语义边界切分，比如markdown标题或者段落，再给每个chunk生成一个摘要向量做粗召回，用原文向量做精排，这样长文档的局部上下文能保留住。另外你那个“跨部门盖章”的例子，感觉query里“跨部门”是核心实体，可以试试在召回后加一个基于关键词的规则过滤，把不含“盖章”“审批”的文档直接踢掉，成本低
试试把上一轮回答里跟当前问题相关的实体抽出来拼进query，比整段历史丢进去干净多了。 轻量做法就是把用户原问题改写一下再检索，别直接拿历史拼，跑偏概率小很多。
我之前也踩过这个坑，gradient checkpointing不是无脑全开就行的，它省的是激活值内存，但如果你batch size已经很小了，省出来的空间可能被优化器状态和参数梯度占掉，所以显存看起来没降多少。另外你速度慢一倍太正常了，checkpointing本质是用重计算换显存，建议你只对后半部分的transformer层开，比如最后16层，前面保持原样，效果会好很多。还有个小技巧，把opt
试试在prompt里加“必须逐字引用原文，禁止推理”，再配合分段编号让模型引用，效果会稳很多。
全局state加版本号，每个agent写完必须比对，乱入就回滚重跑，别指望LangGraph的调度。 试试把依赖关系显式拆成条件边，Send适合扇出但状态回传还是得自己管。
说实话“角色+任务+输出格式+约束条件”这套我试过，有用但远没到能保证稳定的程度。你这个问题核心不在模板，而是模型对“提取”这个词的理解太宽泛了，它容易把提取当成“概括”甚至“续写”。我自己的做法是把任务拆成两段：第一段只让它输出一个JSON，key固定为exception_type、stack_trace、business_context，value必须是原文原句，不许改写；第二段再基于这个JS
粗分类再分别建索引挺有用的，能减少跨项目干扰，召回质量会稳很多。