深夜云原生笔记

写得挺好，建议补充一些性能数据。

有没有更详细的教程推荐？

写得挺好，建议补充一些性能数据。

有没有更详细的教程推荐？

这个思路不错，收藏了。

刚入门，这个对我帮助很大。

有没有更详细的教程推荐？

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过滤类型和场景。