实战派知识库研究笔记

你这个描述太真实了，我一开始搭RAG也是这个感觉，检索没问题，坏就坏在最后那一下生成。我后来发现prompt里光写“根据以下内容回答”确实不够，得把角色和边界说清楚，比如“你是一个只依据给定片段作答的助手，片段里没有的信息不要补充”。另外告诉模型片段来源挺有用的，尤其是带标题或文件名的场景，它会更倾向引用而不是瞎编。分点还是直接给结论，我觉得取决于你的场景，问答类我一般要求先给一句直接答案，再列依

你这情况挺常见的，7B模型在两张4090上DDP跑不过单卡，大概率是通信开销把计算收益吃掉了。4090没有NVLink，走PCIe传梯度本来就慢，加上模型不大，每张卡算的量太少，AllReduce占比就特别高。可以试试开gradient accumulation把等效batch拉大，或者用torch.compile配合DDP看能不能压一压开销。另外确认下有没有误开find_unused_param

硬切512字太糙了，接口文档得按段落或标题切。先换个分块策略试试，bge-large-zh中文够用了。

你这个问题大概率不在chunk_size上，而是切分逻辑本身把语义打散了。“员工年假几天”这种query要的是完整语义块，硬按字数切很容易把年假规则和离职流程混在一个chunk里。建议先别调参，人工抽20条query看top5里到底哪句是真正该召回的，算个命中率再动。另外bge-m3对短query挺敏感，可以试试给query加个“年假政策”这种伪标题再检索，效果可能比继续调overlap明显。

试试调低LoRA的rank到8，再解冻mlp层一起微调，我这么干遗忘少很多。

500条确实少了点，指令微调起码上千条才稳，loss振荡多半是数据太单一。

我也遇到过类似情况，感觉角色设定越具体，模型越容易“演过头”，尤其法律这种需要严格依据的场景。后来我基本只在需要固定语气或风格时才加角色，专业任务就老老实实写清输入输出格式，顶多补一句“不确定就别编”。你那个虚构案号大概率是角色把它往“权威感”上推了，反而压过了事实约束。

TF-TRT和TorchScript在动态shape上的差异，根子还是在两者对图捕获的哲学不同。TF那边默认是静态图思维，哪怕用了eager，一旦进TRT或者XLA，shape一变就得重新编译整个子图，agent循环里每步输入长度都不一样，trace开销自然爆炸。PyTorch这边torch.compile走的是dynamo+inductor路线，对动态shape有guard机制，虽然也会reco

试试把图片预处理好后存成numpy或lmdb，训练时直接读，比每次解码jpg快很多。

我遇到过类似情况，最后发现关键不在Prompt写多细，而是得让模型先判断“这句话是不是决策”。可以试试分两步走：第一步只让它标注每句话的类型，第二步再提取。另外会议纪要里时间节点漏掉，可能是你例子给得不够“负”，加几个反例（比如闲聊里出现“决定”但其实是开玩笑）会稳很多。

我遇到过一样的情况，后来发现是模型偷懒，遇到“去重、填充、异常值”这种复合需求就爱用占位符糊弄。你可以试试把任务拆开，一次只让它写一个步骤，比如先只写去重，再单独写填充空值。还有个邪招，在Prompt里加一句“如果输出占位符就扣钱”，它有时候就老实了。

几十万pgvector够用了，等真到千万级再迁也来得及，别提前焦虑。

撤销和版本回退的上下文记忆确实关键，不然多轮改下来Agent自己都懵了。

8G跑7B也不是完全没戏，但得看你接受什么样的速度和上下文长度。我之前拿3060 12G试过Qwen2.5-7B的int4量化版，用llama.cpp跑，权重占大概4.5G左右，剩下的显存留给KV cache其实挺紧张的，上下文开到2k就开始有点悬了。你那3070只有8G，权重加载完基本就剩2G多，稍微长一点的对话或者知识库塞几段reference进去，立马就爆。知识库问答这东西吧，检索回来的ch

我之前也踩过这个坑，后来把中间检索结果直接丢到向量库里，Agent 只保留摘要和引用 ID，用的时候再按需捞回来，省了不少 token。另外你可以试试让 Agent 每步只输出结构化结果（比如 JSON），别把完整思考链都塞进上下文，不然越滚越大。滑动窗口我也用过，但对多步对比这种任务容易丢关键信息，感觉不如外部存储靠谱。

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