实战派推理加速应用札记

“2023年营收”召回成“2022年”这种，多半是切片把年份和数字切散了，或者embedding对数字本身就不敏感。建议先试试混合检索，BM25对这类精确关键词特别管用，再用RRF融合，比单纯调HNSW参数见效快。query扩展也可以做，但别用LLM瞎扩，容易引入噪声，不如直接抽关键词做多路召回。efConstruction影响没那么大，efSearch调高点更实际。

这事我踩过不少坑，后来发现核心问题不在Prompt写得好不好，而在于AI根本没法像人一样持续维护一个“心智模型”。你给它再多约束，它每次生成都是在局部做概率补全，类之间的调用关系、状态流转这些跨段落的依赖，它记不住也推不动。我现在做法是把任务切得更碎，一次只让它写一个函数体，输入输出用类型标注钉死，上下文我自己在代码里拼好再喂给它，反而成功率上来了。few-shot确实容易翻车，例子给多了它会把例

我一般会在system里写“优先用<context>回答，不足时明确说不知道”，但别指望模型百分百听话。实测few-shot放一两个“文档没有就承认”的例子，比光讲规则管用。还有个坑是检索质量差的时候，你prompt再漂亮也白搭，先把召回率搞上去。

试试把实际CSV的几行样例和期望输出直接喂进去，比光说需求管用多了。

这问题我太熟了，Cursor默认会把整个文件当上下文，你只想要它动一块，它却觉得哪儿都能优化。我一般是先把已经写好的函数用注释块包起来，或者干脆拆到单独文件里，再让它只针对新文件干活。另外在提示词里明确写“只新增，不要修改现有函数”，配合diff预览，能省不少回滚的功夫。

纯中文场景下BGE其实挺能打的，尤其large-zh版本，跟ada-002比差距没想象中大，有些垂直领域甚至反超。OpenAI的优势主要在跨语言和泛化上，如果你们数据全是中文，用BGE完全够。Rerank确实能兜底，Embedding召回个七七八八，后面精排能拉回来不少，所以前期不用太纠结。建议先拿几百条真实query做个召回评测，别凭感觉，数据说话最靠谱。

LangGraph确实能搞，把带状态的工具放节点里，并发用线程局部变量存token就行，不用每次重认证。

能稳定解决实际任务就算入门，进阶就看你能不能把复杂问题拆成可验证的小实验了。

把预期输出拆成几个边界case写进prompt里，比堆描述管用，我试过能少改一半轮次。

50万条faiss慢很正常，更新全量重建这痛点太真实了。我建议直接上Milvus，pgvector在数据量上来后性能衰减也明显，而且Milvus支持增量更新和混合检索，你不用自己拼两套系统。中文场景BM25+向量基本是标配，单靠向量对专有名词和短query很容易翻车，ES那边做混合检索生态更成熟但运维成本高，Milvus现在也够用了。你更新频繁的话，最好先把文档切分和embedding的增量流程设

我之前调过类似的，问题大概率出在分片后的nlist上，800万数据拆成8个分片，每个分片单独建索引时nlist得按分片内数据量重新算，不是简单沿用全局配置。另外PQ量化在分片场景下误差确实会被放大，建议先试试把nlist调大几倍，或者临时换成flat索引对比一下，这样能快速定位是索引还是模型的问题。还有个坑是Milvus的相似度阈值默认用的不是余弦距离的直观值，你确认过返回的score范围和本地暴

这问题我也踩过坑，光换embedding作用有限，中文里“离职流程”和“考勤规则”字面差距太大，语义模型容易懵。你可以试试bge-large-zh-v1.5或者text2vec-large-chinese，但更关键的是把文档按“用户意图”重新分块，比如把HR常见问题整理成独立的问答对再检索。另外在query端加个轻量意图分类确实有用，或者干脆用bge-reranker做二次精排，比单纯提权重见效快

别死磕Prompt，上点后处理兜底吧，漏字段用规则补，长文本截断分块抽更稳。

说实话Prompt调优确实容易让人头秃，尤其结构化提取这种对稳定性要求高的活儿。我的经验是别在单一prompt上死磕，先跑个30条样本集，统计错误类型，再针对性改输出格式或加约束规则，比瞎调温度靠谱。至于微调，如果数据量能攒到几百条标注，效果确实甩prompt几条街，但前期投入得算清楚。小工具的话，试试用函数调用或JSON mode强制输出结构，比纯靠prompt稳多了。

Qdrant上手快但内存吃紧，Milvus功能全可运维起来真折腾，看团队规模选吧。 小项目果断Qdrant，省心；数据量大要上分布式的再考虑Milvus，不然光调参就够喝一壶。

大概率不是索引的问题，你这情况更像是没做分块或者块太大，语义串了。试试先按256-512字切好再入库，检索前记得用同款embedding处理query。

我之前也遇到过类似现象，感觉“请”更像是在给模型设定一种对话基调，它不光是礼貌词，可能间接让模型更专注于“角色”本身，而不是单纯的字面指令。系统提示里“你是一个专业客服”和“请以专业客服身份回答”，后者确实更带点执行指令的意味，或许跟模型在训练时对祈使句的响应模式有关。不过我也没跑过严格对比实验，感觉这背后可能跟token长度没关系，更像是模型对“身份+动作”的关联记忆更敏感。说到底，玄学还是科学

试试8bit量化或者AWQ，能保住大部分推理能力，显存卡在12G左右刚好能跑。

七八个确实有点狠了，我最多同时挂四个就觉得交互变肉，后来发现主要卡在工具描述和schema的token消耗上，每次请求都得重新解析一遍。按需加载是个好思路，或者把不常用的MCP拆到单独项目里，用的时候再临时挂上。另外也建议检查下是不是某个服务器本身响应就慢，比如数据库查询没做索引，拖累了整体。

八成是MCP没把`MASTER_ADDR`这些环境变量透传进容器，手动设一下或者直接看下官方镜像里的启动脚本。