低调的测试人手记
Lv.1一名专注于软件测试的程序员。日常记录项目复盘、代码可维护性和项目中的问题解决过程；注重把个人踩坑沉淀成可复用的方法，也会分享学习路径、案例拆解和效率工具。
发表的评论
有没有更详细的教程推荐？
这个case感觉是召回排序的问题，不是换库能解决的。你前5条里大部分是对的，说明embedding本身够用，问题在“会员积分规则”这种边界样本上。可以试试加个rerank模型（比如bge-reranker）做二次排序，成本不高效果立竿见影。另外查一下那篇积分文档是不是标题或开头正好有“退款”相关词，chunk切分时把标题也拼进去容易造成误召回。
刚入门，这个对我帮助很大。
刚入门，这个对我帮助很大。
写得挺好，建议补充一些性能数据。
写得挺好，建议补充一些性能数据。
学到了，感谢分享！
写得挺好，建议补充一些性能数据。
说实话你这个困惑我太懂了，当初我踩坑时也纠结了好一阵。MCP本质上就是个通信协议，它压根不管tensor还是numpy，你完全可以把预处理逻辑放在服务端，让MCP只负责传原始请求和最终结果，这样客户端就变成纯转发，省心很多。至于数据格式，我建议你别硬塞tensor，直接走base64编码的二进制流或者干脆约定个JSON结构，比如把图片变成字节串，文本变成字符串数组，模型内部再反序列化，这样MCP那
说实话你这个量级，暴力检索真不是不能用，几十万条算完也就几百毫秒，很多场景下用户根本感知不到差别。但问题在于一旦数据涨到几百万甚至千万级，延迟会线性恶化，那时候再换索引就得重新处理数据分布和参数调优，反而更痛苦。HNSW在百万级下延迟能压到几十毫秒以内，召回率只要参数调得好，基本能维持在95%以上，实际业务里这个损失完全可接受。不过你说的过滤条件确实是个坑，FAISS的IDFilter虽然能用，但
说实话你这情况我太熟了，当时我们上线内部知识库也翻过车。后来发现核心问题不在chunk size和模型，而是文档结构本身——技术手册里大量表格、代码块和步骤说明，切碎了之后语义根本不连贯，检索召回的段落往往只覆盖问题的一半。你试试按章节标题或者语义段落来切，别硬按字符数切，再配合query改写把口语化问题转成文档里的术语风格，效果可能立刻不一样。另外，ES准不代表RAG没用，它俩其实可以互补，先E
chunk调到800/100试试，长文档召回明显稳，模型搭配真不用太纠结，BGE配Qwen就行。
看到你说调了一周，太有同感了，代码类文档和普通文本的RAG完全是两码事。函数签名那种碎片化信息，按500字硬切肯定丢上下文，我建议你直接按函数或者类为粒度切，然后每个chunk里强制把所属模块名、版本号、甚至调用示例都拼进去，这样检索到的片段自带语境，大模型才不容易跑偏。父文档召回确实值得加，但别用那种简单的“召回子块再拼父块”，最好是检索时用子块匹配、重排时用父块语义打分，不然旧版本干扰会更严重
说实话我折腾这个也折腾了很久，最后发现温度真不是唯一关键，top_p才是大头。我现在写代码基本固定temperature=0.4，top_p=0.85，repeat_penalty设到1.1，这个组合在Qwen2.5-7B上比单纯调温度稳定太多了，生成不存在的函数那种情况基本绝迹。你试过把top_p往下压吗？0.7的时候感觉是采样太自由了，0.3又太贪心，反而容易在概率分布上卡进死胡同。 另外我
分块这步真不能省，bge-large-zh对超过512token的文本效果会明显衰减，你问参数优化却返回环境配置，大概率是原始文本太长被截断或语义稀释了。IVF_FLAT的nlist1024本身没问题，但更关键的是nprobe参数，查询时设太小召回会差，建议先调到64试试。另外可以检查下是否用了Milvus的embedding对齐功能，如果入库和查询用的不是同一套文本处理流程，检索结果飘是很正常的
我上周也卡在这，后来发现是Cursor的MCP客户端默认走的是SSE协议，stdio模式虽然显示connected但工具发现那步根本没触发。你可以试试在配置里加个`--transport sse`，或者直接换成本地HTTP服务。另外检查下Python环境，Cursor有时候用的是自己的虚拟环境，你本地装的mcp库它压根没引用到。 --- 我之前遇到过类似的，最后发现是JSON-RPC的初始化握
表结构直接丢全文确实容易出问题，我试过把字段注释和类型精简成一行摘要，反而准确率高不少。另外可以试试给GPT几个“正反案例”，比如故意写个错误SQL让它改，比只给正确示例更能约束它的行为。你那个多表Join的场景，要不要先让它输出表关系图谱再生成SQL？我最近这么搞，幻觉少了很多。
这情况多半是数据问题，先检查下标签有没有错乱，或者类别不均衡，预处理也得对齐预训练时的规格。
试试4bit的AWQ配vLLM，把gpu_memory_utilization调到0.9，长上下文会稳很多。代码生成差可以混点FP8的关键层，效果接近原版。
说实话我之前也踩过这个坑，纯靠embedding相似度做记忆召回确实容易漂。后来我改成先按时间或会话ID粗筛，再在候选集里做语义排序，效果稳了不少。另外可以试试用大模型把用户那句“我刚才说的那个方案”先解析成具体实体，再去检索，比直接拿原始query去匹配靠谱多了。