深度学习方法论

温度调低确实有用，我一般设0.1到0.2，但还是会有漏网之鱼。后来发现关键是在prompt里要求模型先摘出相关原文句子再作答，相当于逼它走一遍引用流程，编造的概率会低不少。另外可以试试在检索结果每块前面加编号和来源，让它回答时带上角标，这样你也能快速判断是不是在瞎编。

自己玩的话真别硬上TensorRT-LLM，光转engine那套就够折腾半天，调参调到你怀疑人生。vLLM其实已经够用了，7B模型吞吐比transformers快好几倍，报错的话建议先确认下CUDA版本和模型架构支不支持，很多坑都是版本对不上。Ollama和llama.cpp胜在开箱即用，但并发一上来就拉胯，看你更在意省心还是在意性能。我现在是vLLM跑服务，本地随手测试就用Ollama，两套切换

我踩过一模一样的坑，当时也以为是模板写得不够细，后来改了半天才发现问题出在“先总结再回答”这个指令本身。RAG的上下文本来就是检索出来的碎片，模型看到一堆不连贯的段落，你让它总结，它就容易把不同文档里的信息强行拼在一起，像你说的编表格就是典型症状。其实简单的事实型问题根本不需要总结这一步，直接让模型从上下文里抽答案反而更稳。我后来把模板拆成两类，事实查询用极简指令，比如“只根据上下文回答，找不到就

几百条数据微调7B做rerank，感觉量有点少，模型很容易过拟合到标注风格上，反而把原本embedding的泛化能力带偏了。我之前也踩过类似的坑，后来发现不如先用cross-encoder小模型试试，或者拿GPT-4o直接做few-shot rerank，效果比硬微调稳。你训练时正负例是怎么构造的，负例是随机采的还是hard negative？这个对rerank影响特别大。

我之前也踩过这个坑，光调chunk_size其实治标不治本。真实查询里的数字和细节往往被切散在两三个chunk里，embedding再准也召回不全。后来我改成按语义边界切，再给每个chunk加上标题和上下文前缀，效果明显好转。你们文档结构复杂吗？如果有表格和层级标题，建议先预处理再入库，别直接丢给splitter。

你说的这两个方向其实都可能有问题，但我觉得你文档里有扫描件和表格这点更致命。扫描件OCR出来的文本质量差的话，embedding再牛也白搭，检索出来全是噪声。建议先拿几个bad case把原始chunk打出来看看，大概率能发现文本本身就乱七八糟。reranker确实能救一些，但它是在召回结果里重排，如果top50里压根没有对的内容，它也无力回天，先把数据质量这关过了再说。

7B跑Agent确实吃力，我拿14B做function calling都经常翻车，最后还是老老实实调API。

线上掉点大概率不是embedding模型本身的问题，先盯并发下的faiss索引和动态加载那块的线程安全，我们之前也踩过类似的坑，多线程读同一个index偶尔会拿到脏数据。切块512对表格和代码确实太粗暴了，硬截断后语义直接散掉，召回不相关太正常了。建议先把切块换成按结构走，表格单独处理，代码用语法边界切，再把embedding服务改成常驻加请求队列，基本能定位到是哪块在拖后腿。

几十万条这个量级其实Qdrant单机版完全扛得住，Docker一条命令就跑起来了，比Milvus那套etcd+MinIO+Pulsar的组合轻太多了。我之前也是faiss转过来的，换Qdrant之后增量更新舒服很多，不用每次重建整个索引。Chroma的话小几千条还行，上到几十万检索延迟会明显上来，不太建议。个人项目除非你要上亿级别或者需要分布式，不然真没必要折腾Milvus。

2e-4对LoRA来说确实偏高了，我一般从1e-4甚至5e-5起步，rank 8配这个学习率很容易把通用能力冲垮。2万条数据跑3个epoch也有点猛，试试1个epoch或者加个验证集早停。数据配比上可以掺10%-20%的通用指令数据，能明显缓解遗忘。重复跑题可能还跟训练时只mask回答部分有关，检查下label有没有把prompt也算进去。

同款3090，之前试过在小 Bert 上硬上 compile，收益也就 5%-8%，跟你差不多，后来发现瓶颈根本不在计算，而是数据加载和 GPU 利用率没吃满。动态 shape 报错太正常了，torch.compile 对变长序列的支持本来就没完全落地，建议要么固定长度要么用 bucket 把长度分档。你这种规模其实 eager 模式调好 batch size 和梯度累积，效果不会差太多，部署推理

这情况多半是向量检索扛不住精确匹配，试试bm25粗筛加向量重排，小项目用bge-reranker-base够使了。

我之前也踩过类似的坑，特别能理解你说的“按段落太长、按句子太碎”这个矛盾。后来我试了折中方案：先按语义段落切，再对超长段落做个二次切分，但切分点选在二级标题或者逻辑转折词附近，这样能保住上下文。另外你提到“保修期”那个例子，其实光靠切片粒度解决不了，关键得看你的检索策略——我后来把每个切片的上文摘要（比如前两句）作为元数据存进去，召回时让embedding同时匹配正文和摘要，漏上下文的情况改善很多

动shape这个点基本就说到根子上了，torch.compile对静态shape的优化最狠，一变长就得重新编译，来回折腾的开销比省下来的还多。我之前试过把输入padding到固定长度，配合cudagraphs，小模型上确实有提升，但7B这种规模显存本来就紧，padding浪费的空间反而让batch size降了，最后收益被抵消。 另外你用的是默认模式，默认的max-autotune其实没开，很多

我之前也踩过这个坑，后来发现问题可能出在“过度约束”上。模型不是被你教坏的，而是被你“框”住了，尤其那些边界条件反而容易让它产生误解。建议把核心任务（提取哪几个字段）单独拎出来写清楚，格式用最简单的模板，few-shot控制在两三个以内，而且示例要和你的真实数据风格贴近。另外，如果JSON乱，可以试试让模型先输出纯文本再单独做一步解析，别让它在一步里又思考又格式化。 --- 说实话，500字那

试试把首轮关键实体抽出来单独存个短期记忆槽，检索时跟当前query做加权融合，比硬拼历史稳。 我们生产里是让LLM先判断是否依赖上文再决定改写还是直查，能省不少无效召回。

数据投喂这个点确实扎心，我给孩子用这类产品时最怕的就是越用越像做题机器。不过如果T90真能靠对话摸清思维卡点，那可比单纯堆错题强多了，至少算从“刷题”往“诊断”挪了一步吧。我倒好奇它对那种“非标准答案”的解法会不会给正向反馈，不然孩子脑子里冒出怪点子的时候，被AI拉回标准路径，那发散思维反而更危险了。

负样本这块你猜得没错，随机采的负样本对法律这种专业领域来说区分度太低了，模型根本学不到“像但不对”的边界，建议试试用BM25或者别的embedding先筛一批高相似的做hard negatives。另外温度参数也值得调低一点，比如0.05左右，不然正负样本的梯度容易被拉平。至于通用能力下降，微调时混入一部分通用语料能缓解，但别指望完全保留，毕竟领域专精和通用性本来就有trade-off。还有个细节

试试父子chunk吧，小块检索大块喂给模型，表格代码单独走解析器。

2000条数据对7B来说有点少，客服对话格式也容易破坏基座能力，建议先拿100条试跑对比下loss。