一线数据分析笔记
Lv.1主要整理数据分析相关的学习笔记与工程经验，内容覆盖工程化处理流程、业务数据解读。重视可维护性、稳定性与协作效率，希望把复杂问题讲清楚、把实践步骤写完整。
发表的评论
2k序列对8B模型确实偏长，先试试把max_length砍到512看还爆不爆，Flash Attention优先上，比ZeRO-3省心多了。
两千条数据做垂直领域微调，说实话量确实偏少，模型很容易学到一些表面模式而不是真正的领域知识。你loss正常不代表泛化好，很可能过拟合到训练集的问答格式上了，所以推理时格式乱掉、答非所问。我之前也踩过这个坑，后来把数据扩充到五六千条并且混了一部分通用数据进去，效果才稳下来。另外检查一下推理时的prompt模板跟训练时的格式是不是一致的，这个不一致特别容易出问题。
有没有更详细的教程推荐？
有没有更详细的教程推荐？
学到了，感谢分享！
学到了，感谢分享！
学到了，感谢分享！
有没有更详细的教程推荐？
我之前也遇到过类似问题，后来换了方案。
试试把上一轮的query改写后再检索，别直接拼结果，不然噪音太大。
两张4090跑Llama3-8B的LoRA，batch size=4就OOM其实挺正常的，别忘了4090只有24G显存，模型权重加载完加上优化器状态和激活值，留给batch的空间真不多。你LoRA rank=32确实偏高了，做客服问答这种任务rank 8到16基本够用，rank翻倍显存占用也会涨不少，建议先降到16试试，说不定batch就能开到4了。gradient accumulation那个抖
这种格式漂移太常见了，我去年做类似项目时也踩过一模一样的坑。你验证集loss降了不代表模型真的学会了严格遵循schema，因为它本质上还是在做下一个token预测，多一个换行或少一个空格对loss影响很小，但对解析器就是致命的。我的经验是，靠微调让7B模型百分百输出稳定JSON或者固定格式，基本不现实，尤其是工具名这种需要精确匹配的字段。后来我们改成在推理侧做约束解码，比如用outlines或者l
我们之前也踩过这个坑，后来在切分时给每个 chunk 带上 doc_id 和版本号，更新时先按 doc_id 删旧向量再插新的，Faiss 得自己维护 id 映射，挺麻烦。换成 Milvus 或 qdrant 会省心很多，它们支持标量字段过滤和按条件删除，配合 upsert 基本能搞定增量同步。不过去重和切分策略还是得自己控制好，不然版本一多照样乱。
bge-m3确实有点重，几万条文档的话可以试试bge-small或者text2vec-base这种，embedding延迟能降不少。向量库换milvus收益不大，瓶颈主要在模型推理上，FAISS本身检索已经很快了。MCP层缓存可以自己加个LRU，对query做hash存结果，命中率其实不低。另外注意下是不是每次都在重新加载模型，这个坑挺常见的。
我们之前两种都跑过，最后生产环境选了API转发那套。本地vLLM确实快，但多人并发一上来显存就炸，还得搞队列和限流，维护成本比想象中高。MCP这边只做转发其实挺香的，模型迭代跟MCP服务解耦，发版互不影响，出问题也好排查。多版本的话可以在API网关那层做路由，MCP只传个model标识就行，别把版本逻辑塞进MCP里。
温度管“敢不敢选冷门词”，top_p管“从多大池子里挑”，我一般结构化输出直接temperature=0，top_p默认就行。
ROIAlign和NMS确实是坑，TensorRT原生不支持这俩，得自己写plugin或者用TRT的NMS插件（8.6有内置但限制挺多）。动态shape报Invalid shape大概率是onnx里某些维度推导成了-1或者跟profile对不上，建议先用polygraphy跑一下onnx的shape推断，看哪一层断了。opset版本也关键，ROIAlign最好用opset11以上导出，低版本算子拆
这种解释性尾巴基本是模型天性，光靠加粗和强调很难根治。我现在都是直接上JSON mode或者function calling，从解码层面限制格式，比反复调Prompt省心多了。如果非要用普通接口，那就在Prompt里给一个完整输出示例，让它照着抄，比单纯说“只输出JSON”管用。另外返回后还是得加一层正则或json.loads兜底，别指望模型百分百听话。
先加重排序把相关片段压到最前，再在prompt里让模型逐条列出约束，不然它真容易漏。
双通道检索试试，当前轮和摘要各查一次，再合并去重，比纯滑动窗口稳很多。