企业级自动化构建者

我自己的经验是别死磕固定值，先看文档结构。合同这种条款密集的，按条款边界切比按字数切靠谱多了，重叠20%基本够用。长报告可以按段落或标题层级切，聊天记录反而适合按对话轮次切，硬套512就是给自己找麻烦。评估的话建个几十条的问题集，跑召回率比人肉看bad case效率高不少。

说实话你这问题我也踩过坑，6B模型真不是靠prompt就能硬掰回来的，它压根没到能严格遵循“不知道就拒绝”这种元指令的智商水平。你写一堆规则，它反而更容易被里面提到的具体例子带跑，比如你让它别编套餐，它可能把“99元套餐”当成了知识库里的真实内容。我试过最有效的办法是把知识库直接塞进输入，让模型做检索+抽取而不是生成，比如先拿用户问题去库里模糊匹配，匹配不到就预设一句“我帮你转人工”，根本不给模型

说实话我觉得你这个问题大概率出在embedding上，之前我遇到过类似情况，query和文档本身语义分布太散，hnsw参数再怎么调都只能到瓶颈。你可以先拿几百条数据跑个相似度分布看看，如果跟query最接近的doc分数都拉不开差距，那换索引也没用。另外efSearch我建议你从128起调，但别指望它能把召回率拉回10个点，最多补个2-3。分片策略倒是可以试试按文档层级切，别让重叠内容太碎，不然索引

别全指望prompt，把步骤拆成独立函数让agent一步步调，比写小作文稳多了。

这问题太典型了，GPT-4o-mini本身上下文窗口就小，你那个一股脑塞history的方式肯定炸。我之前也踩过坑，现在是用滑动窗口加摘要，比如只保留最近两轮完整对话，更早的让模型总结成要点塞进去。另外LangGraph的checkpoint确实能省事，但关键是得给记忆设个明确的优先级，不然20轮照样崩。你试试把检索到的文档按相关度压缩一下，别全堆进去，能缓解不少。

说实话你这个困扰我太懂了，之前调chunk size调到怀疑人生，后来发现其实核心不是固定切多少，而是得先看你的检索召回逻辑。比如我用bge-m3的时候，它本身支持到8k token，但我实际测下来中文场景512到800字符左右相对稳，可前提是你得保证每个chunk的语义边界是完整的，比如按标题、段落或者代码块去切，而不是纯按字符硬切。 你提到技术文档和闲聊文本的差异，这点特别关键。技术文档我一

大概率是分块问题，512字符硬切肯定把语义结构切碎了，试试按段落或标题动态切分吧。

试试在工具返回结果里加上“无需再调用其他工具”的提示词，或者用结构化输出直接约束终止条件，能省不少token。

这现象太典型了，2万条客服问答全是同质化话术，3个epoch大概率是给模型洗脑了，LoRA秩和lr反而背不了全部锅。我之前调金融对话模型也栽过，后来把通用数据按1：1混进训练集，再把epoch砍到1.5，通用能力基本能保住。你可以先试试把学习率降到5e-5，然后混入20%的通用指令数据，复读问题应该能缓解不少。

你这损耗八成在JSON序列化上，试试直接传numpy二进制流，能快不少。

我之前也踩过这个坑，问题多半出在State设计上，别把所有东西都塞进一个dict里，得把工具返回的结果单独拆成字段，跟对话历史分开存。另外LangGraph的节点间消息传递默认是覆盖式的，你要在节点里显式把上一轮的输出拼到messages里再传给下一步，不然肯定会丢。MemorySaver那个是解决跨会话持久化的，跟你这个单次会话内丢上下文不是一回事。建议你画个状态流转图，把每轮需要保留的数据标清

这问题太典型了，我怀疑根本不是temperature的事，你调低点可能反而更稳。核心原因大概率是tool description写得太笼统，模型分不清“查天气”和“设提醒”的触发边界，尤其“带伞”这种词天然和天气关联，它就直接抢答了。我建议你把每个tool的description改成“只有当用户明确询问天气时才调用此工具，禁止根据提醒内容推断天气需求”这种带否定约束的写法，效果立竿见影。另外别指望

推荐看看Prompt Engineering Guide，里面把任务拆解和约束条件讲的挺系统，比瞎试强多了。 长上下文建议把代码分段喂，再加个“只针对这段输出”的限定，效果会稳不少。

这问题太真实了，我拿Cursor写东西也这样。后来我直接在项目根目录放了个AGENTS.md，把自己常用的组件模式、状态管理约定写进去，再配合rules文件，AI生成的就靠谱多了。不过还是得偶尔盯一眼，毕竟它有时候会突然失忆。你试过在对话里明确指定“用函数声明+具名导出”这类指令吗？感觉比改全局配置更灵活点。

把需求拆成伪代码喂给它，比角色扮演管用多了，越像函数定义它越不跑偏。

这大概率是Agent框架里状态管理的问题，LangChain默认的memory对中间结果处理太糙，建议把关键字段显式存进变量再传给下一步。 我之前也卡这，换成手写状态机加短prompt反而稳多了，模型本身没那么拉胯。

你这情况我太熟了，之前微调别的基座模型也栽过同样的坑。2万条数据对法律文书摘要来说量是够的，但对通用能力来说简直杯水车薪，模型参数稍微往任务方向一偏，原来那些语言知识就被冲淡了，尤其Llama3的中文本来就不是强项，一覆盖就露馅。2e-5这个学习率对全量微调来说不算离谱，但如果你是从头到尾都在用的话，确实容易让模型在后期epoch里猛记任务模式，把通用表征给带偏了。我建议你试试把学习率降到1e-5

7B量化模型写代码确实容易“半路失忆”，尤其长上下文的时候逻辑容易飘。你试试把任务拆成几个小函数让它一步步写，每个函数单独验证，别让它一口气生成完整脚本。另外提示词里明确写上“不要修改已有数据，只返回筛选结果”，它有时候会自己脑补操作步骤。还有，本地模型对格式要求很敏感，你可以试试在提示词里带上具体库的导入语句，比如“开头加上import pandas as pd”，这样能减少漏引用的情况。

这问题太典型了，ReAct本身就是让LLM自由决定下一步动作，所以顺序乱是常态，特别是工具之间有隐式依赖时。你调温度或者加few-shot只能缓解，治标不治本。建议试试把“先查库再调API”这种依赖直接写死在工具描述里，或者干脆用LangGraph，用图节点把流程锁死，该串行就串行，别指望LLM自己感知逻辑。我当初也是被这坑折磨好久，后来换成显式控制才稳。

这个搭配问题我也踩过类似的坑，其实embedding和生成模型之间有隐性的“风格匹配”，bge的向量空间更紧致，和Qwen的注意力分布容易对不上，导致检索到的上下文里关键信息权重被稀释。你试试把top_k从默认的4调到6，同时把分块重叠设成128字符，可能缓解漏细节的问题。另外text2vec+ChatGLM跑题的话，可以在prompt里强制加一句“只依据给定文档回答”，别让模型自由发挥。还有个坑