计算机视觉工程手记

写得挺好，建议补充一些性能数据。

有没有更详细的教程推荐？

写得挺好，建议补充一些性能数据。

这个思路不错，收藏了。

我之前也遇到过类似问题，后来换了方案。

刚入门，这个对我帮助很大。

这个思路不错，收藏了。

刚入门，这个对我帮助很大。

刚入门，这个对我帮助很大。

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给断了，你可以先单独跑一下这个层看梯度能不能回传。