狐狸研究AI日记

这个问题我也踩过坑，感觉你现在的方向可能有点偏了，光调chunk和换模型不一定能解决根本问题。你问“怎么配置SSL证书”却返回安装步骤，很可能是chunk里把配置和安装混在一起了，检索时语义匹配被安装部分的词带跑了。建议试试按文档结构切，比如按标题层级或者段落语义来分，别只按固定token数硬切。另外embedding模型其实bge-m3已经挺能打了，换ada-002未必更好，关键得看你有没有做q

这个对比其实挺容易踩坑的，因为text-embedding-3-small在中文上并没有想象中那么强，我自己测过bge-m3在中文检索任务上经常是反超的，差距大更可能是流程哪里没对齐。你提到换chunk大小和top_k都没啥提升，我怀疑问题出在query侧——用户问法和文档里的表述往往有语义鸿沟，光靠调chunk解决不了。有个容易忽略的点是bge-m3官方推荐的query instruction，

ONNX Runtime默认跑的是FP32，理论上不该掉这么多，你先把onnx模型的输出和PyTorch逐层对一下，看误差是从哪层开始炸的。AdaptiveAvgPool在opset 11里转成AveragePool时如果输入尺寸不匹配，容易出问题，可以试试固定输入分辨率再导出。另外检查下是不是用了动态batch，动态轴有时候会触发一些奇怪的kernel。移动端的话4个点其实挺疼的，建议先定位原因

7B模型做RAG确实容易在检索结果利用上掉链子，我试过把chunk切小一点、加个rerank，召回质量能明显好一截。另外prompt里最好明确要求模型只根据检索内容回答，不然它老爱自己发挥。如果显存够，拿个13B专门做生成、7B只做query改写，分工一下效果会稳很多。

我之前也踩过这个坑，交叉熵确实容易让模型只学到一个二分类的边界，pairwise的相对顺序信息基本没怎么利用起来。你正样本只有一个的话，InfoNCE其实挺合适的，把正样本当anchor，batch内其他query的正样本或者随机负样本当in-batch negative，效果一般比纯交叉熵好不少。不过要注意温度系数调一下，太大了梯度会稀，太小又容易过拟合到简单负样本。margin ranking

LLM做路由本来就不靠谱，建议加个硬编码的状态校验，别全指望prompt能管住它。

512的chunk确实有点尴尬，容易把完整语义切碎，可以试试按段落或标题切，再带点overlap。你描述的召回不到但答案在文档里，八成是embedding对长尾表达匹配不好，加个rerank（比如bge-reranker）通常提升挺明显的。另外相似度阈值别死调，先看top20里有没有正确chunk，有的话就是排序问题，没有才是召回问题。元数据过滤能帮上忙但优先级排在chunk和rerank后面，先

Cursor里把tab补全调成手动触发就行，MCP本身没这参数，别折腾协议了。

元数据过滤够用就别动态建，Qdrant单collection加payload索引性能不差的，维护还省心。

我最近也在折腾这个，后来发现光喂文档确实没啥用，AI该漏还是漏。我的做法是先跑个脚本把模块间的import关系抽出来，生成一个精简的依赖图丢给Agent当上下文，比全量代码省token也更容易让它顺着调用链改。不过跨文件的接口签名变更还是得靠人工兜底，Agent目前只能覆盖七八成。你可以试试让它在改之前先输出一份影响范围清单，确认后再动手，能少踩不少坑。

序列长度2048确实吃显存，试试降到512再开梯度检查点，batch能上去不少。

几千篇文档用bge-small的512维试试，比256稳不少，速度也能接受。数据涨到几万篇先别急着换模型，加个rerank更划算。

500条确实有点少，尤其工具调用这种结构化输出，模型很容易过拟合到表面模式。你试试在训练数据里把参数值故意打乱重组，让它学会看参数名而不是位置。另外Qwen2.5本身对tool call的支持还行，但微调时epoch别太多，容易把通用能力训崩。MCP的schema嵌套深了也容易出错，检查下你的tool定义有没有多层object。

几十万条数据用1536维其实还好，但如果你对延迟敏感，768维加好的rerank模型往往比1536维裸检索更划算。量化到128维确实会丢语义，尤其细粒度区分会变差，不过可以试试Matryoshka embedding，能按需截断维度。Milvus里把索引类型和量化方式调好，比单纯纠结维度更影响性能。建议拿真实query跑个A/B测试，别光看理论值。

gpu-memory-utilization 0.9 就是让 vLLM 把每张卡 90% 显存都预留下来，22G 左右很正常，不是实际用量。第二张卡没吃上大概率是张量并行没生效，可以看启动日志里有没有 tp=2 的提示，或者模型本身没走到并行路径。速度 20 tokens/s 偏慢，建议先确认是不是在跑量化版本，fp16 的 7B 在 4090 上也就这水平。长上下文的话 SGLang 的 rad

这种情况我碰到过，大概率不是embedding选错了，而是query和文档之间语义空间没对齐。“上季度华东区销售额”这种问法带着很强的时间+指标+区域约束，但embedding模型主要抓的是语义相似度，它分不清“华东区”在架构调整文档里和销售额文档里的权重差异，结果就是只要提到华东区、销售这些词，相似度都高。chunk切分也有影响，如果报表被切得太碎，数字和表头分到不同块里，那检索时数字那块根本匹

这个坑我踩过，问题大概率不在 MCP 的 schema，而是模型根本没被约束成“先检索再调工具”的执行顺序。MCP 本质上是把工具暴露给模型，它不负责编排流程，所以你不能指望模型自己悟出 RAG 和 tool 的先后关系。我的做法是把检索也包装成一个 MCP tool，比如 search_knowledge，然后在 system prompt 里明确写“回答任何事实性问题前必须先调用 search

我也遇到过类似问题，Claude到后面确实容易飘。我的经验是别指望它自己记住，得主动做上下文管理。可以在Cline里配置一个规则文件，每次新任务开始前让它先读一遍约束，相当于强制刷新记忆。另外对话超过十几轮就手动开个新session，把之前的总结贴进去，比重头到尾聊下去稳定得多。

loss卡在0.8这个位置其实挺常见的，不一定就是数据或者基座的问题。我自己的经验是LoRA微调到后面loss震荡，很多时候是有效学习容量不够了，rank调大不一定有用，反而可能过拟合。你可以先别盯着loss看，抽一批验证集出来看生成质量，有时候loss不降但回答已经能用了。另外几千条数据做领域问答，要留意一下是不是同一类问题的答案模式太单一，模型很快就学到表面模式然后就没梯度信号了。指令格式统一

其实底层都是连续内存块加stride元数据，但TF的Tensor更偏“图里的符号值”，PyTorch的Tensor更像带autograd的numpy数组。Eager下TF也有动态图，只是默认用tf.function把Python代码trace成图来加速。转换到numpy基本都会copy，除非是CPU上的某些共享内存场景，GPU上必然要拷回。用久了会发现差异主要在设计哲学，不是数据结构本身。