隔壁架构师手记

先主攻PyTorch，面试能讲清项目比会几个框架重要，TensorFlow入职再补也来得及。

两个都用过，说点实际的。Milvus功能确实全，但部署是真重，etcd、minio、pulsar一堆组件，小团队维护起来心累。Qdrant单机跑起来轻松很多，Rust写的性能也不错，但分布式那块成熟度还是差些，集群出问题排查资料不好找。如果数据量不大、就图个省心，我偏向Qdrant；要是上大规模还要一堆索引类型，那只能咬牙上Milvus。

优先官方肯定稳一些，社区的先看star和最近有没有人维护，跑不通基本就弃了。

出海最难搞的其实是文化适配，光靠算法堆数据真不够。

两个都上过生产，说点实际的。Milvus功能确实全，但那个依赖栈真的重，etcd、MinIO、Pulsar一套下来，运维成本不低，小团队慎入。Qdrant单机部署清爽很多，Rust写的性能也稳，但分布式这块成熟度还是差点意思，集群模式踩过几次坑。Milvus的坑主要在版本升级，之前从2.2升2.3 collection直接读不了，得重建，文档里写得也不清楚。Qdrant的话，filter跟向量检索

先抓包看MCP转发时query有没有被改，八成是编码或转义搞的鬼。超时那个也遇到过，把RAG改同步返回就稳了。

只用本地文档确实没必要上MCP，它的价值在工具多且杂时统一调用，单一检索场景纯属折腾。

别在一个对话里改，每加个需求就重开并贴完整代码，让它只动对应部分。

我之前也踩过这个坑，后来干脆放弃在回调里拼最终答案，只拿它做状态通知，比如工具开始/结束、错误上报这些。流式token单独用一个异步队列接出来，前端消费队列做打字机效果，最后再从AgentExecutor的invoke结果里取完整输出，这样两边就不会打架了。工具调用导致流式中断其实挺正常的，因为中间那段本来就不是LLM在生成token，建议用事件类型区分，别指望一条流走到底。

微调后检索变差挺常见的，loss降不代表向量空间还保持原来的语义结构。你用的正负样本对如果只覆盖了术语区分，模型可能把整个空间扭曲了，反而丢了通用语义。建议先别急着换学习率，把微调前后的embedding做个可视化对比，看看是不是坍缩了。另外微调完一定要重建索引，不然新旧向量混用肯定乱套。

我们之前也踩过差不多的坑，bge-large-zh其实对中文语义还行，但它对chunk的粒度挺敏感的。你光调大小不太够，得看文档结构，像我们做产品手册那种，按标题层级切比固定长度好很多，语义完整度完全不一样。重叠区间别设太大，10%到15%就够，设多了反而让相邻chunk太像，召回时互相挤排名。top_k的话我一般先设10，再靠rerank往下压，直接卡3到5容易漏。rerank真的值得上，bge

确实会有这个问题，我生产环境一般最多挂3个核心的，其他靠动态路由按需加载。取舍主要看工具描述和上下文相关性，建议加个缓存层。

这问题我也踩过坑，大概率不是Agent逻辑写崩，vLLM那边max_model_len设4096看着不大，但Qwen2.5-7B跑tool call时，多轮工具返回和系统提示词会悄悄撑爆上下文。你先在vLLM日志里看下卡死前的token数，如果每次都接近上限那就是这个原因。另外建议把LangChain的对话历史做下截断或者摘要，只保留最近几轮，不然每轮tool结果都堆进去，显存肯定吃不消。我之前是

先别急着换embedding，把PDF转成带标题结构的markdown再切chunk，召回率能上来一大截。 召回和生成都先别管，拿几个问题去检索下，直接看返回的chunk是不是答非所问，定位到具体环节再调。

我最近也踩过这个坑，几百篇文档的库，top-k拉到20基本就是灾难。后来试了试在Chroma后面接一个cross-encoder做重排序，效果立竿见影，比单纯调阈值靠谱多了，因为bi-encoder检索本身就是为了召回，粗排精度不够很正常。你用的LangChain里其实可以直接挂Cohere Rerank或者HuggingFace的cross-encoder模型，把召回chunk压缩到5个以内再喂

别急着降维，先看你的数据量级，几千条用1536没问题，换模型确实要重新生成向量，但更建议固定一个别乱动。 维度高低影响没那么玄乎，召回率主要看你切块和query处理，换384维的反而可能丢细节。

先检查下预处理和后处理是不是一致，ONNX这边经常是图片归一化或者letterbox尺寸没对齐导致的偏差。

图片去重完全可以，感知哈希对旋转裁剪太敏感，向量特征稳得多，我试过效果不错。

这个评测角度挺有意思的，特别是动态任务分解那块儿，正好戳中了我之前用GPT Agent时的痛点。我之前拿它做一个小型电商站，遇到环境配置报错它就死循环了，非得我手动改prompt才肯换思路，确实没有那种“自己想办法绕过去”的灵性。不过你那个5轮测试的样本量还是有点小，40%的差距会不会跟项目类型相关性太强？比如如果是纯CRUD应用，可能差距就没这么明显。另外我比较好奇的是，Agent 2.0在调试

先让LLM把历史对话改写成独立的当前query，再拿去检索，效果比直接拼历史稳很多。 我之前也踩过这坑，后来加了一步意图识别，只抽跟当前问题相关的实体和指代，检索准多了。