持续研究知识管理实践笔记

在prompt里直接贴两行现有代码的风格样例，比写十句“别加戏”都管用。

我们之前也是ES扛着，后来几百万文档加跨语言查询，确实感觉召回差点意思，HNSW调参调到头秃。换Qdrant之后召回和延迟都稳了不少，bge-m3这种多语言场景还是交给专业向量库吧。不过也得看团队运维成本，Milvus组件多，Qdrant相对轻一些。你们要是ES里还有其他检索需求，混着用也不是不行，就是得拆开。

数据处理确实容易翻车，AI对列名和路径这类“约定”特别爱自作主张。我的经验是别让它直接写完整脚本，先让它输出一个只读表头和打印列名的片段，确认对了再往下加逻辑。另外Cursor里可以把报错直接贴回去让它改，比重新描述需求省事。这场景不是AI不擅长，是它缺上下文还特爱脑补，你得把“猜”的空间堵死。

我最近也在折腾MCP这块，说说踩坑感受。你要是主攻服务端部署和推理优化，PyTorch其实更稳，生态成熟、调试工具链完善，出问题基本都能搜到现成答案，JAX那套jit编译报错有时候真让人抓狂。不过JAX在MCP上下文切换那块确实有优势，它的纯函数特性让状态管理更可控，尤其是需要频繁切换推理上下文的时候，PyTorch的动态图和全局状态反而容易埋雷。我现在用的折中方案是主体逻辑走PyTorch，只在

说实话现在入坑大模型基本无脑选PyTorch，HuggingFace那一套生态全是基于它，微调LLaMA、Qwen这些开源模型几乎清一色PyTorch代码。TF不是不能用，但LLM这块社区资源和教程明显少一截，踩坑了都不好搜答案。部署端TF Serving确实还有存量，不过现在vLLM、TGI这些推理框架也都是PyTorch系为主。建议先把PyTorch吃透，TF等真遇到公司项目再补也来得及，别一

500条确实偏少，而且loss卡在2.3振荡、验证集还在“背书”，大概率不是单纯数据量的问题，更像是数据同质化+过拟合。你每条300-500字，如果是同一套模板或同一批文档切出来的，模型很容易学到“复读”而不是指令跟随。建议先别急着加数据，把500条按任务类型或模板拆开看看分布，再混一点通用指令数据进去。另外LoRA的target_modules和rank也会影响，rank太低在7B上确实容易欠拟

我之前也踩过这个坑，调chunk size和top k其实治标不治本，问题大概率出在embedding对“流程类”文档的语义区分度不够。你可以试试把文档按标题层级做父子分块，检索时先命中父块再返回子块，或者加个rerank模型（比如bge-reranker）过一遍候选，效果比单纯堆top k明显。另外“项目部署流程”这种query太笼统，让用户补一句具体环境或组件，召回会准很多。

多步工具调用出错，很多时候不是LangChain编排太重，而是中间结果没有做结构化校验。我建议在每个工具返回后加一层schema验证，参数错了直接重试，别让它带着脏数据往下走。另外可以试试把多步推理拆成显式的状态机，比ReAct那种自由发挥稳定不少。prompt工程能救一部分，但别指望它兜住所有幻觉。

苹果种植那个例子太真实了，语义相似度确实容易在这种词面重叠但意图完全不同的场景翻车。你项目赶时间的话，最省事的做法其实不是pure prompt，而是在检索后面加一层轻量重排，比如用bge-reranker或者cohere的rerank接口，把top-5先重新打分再取前2-3，代码量很小，LangChain里ContextualCompressionRetriever直接能接。如果连这个都不想加，

500万这个量级其实挺尴尬的，faiss扛得住但运维确实难受，milvus又有点杀鸡用牛刀的感觉。我们之前用pgvector跑过300万左右的向量，HNSW索引下延迟还行，但内存吃得不轻，得盯着shared_buffers调优。如果你们团队本来就在postgres生态里，我建议先拿pgvector压测一下，真到瓶颈再迁也来得及。milvus分布式部署那套东西没专人维护的话，后面踩坑概率不小。

我一般在工具外面包一层tenacity，超时和网络错误自动重试，简单又省心。

我用的也是Cursor+MCP这套，确实补全激进得离谱，尤其写到一半停下来想逻辑的时候，它直接帮我“决定”了。你可以在Cursor设置里把Tab补全的触发延迟调高一点，再把“自动跳转”那个选项关掉，会好很多。MCP本身好像没有意图权重这种参数，更多还是靠客户端这边控制。不过说实话关掉又舍不得，我现在是写核心逻辑时手动关，写模板代码再开。

这个感受太真实了，开源模型之间的prompt迁移成本确实被严重低估了。Qwen和Llama虽然都是decoder-only架构，但预训练数据的中英文配比、指令微调时的模板格式差异很大，导致同一个few-shot模板在两边的“激活模式”完全不同。我之前做抽取任务时也踩过类似的坑，Llama系列对分隔符特别敏感，你试试把示例之间的分隔从换行改成###或者<|sep|>这种显式标记，漏字段的情况会少很多

这个坑我踩过，而且踩得挺深的。之前做金融领域的问答微调，也是7B模型，一开始训练数据里Prompt平均长度拉到600多token，结果模型学会了“先寒暄再分析最后总结”的套路，测试时问个简单问题它都能给你扯出三段式小作文。后来我做了个对比实验，把同样的答案配上长短两种Prompt分别训练，发现长Prompt那版确实更容易过拟合到“啰嗦模式”，因为模型会把Prompt长度当成一种风格信号来学。但如果

这个问题我太有同感了，Cursor的Agent模式确实容易“手痒”，尤其是你选中的代码块跟周围耦合比较紧的时候，它就会自作主张地帮你“顺带优化”。我后来发现一个比较管用的做法，是别用默认的Agent或者Composer模式去改局部，而是切到Inline Edit（Cmd+K那种），选中后直接在里面写指令，它基本就只碰你框住的那几行。另外在Prompt里光说“只改选中”确实不太稳，我会加一句“不要改

500万这个量级其实单机跑的话，Qdrant确实更舒服一些，我去年一个项目差不多也是这个规模，用的Qdrant单机docker部署，内存占用比Milvus小不少，运维也简单。但你要是数据量再涨，或者需要多租户、复杂过滤这些，Milvus的架构优势就出来了，它那套存算分离不是白设计的。GPU这块得看你具体要什么，Milvus有GPU版的CAGRA索引，NVIDIA那边合作挺深，Qdrant目前主要还

我也有类似的感觉，不过后来给自己定了个规矩：AI生成的核心逻辑，哪怕跑通了也得自己手敲一遍再删掉重写，不然真的会虚。另外报错日志我现在强制自己先看五分钟，实在没头绪再问AI，这样至少不会把排查能力也外包出去。设计模式那块我建议直接让AI解释它写的每一层装饰器在干嘛，听不懂就让它画调用栈，比事后被问懵强。手感这东西说白了就是肌肉记忆，你少练它就真没了。

我之前也踩过这个坑，微调完单测相似度确实涨了，但整体召回反而乱掉。大概率是训练数据里正负样本构造有问题，负样本太简单或者太偏，模型学到的不是你要的语义区分。另外CSE默认的in-batch负采样在领域数据少的时候容易过拟合，建议先把微调模型和原模型做一下检索结果对比，看是哪些query变差了。如果不是特别缺数据，其实加个rerank模型可能比硬调embedding更划算。

top_k设5其实不算多，问题大概率出在chunk切分上——如果块本身语义就不完整或者混了好几个主题，向量相似度再准也救不回来。我自己的经验是先把chunk按语义边界切（比如按段落或标题层级），而不是固定token数硬切，这样每块的信息密度会高很多。reranker我试过bge-reranker和Cohere的，bge那个开源的效果对中文挺友好，成本也低，建议top_k先拉到10-15再用rera

十几秒一步确实太慢了，4060Ti 16G跑Qwen2.5-7B Q4不该是这个速度。你先看看是不是每轮都把完整历史塞进prompt了，ReAct多步下来上下文涨得飞快，prefill时间会爆炸。另外Ollama默认并发和batch设置不太适合Agent这种频繁短请求，换vLLM或者llama.cpp开continuous batching能明显改善。70B量化版在16G上基本别想，显存都不够，就