计算机视觉工程手记

loss卡在1.8还开始吐套话，这个信号其实挺典型的，不一定是学习率的问题。我去年也拿LoRA微过一个7B做合同问答，情况跟你几乎一样，后来发现是数据里短答案占比太高，模型很快就学会用“根据相关法律规定”这种万能句式去糊弄，因为它在训练集里出现的频率实在太高了。你可以先抽样看看训练集里有多少条答案是以类似模板开头的，如果超过三成，那loss不降基本就是模型找到了偷懒的捷径。另外判决书本身结构重复度

这个差距确实挺常见的，我们之前也踩过类似的坑。text2vec-base是768维，ada-002是1536维，维度高不一定就更准，但ada的语义泛化能力确实强不少，尤其你这种query和doc用词不完全重合的场景。数据本身也有影响，如果技术文档里也老出现“客户”“投诉”这种词，小模型就容易跑偏。建议先拿几百条query对比下hit rate再决定要不要全量重做，别一上来就烧钱。

表格和长段落混着的话，粗暴按字数切确实容易把语义切碎，报销和差旅这种词向量本身就接近，召回混很正常。我之前也踩过这个坑，后来先做一轮版面/结构解析再按语义块切，效果提升挺明显的。rerank真不是玄学，尤其你这种容易混淆的场景，能拉回不少相关性，但前提是候选里有对的东西。可以先把召回top20拉出来人工看几条，确认是召回问题还是排序问题，再决定要不要上rerank。

这个问题我也踩过坑，感觉核心不是top-k设多少，而是召回之后缺了一层“过滤+重排”。你可以先加个cross-encoder或者bge-reranker对召回结果重新打分，把明显只是关键词撞上的那几段压下去，效果比单纯调k值稳很多。另外我试过按文档类型分层，技术手册和FAQ用不同的prompt模板去处理，因为FAQ往往一问一答很干净，手册里的段落却经常需要拼上下文，混在一起喂确实容易自相矛盾。还有

先手写个能跑通的最小流程，再让AI照着改，不然它老拿旧API糊弄你。

固定512切分对表格和跨页逻辑确实很容易切碎，检索时好时坏大概率是chunk边界把语义切断了，换个问法命中不了很正常。我自己踩过类似的坑，后来把chunk size降到256、overlap提到80左右，表格单独抽出来做结构化处理，效果明显稳了一些。语义切分可以试，但别指望它万能，它更依赖分割模型的质量，有时候反而把长依赖拆散了。embedding这块BGE-large-zh本身不差，但要注意qu

这个场景我也踩过类似的坑，感觉你描述的问题不完全出在prompt上。3000字以上的多文档塞进去，模型注意力本身就会被稀释，尤其GPT-4对中间位置的文档召回率明显下降，这跟你怎么写指令关系不大。我后来试过把top5压到top3，再按相关性排序，把最关键的放开头和结尾，效果比堆few-shot稳不少。另一个思路是别让模型直接读原始片段，先用一次调用把每篇文档压缩成两三句和问题相关的摘要，再拼起来回

我之前也踩过这个坑，PyTorch的log和除法在接近零的时候确实更容易出NaN，TensorFlow有些算子默认加了epsilon。你可以重点查一下损失函数里有没有log(p)这种操作，手动clip一下概率值试试。另外混合精度训练也会导致类似问题，看看有没有开amp。

几十万文档其实pgvector就够用了，加个HNSW索引过滤性能也还行，关键是省掉了独立部署那套东西。Milvus确实重，etcd加kafka那套单机跑起来就是灾难，除非你们团队有人专门维护。Chroma的问题就是它定位本来就是轻量demo，别硬扛生产。建议先压测一下pgvector，真扛不住再考虑Qdrant这种单二进制部署的，比Milvus友好太多。

豆瓣这种站其实用不着上代理池，新手折腾那个纯属浪费时间。你被封大概率是请求频率太密加上header里缺了Referer和Accept-Language这些，光换UA没用的。建议让AI帮你改成用requests.Session，把浏览器那套常用header补全，再把延迟调到2到5秒随机，基本就能稳住。真要做大规模采集再考虑代理，练手阶段先别给自己加难度。

你backward是不是没return对梯度的顺序？我之前也踩过坑，自定义层里如果参数没通过nn.Parameter注册，或者backward返回的梯度跟forward输入顺序对不上，autograd就直接静默不更新了。另外MCP如果自己包了一层计算图，很可能把中间节点的grad_fn给断了，你可以先单独跑一下这个层看梯度能不能回传。

温度降到0确实会稳很多，但我一般还会加个输出解析兜底，免得它偶尔抽风。

我之前也踩过这个坑，LoRA微调时如果直接把检索片段当输入去训，模型很容易学会“抄”而不是“用”，尤其是片段本身有噪声的时候。后来我的做法是把微调目标定在“基于片段做改写和融合”上，训练数据里混入一部分无检索的通用问答，防止灾难性遗忘。数据构造上别只用“问题+片段+答案”，最好加入一些片段无关或部分相关的负样本，让模型学会判断什么时候该依赖检索、什么时候靠自己。另外检索质量波动确实会带偏模型，可以

两百篇就乱，大概率是chunk切太碎了，先按标题切试试，关键词过滤可以加但别指望它救场。

说实话，我之前在MCP上搞类似适配也踩过这个坑。你直接把工具描述和示例塞进训练数据，模型很容易学到“格式幻觉”，尤其是纯文本和JSON混着来的时候，它自己就懵了。我的做法是先做一个轻量级的预处理层，把不同工具的返回值统一包装成带类型标记的schema，比如强制加一个“dataType”字段，这样微调时模型只需要学会读这个标记，而不是靠猜。不过光靠预处理不够，prompt里的格式说明也得写得像“合同

题简单时不需要CoT，反而容易画蛇添足，试试只在真正多步推理时再引导。

说实话你这个情况我太熟了，之前我调RAG也卡在这。512的chunk对配置类文档来说大概率是偏大了，尤其功能变更记录和操作手册混在一起时，语义边界特别模糊，模型很容易把“提到过该功能”当成“在讲该功能怎么用”。我后来改成按文档结构切分，比如标题、步骤、表格单独成块，再把chunk降到256左右，效果立竿见影。另外bge-m3本身不差，但纯向量检索对“怎么配置”这种指令型问题确实弱，建议你试试小权重

试过AWQ量化加tensor parallel，8个并发稳在40G左右，长文本没缩水但得调下gpu_memory_utilization。 量化后吞吐会掉一点，但你这场景明显显存是瓶颈，建议先上4bit试试，vLLM对Qwen支持还挺顺的。

说实话你这情况我太熟了，之前也是卡在60%上不去。建议先别碰微调，大概率是chunk切得太机械，试试按标题和段落结构做语义切分，把每个chunk带上文档名和章节路径当元数据，效果能立竿见影。另外parent-child结构值得试，但重点是小chunk召回、大chunk给LLM，别搞反了。还有个容易忽略的点是PDF里的表格和页眉页脚，转出来经常是脏数据，清洗一下比换模型有用。 --- 固定500

loss曲线下降不一定代表模型学到了东西，我怀疑是tokenizer和模型之间没对齐，比如special token设置错了，或者数据里混入了奇怪的字符。你可以先试试不微调直接加载原模型跑一下同样的话，排除是不是生成参数的问题。另外200条数据训练LoRA有点少，rank值建议先设8或16，学习率2e-4对7B模型可能偏高了，降到1e-4或者5e-5看看，我之前踩过类似的坑，乱码多半是embedd