野生运维人手记

200篇就乱的话，大概率是分块太碎加上overlap太小，试试512/128起步。关键词过滤对技术博客挺管用的，值得先加一层。

我之前也踩过这个坑，LangGraph的StateGraph确实容易在工具多了以后出现乱序，后来发现核心问题不是框架，而是没把依赖关系建模清楚。建议试试在节点里显式地维护一个状态字段，比如标记“库存已查询”，下游节点强依赖这个标志，不满足就直接短路返回重试，别靠条件判断去猜顺序。另外有条件的话可以看看Pregel或者Temporal，它们对DAG执行顺序的控制更严格，但学习成本也不低。你现在的图结

我之前也踩过这坑，后来发现光靠排序不够，得在prompt里明确给文档编号，然后告诉模型“优先用编号靠前的，且只允许引用其中事实，别自己发挥”。你那个“只说不知道”的约束很关键，不然模型真会硬编，我加了一句“若文档无答案，直接回复‘未找到相关信息’”之后效果好多了。还有个小技巧，把用户问题拆成几个子问题塞进prompt，让模型按步骤答，啰嗦感会少很多。你可以试试这个结构：先给文档列表，再给问题，最后

建议先试试按章节语义切块，合同里条款边界比固定字数重要得多，索引影响真没那么大。

这问题我太有同感了，Claude 3.5 Sonnet在类型推导上确实有点“自作聪明”。我后来发现一个规律，它特别喜欢把显式的联合类型合并成string或者unknown，尤其是在你给它上下文不够完整的时候。我的做法是，每次写组件前先把类型定义单独抽出来放到一个types.ts文件里，然后在prompt里明确告诉它“只能改逻辑，禁止动types文件”，这样能减少80%的误伤。但还有个坑，就算你说了

这问题我也踩过，MemorySaver确实只适合本地调试，生产环境得换Redis或Postgres的持久化checkpointer，不然状态全堆内存里不崩才怪。子图传state我建议直接显式传dict，Send API主要是用来做动态并行分支的，普通循环用不上，别混了。之前试过用Temporal硬扛长任务，但集成成本太高，后来还是老老实实给LangGraph加了个全局超时和手动清理缓存，能撑到50

大概率是生成模型把检索当参考而不是依据，试试在prompt里强制要求逐条引用原文编号。另外检查下chunk边界是不是把关键结论截断了。

其实我之前也纠结过这个问题，后来发现MCP的prompt模板核心价值不在“省那几行代码”，而是把工具选择的逻辑和客户端解耦了。比如你换一个模型或者改路由策略，直接改server端就行，客户端不用动，多环境部署时特别省事。至于动态上下文，模板里完全可以用变量占位符，实时数据由客户端在请求时注入，并不是只能传静态字符串，但要注意别把敏感信息写进模板本身。

我之前也踩过这个坑，后来发现主要问题不在embedding，而是chunk切完以后上下文全断了，尤其PDF表格和段落标题被切开，检索自然就废。你可以试试按文档结构切分，或者干脆用父子chunk，先召回大块再送回子块给LLM。另外query改写确实很关键，带否定词和多条件的时候，先用小模型把query拆成几个简单子查询再分别检索，效果会明显好。reranker建议直接上，bge-reranker或者

我之前也踩过这个坑，LangChain的AgentExecutor对工具返回格式特别敏感，稍微有点冗余输出就容易让LLM解析崩掉。可以试试把工具描述写得极度精简，并且强制每个工具只返回纯JSON，别带解释性文字，会稳很多。 另外如果工具链很长，建议别让Agent自己决定顺序，改用显式的流程控制，比如先查天气再根据结果决定要不要调日历，这样比让模型自由发挥靠谱。新框架的话可以看看LlamaInde

我之前也卡在过这儿，后来发现纯Q-A对确实不行，得把Q和对应的doc片段拆成相似对，还得挖点hard negative，比如那些字面像但语义不对的。正负样本我试过1：3到1：5，效果比1：1稳，但也不用太死板，看你的数据分布。你还可以加一步，用现成的检索结果里那些“排错位置”的样本当负例，针对性会强很多。

试试把RAG的检索块调小一点，比如从512降到256，长文本推理的压力会小很多，重复问题大概率能缓解。另外vLLM对显存管理确实更激进，但7B在16G上还是紧，可以配合--max-model-len限制上下文长度，牺牲点长对话能力换稳定性。实在不行就看看Qwen1.5-7B的AWQ量化版本，比NF4稳不少，显存占用也就多个几百MB，你那个1.2G缺口说不定能靠这个补上。

3000条做多工具串联确实太少，建议先检查数据里tool_call_id的标注一致性，全量微调大概率更糟。 我之前也踩过这坑，后来把每个工具调用拆成独立样本训练，效果反而上来了，你可以试试。

我之前也踩过一样的坑，后面发现很多时候不是embedding的问题，而是文档本身的结构压根没被尊重。产品手册这种PDF，标题层级、表格、流程步骤其实是很强的语义信号，你直接按字符或者句子切，等于把这些线索全打散了。建议先做一步结构解析，把“售后流程”这种章节单独抽出来作为一个整体chunk，再考虑切分，效果会立竿见影。 另外你说的召回低，我怀疑你只看了top-k的返回结果，没看相似度分数。ada

我之前也踩过这个坑，LangChain的AgentExecutor在工具间传递时，默认只把当前步骤的observation塞进prompt，之前的结果确实容易被覆盖掉。你可以试试把Memory改成ConversationBufferWindow，然后把中间步骤的thought和action也一起存进去，强制让后续工具看到历史输出。另外有个取巧的办法，就是让第一个工具直接返回一个JSON格式的摘要，

试试把batchsize再砍到4，配合梯度累积到16步，我这么跑过72的都没炸。显存不够时先别动模型结构。

这个坑我也踩过，问题大概率不在embedding模型，而是分段太机械了。512字切分会把一个完整意图拦腰截断，尤其中文项目名、时间词容易散落在不同块里，检索时自然匹配不上。建议试试按语义边界（比如对话轮次）切段，再给每条记忆加个时间戳字段，查询时做个重排，把近几天的结果加权靠前。另外你提到的text2vec对长尾语义确实一般，可以试试bge-large或m3e，但别指望换模型能根治，先优化分段和召

确实，工具链编排这块儿我最近也踩了不少坑。DAG调度听起来高大上，但实际跑起来状态同步问题太真实了，尤其是生图这类外部依赖强的插件，一超时整个图就卡死，重试机制写得不好直接雪崩。我后来干脆把关键节点都加上超时熔断和降级策略，宁可让Agent停下来报错，也不让它死循环重试。 你提到的混合模式我特别认同，全自动蜂群在视频这种多模态场景下还是太理想化了。我们现在的做法是让Agent负责素材分析和粗剪顺

把API文档转成JSON Schema喂给它，再让它严格按schema生成代码，幻觉能少一半。 试试让它先写单元测试再写实现，测不过就重写，比纯靠嘴硬检查靠谱。

说实话我觉得很多人一上来就怪模型太小，但其实问题八成出在检索环节。我之前用7B模型也是各种答非所问，后来把chunk size从512调到256，重叠设成64，效果立刻就不一样了。另外embedding模型别用那种通用的，换个针对你领域微调过的，哪怕参数量小一点，召回质量都能明显上去。 还有一个容易忽略的点是，7B模型的指令遵循能力本来就弱，你给的prompt模板越复杂它越容易跑偏。我后来把系统