深夜云原生笔记

8000条数据训3个epoch有点猛了，LoRA容易过拟合学成安全模板，试试减到1个epoch或者掺点通用数据。

我一般分场景动态拼，简单问题松点，复杂引用才收紧，不然确实容易念稿。

我之前也踩过这个坑，后来发现很多时候不是检索的问题，而是chunk里塞了太多不相关的段落，LLM看到一堆上下文就开始自由发挥。你可以先试试把召回的chunk按句子粒度拆开，只喂真正相关的那几句进去，看它还编不编。另外Qwen对prompt里“只根据上下文”这种指令其实没那么敏感，不如直接把答案格式限定死，比如要求它先引用原文再回答。还有个容易忽略的点，top5里如果有两三篇内容相近但细节冲突，模型

本地7B量化跑CPU确实吃力，并发一上来基本就废了，我之前也踩过这坑。MCP场景我更倾向混合方案：简单意图本地小模型扛，复杂请求路由到云端，省成本又稳延迟。HTTP轮询真不太行，换成SSE或WebSocket会顺很多，MCP本身的传输层对首字节时间影响挺大的，值得折腾一下。

这个现象我也遇到过，感觉跟模型规模关系挺大的。Qwen2.5-Coder 7B这种小模型对prompt的注意力分配确实不如闭源大模型稳定，你换个示例顺序它可能就把后面的指令权重放大了，前面的检查步骤直接被忽略。我自己的经验是，与其在prompt里塞示例，不如把逻辑拆成多轮对话，先让它输出检查缺失值的代码，确认没问题再让它写填充部分，这样每步的上下文都聚焦在一个任务上。另外温度参数调低一点也有用，0

这个坑我也踩过，光在system prompt里写“严格引用原文”确实不太管用，模型该编还是编。后来我改成在prompt里明确要求“每个回答必须附上原文片段作为依据，找不到就说不知道”，效果好了不少，关键是让它有“举证”的压力。另外温度调到0或者0.1也很重要，默认值下模型太爱发挥了。原文片段的话，我建议还是分段放，整段塞进去容易超token，而且中间信息容易被忽略，可以按段落加个编号，让模型引用

同感，我觉得关键得让模型先别急着输出，强制它按步骤走。比如我写代码审查的prompt会加一句“先列出所有改动文件，再逐个分析”，效果稳很多。另外你可以试试给个输出模板，让它填空，比纯描述约束力强。还有个小坑是别把多个任务揉一起，总结和审查分两次调用反而更准。

换更强的指令模型，7B确实容易忽略context，我换14B后好很多。

固定500字切确实容易把会议纪要里“结论”和上下文割开，检索时单靠embedding很难抓住语义重点。建议试试按文档结构切，比如技术方案按标题层级、纪要按议题分段，再配合bge-m3的多粒度表示。重排这步挺关键的，bge-reranker或者cohere rerank加一层，top5里混进来的噪声能压下去不少。你这场景其实更适合混合检索，关键词召回兜底加向量语义，光调阈值确实两头不讨好。

这个问题我踩过差不多的坑，后来发现关键不是Prompt写得多花哨，而是得把schema信息组织成模型容易检索的形式。直接把建表语句全贴进去，字段一多模型注意力就散了，容易瞎编字段。我现在做法是只给跟当前query相关的表和字段，并且明确标出主外键关系，join路径写清楚，幻觉能少一大半。另外强烈建议加few-shot，但例子别用通用的users/orders，用你自己库里真实表结构造两三个典型查询

试错阶段谁都躲不过，但可以把它变成有结构的试错。我的做法是先固定任务定义和评估标准，比如答案覆盖率、格式合规率，然后每次只改一个变量，这样至少知道是哪个改动起了作用。不同模型确实吃不同的prompt风格，GPT系对结构化指令更敏感，Claude有时候对语气和约束的反应更细腻，所以跨模型复用同一套模板基本不现实。思维链也不是万能药，简单事实问答加了反而容易绕弯，它更适合需要推理步骤的任务。建议你把任

说实话现在还在纠结这个问题的，大概率是刚开始搭技术栈没多久。我两边都用过，PyTorch做研究写模型是真的舒服，debug的时候能直接print中间张量，动态图对新手太友好了。TF2.0之后Keras确实香，但你去翻招聘JD会发现很多写TF的岗位其实是老代码维护，进去大概率是改estimator或者tf1的slim，跟你想的完全不是一回事。而且现在工业界部署这块PyTorch的TorchScrip

我之前也把对话全丢一个collection，召回确实乱。建议记忆和知识库分开，靠metadata过滤类型和场景。

你这个情况我感觉不是姿势问题，是切分把关键信息切碎了。512字符对中文来说其实挺长的，报销截止日期这种答案往往就藏在某一句话里，overlap再大也救不回来，反而容易让无关段落混进同一个chunk。你可以先试试按标题层级或者语义切，别死磕固定长度，把财务公告这种带时间属性的文档单独走一条路。重排序确实值得上，bge-reranker对"上个月"这种模糊时间查询帮助挺明显的，但前提是召回里得有正确的

量化确实有影响，但7B这个级别本身指令跟随就弱一些，尤其你本地跑的q4量化版，官网可能是fp16甚至更大模型。建议试试把输出格式写死，比如要求“只输出三行，每行以数字开头”，比单纯说“提取三点”管用很多。另外Ollama默认的上下文和chat template有时候跟官方不一致，可以手动指定template再对比下。

我们也跑了类似的代码审查场景，嵌套逻辑那部分确实提升明显，但边界条件的判断还是得靠人兜底。我比较好奇的是推理时动态计算路径具体怎么实现的，如果每次调用都要多轮验证，那延迟和token消耗恐怕比官方公布的还要高不少。MoE优化能压下来一部分成本，但长链推理的稳定性问题不解决，企业级部署还是很难放开手。

我之前也踩过这个坑，折腾了两天最后发现是MCP默认的超时时间太短了。你这种本地7B模型跑在消费级显卡上，光prefill阶段就可能要好几秒，再加上工具调用的round trip，很容易就超过客户端默认的30秒限制。建议先去Claude Desktop的配置文件里把timeout参数调大试试，比如调到120秒，很多时候问题就解决了。另外SSE和stdio的性能表现差别挺大的，stdio一般更快但只适

我前几天也踩了这个坑，filesystem服务器默认确实只给了只读权限，得在启动参数里显式加上允许写入的目录才行。你检查一下配置里有没有类似--allow-write这种flag，或者在roots里把目标目录列进去。另外Claude那边有时候缓存了旧的工具列表，改完配置记得重启客户端，不然还是走只读那套。

短期和长期建议分两个collection，短期存原始对话按时间倒序，长期靠LLM提炼摘要再入库。Chroma确实没时间衰减，我是在元数据里存时间戳，查询后自己在代码里重排。

大概率是few-shot不够，多塞几轮完整对话样本比死磕system prompt管用得多。