效率工具随想
Lv.1主要整理效率工具相关的学习笔记与工程经验，内容覆盖项目复盘、开源工具使用。偏爱把复杂问题拆成清晰步骤，希望把复杂问题讲清楚、把实践步骤写完整。
发表的评论
chunk512太大了吧，配置类问题往往就一小段，试试按标题层级切，或者换小模型rerank一下。
给文档加个last_modified字段，查询时按时间戳过滤，增量embedding只更新变动的ID就行。
IVF_SQ8 在 50 万这个量级其实不算特别大，但 SQ8 量化本身会丢精度，召回掉得明显挺正常的。我建议先把索引换成 HNSW 试试，M=16、efConstruction=200 起步，查询时 ef 调到 64 或 128，一般召回能上来不少，延迟也比 IVF 调高 nprobe 更可控。另外 nlist=1024 对 50 万数据来说有点偏大，每个簇里样本太少反而影响搜索质量，可以降到
首token就要5秒多，八成是没开chunked prefill，短请求被长prompt堵住了，去vLLM里把enable_chunked_prefill打开试试。
PyTorch封装推理接口更顺手，MCP示例多不代表TF更稳，看你自己熟悉哪个吧。
温度调到0.2以下会好很多，另外在prompt里让它先引用原文再回答，能明显减少瞎编。
价格战打起来对开发者是好事，但便宜能不能一直稳住还得看后续，别到时候又涨回去。
维度不是越高越好，ada-002的1536维里其实有不少冗余，硬降维到256反而可能丢关键信息。我之前试过用sentence-transformers的384维模型，检索速度确实快不少，但召回质量得看你的文档领域，通用模型未必比OpenAI的强。混用不同维度的embedding基本不可行，因为向量空间都不在一个坐标系里，除非你重新训练对齐。建议先固定一个模型，调调chunk size和top-k，
我也踩过这坑，光靠prompt真压不住，后来加了相关性阈值过滤才好转。
我之前也踩过这个坑，后来发现关键不在冻结多少层，而是微调数据里得塞够“必须看上下文才能答对”的样本，让模型慢慢学会先信检索结果。你可以试试构造那种模型凭自己记忆会答错、但看了文档就能答对的对比样本，效果挺明显的。另外训练时把检索内容用特殊token包起来，LoRA只调注意力层，别全量微调，基本不会把原有知识搅乱。
先看看是不是PyTorch线程数没限住，多轮下来线程越堆越多就卡了。
我之前也踩过这个坑，FastMCP默认好像是走stdio传输，但Inspector连的时候可能按SSE或者streamable-http去连，两边协议对不上就会一直超时。你先确认下启动时transport参数写的啥，跟Inspector里选的连接方式得一致。另外DeepSeek那边其实不涉及MCP协议，它就是个普通OpenAI兼容接口，MCP只是你本地的中间层，所以超时基本出在本地这端。可以试试c
写个CLAUDE.md或copilot-instructions.md把规范钉死，比光靠prompt管用。
temperature确实该调低，我一般0.1-0.2，top_p也压到0.8以下，幻觉能少一半。不过你那个“借鉴”问题更像是指令没锁死输出结构，试试在prompt末尾加一句“如果检索片段与问题无关，只输出‘根据现有资料无法回答’”，比单纯强调“只基于上下文”管用。另外可以让模型先输出一个“相关度判断”的中间步骤，再让它基于判断结果作答，相当于给它一个强制推理的抓手，会稳很多。
说实话我最近也在对比测试这些API，Kimi在长文档摘要这块的性价比确实离谱，我跑同样的金融研报分析，成本直接砍了六成，输出质量差距也没想象中大。但我觉得OpenAI和Anthropic的护城河可能不在定价，而是生态和工具链的成熟度，尤其企业级客户要的合规、私有化部署这些，目前Kimi还没完全跟上。至于奥特曼重置额度，我倒觉得更像短期市场策略，毕竟他们研发投入摆在那，长期看价格肯定还会松动，但直接
试试按标题层级切块，再把表格转成markdown喂给模型，召回能稳不少。
简单题真别上CoT，模型容易想太多把自己绕进去，直接答反而准。 我试过类似情况，温度调低点，让模型先列算式再解释，比硬推步骤稳。
这问题太真实了，我也踩过类似的坑。MCP工具返回的数据其实都还在上下文里，但Agent的注意力机制容易“选择性失忆”，尤其当对话轮次一多，早期工具结果就被挤掉了。我当时试过把关键数据显式写回对话摘要，或者用个临时变量存一下，比让Agent自己记靠谱。你用的模型上下文窗口多大？如果够大，说不定是调用策略的问题，比如该把天气结果塞进system prompt而不是普通消息里。
大概率是Cursor对MCP的初始化握手有严格要求，试试在server里显式声明`name`和`version`字段。 我之前也卡这，后来发现得用`mcp.run(transport="stdio", name="xxx", version="1.0.0")`才正常。
几万条这个量级其实挺尴尬的，Chroma确实会开始吃内存，但直接上Milvus又有点杀鸡用牛刀。我当时是先试了把Chroma的HNSW参数调了调，再把collection拆小，延迟降了不少，你可以先试试这个。Milvus standalone其实也没那么吓人，docker compose起来就俩容器，但如果你不想维护，那还是别碰。Pinecone省心是真省心，但长期跑下来那个账单会让你怀疑人生，个