深夜低代码实验室

大概率是推理时system prompt和训练模板没对齐，LangGraph那边的工具注入格式也得跟训练时一模一样才行。

我遇到过类似情况，后来发现是角色设定把模型的注意力带偏了。你让它当法务专家，它就真去“分析”合同了，反而忽略了你要的纯提取任务。提取类需求其实更像填空题，指令越直接越好，加人设等于给它加了戏。我现在只在需要判断或润色时才加角色，纯抽取就直接说清楚要什么字段、什么格式。

感觉像是ReAct把历史对话带偏了，试试清空记忆再单独测新文档，看能不能召回。

我之前也踩过这个坑，改写后反而把原query里的关键实体给丢了。GPT-4特别爱自作主张地“优化”措辞，结果跟知识库里的术语对不上，向量空间里就飘走了。你试试把prompt改成只做同义词扩展、别动原句结构，或者干脆用query+改写各检索一次再做融合。bge-small对短文本敏感，改写后句子变长反而可能稀释了核心词权重，这个也得留意。

几万条片段Chroma完全够用了，持久化没问题，性能也没网上说的那么不堪，真正坑的是并发和分布式场景。Milvus那套etcd+minio+pulsar的架构，个人项目部署纯属给自己找罪受，杀鸡用牛刀。其实可以看看Qdrant，单机docker一条命令就起来，性能比Chroma强不少，API也清爽，以后要扩也顺。真到数据量爆炸那天再迁Milvus也不迟，向量库这块迁移成本没想象中那么高。

我也遇到过这情况，后来改成先自己把组件骨架和state逻辑手写出来，再让AI补样式和重复代码，它就没法带偏了。关键是别让AI在你还没想清楚之前就动手，Tab补全太顺手反而容易偷懒。还有个笨办法，把AI建议当code review看，不直接接受，先问自己它为什么这么改。慢慢就形成习惯了，AI还是打字员，思路得自己攥着。

两个人维护确实别碰重框架，我们后来直接用OpenAI SDK加个简单路由，反而稳得多。

我现在的做法是工具定义只放System里，但会在每轮User消息末尾加一句极简的“可用工具：xxx”，相当于做个提醒锚点，实测多轮后调用准确率明显好一些。全塞User里token确实扛不住，而且模型容易把工具说明当成任务上下文来理解。结构化的话可以试试把工具签名压缩成一行JSON Schema，System里只留这一份，别写大段自然语言描述。

我也踩过这坑，后来用Send API拆子图才理顺，全局state共享太容易读到脏数据了。

我一般把硬约束抽成结构化字段每轮显式带上，比塞历史靠谱多了。

500条确实少了点，风格类任务建议至少2000条起，不然模型学不到稳定模式。

合规优先的话BGE-large基本够用，ada那点精度差距在FAQ场景感知不明显，不值得冒险。

MCP本身不管状态，session_id得自己传到工具参数里，内部按sessionId做存储分区就行。 我做过类似的，在server层加个dict存sessionId做key的上下文，多用户串不了，Redis都不需要。

说实话我之前用LoRA调过Qwen2.5-7B做医疗问答，数据集跟你差不多大，五千多条，效果对比全参的话，我那会儿测下来大概能到全参的92%左右，但有个前提是任务本身比较规整，问答对结构固定，格式不容易乱。你说法条文书这种，如果回答里需要严格引用条款编号或者输出特定结构，LoRA确实可能在某些边界case上崩得比较明显，我朋友试过合同审查，就出现过漏条款或者格式错乱的问题。rank8和16没区别挺

数据混合比例的问题确实存在，5000条领域数据对7B模型来说冲击力不小，建议试试把通用代码语料按3：1或4：1混进去，微调时用低学习率+少量epoch，能缓解灾难性遗忘。另外MCP工具触发错乱很可能跟prompt里工具描述太模糊有关，试试在系统提示里明确“仅当用户要求分析既有代码时才调用静态检查”，把排序这种生成任务排除在工具触发条件外，可能比纯靠微调更直接。我自己调类似场景时还发现，给模型加一个

看到这个GPU利用率40%我第一反应就是卡在显存带宽或者数据搬运上了，AWQ 4bit虽然省显存但解卷积的时候访存压力反而可能更大，尤其两张3090走NVLink带宽也就那样。你试试把max_num_seqs调低到64或者128看看，有时候开太大反而导致batch内padding和调度开销吃掉收益，vLLM对7B这种小模型并不一定吃满256的配置。另外检查下是不是输入输出长度差异巨大，如果业务请求

这问题我太有共鸣了，之前做个多工具调用的Agent，也是被上下文撑到怀疑人生。后来我发现核心不在于怎么截断，而是得重新设计工具返回的“格式”，让Agent只拿到决策必需的最小信息，而不是让原始结果一股脑全进来。比如查数据库，我让工具直接返回聚合后的统计值和影响行数，而不是几十条明细；调API也是，让工具自己生成一个几行字的摘要，再附上“完整数据已存到临时文件，需要时再按ID取”这种句柄式引用。

这问题我太有同感了，之前做合同审查也踩过这坑。你这种混合文档光调chunk_size肯定没用，表格和代码本身就是强结构化的，硬拆反而把语义切碎了。我后来是先用规则把表格和代码块单独抽出来，再对纯文本按段落切，效果立竿见影。另外建议你试试用LLM给每个chunk生成几个模拟用户问题的索引，比单靠embedding硬匹配准很多。reranker可以加但不急着上，先把分块和检索逻辑捋顺再说。

我之前也遇到过类似的坑，最后发现是数据预处理的问题。你512token的窗口对代码补全来说太短了，函数体稍微长一点就被截断，模型根本学不到跨函数的调用关系，至少得1024起步。另外loss在2.3附近徘徊不降，可以先看看验证集上生成的代码是不是语法都对了，如果语法错误很多，那大概率是tokenizer没处理好缩进和换行，试试把代码按tokenize粒度重新清洗一遍。

说实话我觉得这不是你prompt的问题，DeepSeek Coder v2在长脚本的上下文连贯性上确实容易翻车，尤其像inplace这类细节，它经常把默认行为理解错。我后来学乖了，写pandas操作时干脆每步都显式赋值，不靠inplace，反而少很多莫名其妙的坑。另外异常处理那块，你可以在prompt里直接要求“所有网络请求必须带try-except并重试两次”，它会照做的，但你不说它默认省略。