计算机视觉工程手记

几十万文档其实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

试试先做query改写，把口语补全成书面语，检索效果能明显提升，切块倒不用急着换。

试试把子任务的输出用few-shot固定住，别光靠描述格式，给个例子模型就老实多了。

试试把工具A的输出直接塞进工具B的prompt里强制绑定，或者用LangGraph的显式状态流，ReAct对顺序依赖确实太随缘了。

我最近也踩过这个坑，LLM路由不稳真的太真实了。我的做法是给每个向量库加一层关键词预过滤，比如财报库绑定“营收、净利润、增长率”这些词，新闻库绑定“股价、事件、传闻”，命中后再让LLM做二次确认，准确率能上来不少。另外打平到一个库确实省心，但前提是切片本身带元数据标签，不然硬匹配很容易被语义相近的财报内容带偏。你试过给每个切片生成一个摘要式标题吗？我加了之后路由判断明显稳了。

说实话我不太建议在server里塞system prompt，MCP的职责边界会变模糊，而且不同client对server返回内容的处理方式不一样，很容易出现预期外的行为。我试过在server端做输出格式约束，结果发现有些client会强制覆盖掉，反而更乱。现在我的做法是server只返回结构化数据，规则全放client的system prompt里，这样每个工具都能复用同一套规范。如果你担心影响

我之前也踩过这个坑，60%的召回大概率不是Milvus的问题，而是特征本身没做好。ResNet50直接出的2048维向量是分类任务的副产品，对细粒度相似度不友好，建议试试先做PCA降维到256或512维再归一化，效果往往立竿见影。另外L2距离对图像特征不太稳，换余弦相似度或者用faiss的IVF索引调大nprobe值，召回能涨不少。你查不出来的那40%是颜色相近但结构不同，还是完全同类的图？如果是

我之前也踩过类似的坑，最后发现是chunk切太碎导致的，256字符确实容易把一句话拦腰截断，模型硬凑上下文就很容易飘。你可以试试把chunk调到500-800字符，或者加一点重叠（overlap），让相邻片段有衔接。另外prompt里别把“仅基于上下文”写得太死，改成“优先参考上下文，但可结合自身知识补充”会稳很多。定位问题的话，建议先单独打印检索出来的chunk拼接后让模型回答，如果还是乱，就是

我之前试过类似场景，长短混合训练确实比固定长度稳，但关键是别让长Prompt喧宾夺主。你800 token那组如果背景信息占了大头，模型很容易学会“凑字数”而不是聚焦答案。我后来把长Prompt里的背景压缩成核心实体+关系，效果反而好了。你试过在数据里按比例混个20%的极端长样本吗？