一只鹤正在学习日记

int4本身就会拖速度，试试换成fp16加flash attention，长文本场景提升挺明显的。

我一般按段落语义切，再用RAGAS跑评估自动调，比手调靠谱多了。

工具返回结果先截断再喂，另外可以试试把历史对话做摘要压缩，能省不少显存。

我按消息粒度存，再给每段对话打个topic标签，切回A话题时按标签召回就行，比纯metadata过滤省心。

先上reranker试试，长尾query纯靠向量确实容易飘。HNSW参数影响的是速度不是相关性，别折腾错了方向。

我也碰到过这问题，后来发现Cursor虽然在同一会话里，但上下文窗口有时候会“断片”，尤其你中间没再提之前代码的话。我的做法是每次让它改代码前，先补一句“沿用上面那个df_raw，别改名”，或者直接把现有代码片段贴进去再问。另外可以试试在项目根目录放个.cursorrules文件，把命名习惯写进去，它会优先遵守。

loss卡在4.5确实挺让人抓狂的，不过你先别急着怀疑数据格式，我拿LoRA微调Llama3中文对话时也遇到过类似情况。2e-4这个学习率对LoRA来说其实偏高了，很容易把模型带进一个震荡不收敛的区域，你可以试试降到1e-4甚至5e-5，配合一点warmup，看loss有没有松动。另外batch size=4本身不会直接导致不收敛，但它会让梯度噪声变大，等效学习率也跟着变，如果你没开梯度累积，实际

chunk_size别拍脑袋定，得拿真实query跑几组对比，我一般256到512试，数字类问题小chunk更稳。

7B做Agent确实吃力，换3B会快不少但推理能力掉得也明显，建议先试试流式输出加KV缓存，体感能好很多。

我踩过这个坑，光靠“基于以下文档回答”确实太弱了，模型很容易放飞。后来我在prompt里明确要求“只允许引用文档原文，禁止自行推理或补充”，还加了引用编号，让它每句话都标来源，效果好很多。你说的“没有就说不知道”也很有用，能压住一部分幻觉。另外文档分块别太大，关键参数最好单独成段，不然模型容易看漏。

才两个例子确实不太够，字段容易飘，加到五六个覆盖边界情况会稳很多。

这个问题我也踩过坑，感觉光靠system prompt里写“不要联想”基本没用，模型对否定指令的服从度本来就弱。后来我改了个思路，把约束从“不要做什么”换成“必须做什么”，比如要求它每个结论后面都标注来自哪个片段，没找到就输出“未找到相关内容”。这样模型有个明确的动作要执行，比单纯禁止它发散要管用一些。另外检索质量真的很关键，模糊片段本身就是在给模型递刀子，我后来加了rerank和相似度阈值过滤，

我最近也踩过这个坑，top5命中率挺高但答案就是一股拼凑味儿。后来发现关键不在检索，而在prompt里上下文的组织方式——把一堆chunk平铺直叙塞进去，模型很容易“礼貌地全部用上”，哪怕有些只沾一点边。我现在的做法是每个chunk前加一句极短的定位说明，比如“以下段落讨论X政策生效时间”，让模型知道每块该看什么，硬凑的情况明显少了。多文档冲突我一般会在指令里明确优先级规则，比如“若不同来源矛盾，

我之前也踩过这个坑，固定500切真的很容易把步骤拦腰截断。你可以试试按标题层级递归分，LangChain里有MarkdownHeaderTextSplitter，PDF转出来的结构要是乱就先用unstructured预处理一下。另外bge-large-zh配faiss直接top-k确实糙了点，加个bge-reranker效果提升挺明显的，尤其是你这种权限和密码混在一起的场景。

loss降不代表模型学会了，2万条多轮数据对客服场景其实偏少，而且多轮里如果回复模板太单一，模型很容易学到“匹配关键词”而不是真正理解意图。建议先拿几百条测试集人工过一遍badcase，看看是不是退货和发货的样本本身就有标注混淆。8B跑中文客服理论上够用，但Llama3.1中文底子确实不如Qwen2.5，换基座值得一试。评估的话别太依赖BLEU，可以看看意图准确率和槽位填充，或者用GPT-4o给回

这个其实没有绝对答案，得看你的训练数据里系统提示词是不是每次都固定出现的。如果训练时每条都带且措辞完全一致，那模型确实会把它当成上下文的一部分来学，推理时带上通常更稳。但你遇到重复“专业”这种词，可能是提示词本身太强、跟训练样本里的回复风格绑太死了。可以试试推理时换个更简短的说法，比如“你是客服”，或者干脆把提示词写进用户消息里，效果可能更自然。

我之前也卡在这，后来发现八成是切块把上下文切碎了，检索回来的是半截话，reranker再强也救不了。你可以先拿几个bad case看看召回原文，如果本身就是断的，那优先调切块和加标题/摘要。混合检索对专有名词和数字确实有用，但得先保证embedding那路没拖后腿。排查顺序我一般是从数据侧往回看，别一上来就换模型。

微调数据跟真实MCP请求差太多，模型没学会啥时候该调。先查下你system prompt里工具描述够不够清楚。

我之前也踩过这个坑，AgentExecutor本质上还是为单链路设计的，你拿它跑多Agent并行调度，等于让一个不擅长并发的东西硬扛，卡住其实挺正常的。你描述的那种互相等、重复执行的情况，大概率是任务状态没有集中管理，每个Agent各自为政，谁也不知道别人干到哪了，最后就乱套了。调timeout和max_iterations只能缓解表面症状，治不了根，因为问题出在调度层而不是执行层。我后来是把规划

这个坑我也踩过，检索出招聘内容大概率是chunk切分把语义切碎了。“离职流程怎么走”和招聘信息里都有“流程”“员工”这类词，500的chunk如果刚好卡在关键句中间，embedding再强也救不回来。建议先试试按标题层级切，或者换成语义切分，再在召回后加个bge-reranker，效果通常立竿见影。