实战派知识库研究笔记

512固定切合同肯定不行，条款被切碎了语义就散了，先试试按段落或标题切再叠个50字重叠看看。

我最近也在搞这块，MCP工具调用微调确实坑不少。我的做法是把工具描述、用户query、模型输出的function call（包括参数）和工具返回结果拼成完整对话样本，但关键是要把错误样本也加进去，比如参数格式错的、选错工具的，让模型学会纠错。另外工具选择可以单独做一个分类任务辅助训练，效果会好一些。

单卡24G跑8B的LoRA确实容易炸，QLoRA 4bit基本是标配了，不然激活值和优化器状态吃得太狠。两万条对话不算少，关键看质量，工单直接拿来用问题不大，但最好把那种模板化回复和答非所问的剔掉。模型瞎编多半是训练时把无关上下文也塞进去了，试着在数据里明确加个“不知道就说不知道”的样本。另外可以降降lora rank，或者用gradient accumulation凑等效batch，先跑通再说。

你遇到的乱码其实是Unicode转义，不是模型中文支持的问题，多半是输出解析那层没处理好。系统提示词里最好直接给一个JSON样例，比写“严格按JSON输出”管用得多。另外ChatGLM本身对格式指令的服从性一般，可以在API侧加个json修复或正则兜底，别全指望模型自觉。Ollama的话记得看看template有没有把system角色正确传进去，这个坑挺常见的。

7B模型做多轮工具调用确实容易崩，尤其是JSON schema约束这块，小模型指令遵循能力就是差点意思。你试试用Qwen2.5专门出的function calling版本，或者换llama.cpp的grammar约束解码，能把输出格式硬卡死。另外LangGraph的重试逻辑也可以优化下，别一解析失败就整个重跑，把失败的输出塞回去让模型自己修。实在不行就本地跑个vllm起API，再套个outline

我一般只让Copilot补全重复代码，核心逻辑还是自己写，不然真会变懒。

SGD+momentum其实不一定更省显存，动量缓冲区虽然比AdamW的少，但如果你开了nesterov或者dampening，中间变量还是会多占一点。不过更可疑的是gradient checkpointing只在forward开——有些实现里backward重计算时如果没配合好，反而会在第三个epoch累积碎片。你可以试试在训练循环里每个epoch结束手动调一下torch.cuda.empty_

MCP只是让AI能调工具，改代码还得自己配server，连不上多半是端口或路径写错了。

微调数据建议模拟完整对话轨迹，只丢错误+修正对模型学不到“看到错误再决策”的时序。我试过类似方案，格式遵循确实会掉一点，得混入原有工具调用数据一起训。其实更稳的是先在MCP层做结构化错误重试，把重试结果当正样本回流，成本低还不伤模型。真要微调，LoRA小rank跑一版对比拦截方案，别一上来就全参。

我现在的做法是短期和长期分开存，短期直接用内存加滑动窗口，超过轮次就压缩成摘要再写进向量库。长期那边单独一个index，写入前先做一轮去重和重要性打分，不然噪声确实会把检索带偏。session_id过滤治标不治本，关键还是得在写入策略上做取舍。过期的话我倾向归档不删，指不定哪天回溯用得上。

我们之前也是仨人小团队，最后选了折中方案：核心调度自己写，工具调用和LLM接口用LangChain的Tool抽象，但不用它的Agent executor。这样既不用啃那些Chain概念，又能白嫖它的工具生态。长期记忆千万别直接塞向量库，我们踩过坑，检索延迟高还容易召回无关内容，现在是Redis存最近对话摘要，向量库只存沉淀后的关键事实。你们内部API多的话，建议先把工具注册和鉴权抽一层，后面换框架

我之前也踩过这坑，7B这个尺寸对system prompt的注意力确实会随着对话变长而衰减，不是你的写法有问题。我的经验是把角色约束塞进每一轮的用户消息里，比如在提问前加一句“记住你是银行客服，简短亲切”，比只写在system里稳很多。另外few-shot确实管用，放两三组完整的问答示例，模型模仿格式的能力会明显提升。还有个偏方是把temperature调到0.3左右，风格漂移会少一些，你可以试试

核心业务我最多让它写单测和工具类，方法体直接粘真不敢，出一次线上事故就老实了。

几十万条全量算确实还能忍，但上百万后延迟基本线性涨，QPS一高就崩。我之前测过百万级，IVF能压到几十毫秒，HNSW更快但内存吃得狠，召回率暴力基本是天花板，索引大概损失一两个点。过滤条件确实是坑，HNSW对带filter的查询容易召回掉，Milvus那种先过滤再搜会好点。建议先扛着，等数据量或并发顶不住了再换，别过早优化。

我之前也踩过类似的坑，最后发现问题出在chunk重叠和拼接顺序上。256字符确实容易把语义切断，我改成带128字符重叠的切法后，生成质量明显稳了。 另外你可以试试把检索到的chunk按相似度排序后，在prompt里显式标注每个片段的来源标题，模型就不太会硬揉信息了。至于定位问题，我习惯把检索结果单独丢给模型做“摘要+判断是否相关”的测试，如果摘要都乱，那就是检索端数据质量问题，而不是生成端的锅。

八成是参数没包成nn.Parameter，或者forward里用了原地操作把计算图掐断了。

我之前也踩过这个坑，后来发现多半是memory里塞了太多历史中间步骤，模型反而分不清当前目标。可以试试只保留最近两轮对话摘要，或者把工具调用结果单独缓存，别一股脑全丢给模型。另外给Agent加个明确的“终止条件”，比如同一工具失败两次就强制让它换策略，能少绕不少弯路。

这情况太典型了，不是碎片化就是缓存没释放。你试试把dataloader的num_workers调到0，顺便检查下有没有变量不小心被梯度带住了，比如loss里用了不该用的中间量。混合精度没降显存大概率是batch里有一两个样本特别大，导致autocast的dynamic loss scaling在反复调整，可以关掉gradscaler看下峰值。工具的话推荐pytorch的torch.cuda.mem

生产环境还是API稳，本地vLLM的显存和并发坑太多，更新模型也够折腾的。

8张A10跑7B还要求50并发，瓶颈其实不在显存总量，而在单卡吞吐。我之前用FP8静态量化配合vLLM的continuous batching，把max-num-seqs压到单卡8左右，实测能稳在40并发不OOM，你试试动态组batch别硬调batch size。 GPTQ乱码大概率是校准集跟你们业务数据分布差太远，换个200条真实prompt重新量化能缓解。估算的话单卡并发≈可用显存除以（模型