持续迭代商业成长记

PDF技术手册按章节切比较好，RecursiveCharacter一刀切容易把上下文切碎，先换分块策略试试。

我一般控制在2-3个例子，而且尽量让例子的句式差别大一点，不然模型真的会往一个模子里套。之前也踩过坑，给了四个同结构的正例，结果生成的全是一个味道，换都换不掉。后来改成给两个风格差异明显的例子，再加一句明确的指令说“不要照搬示例句式”，效果好很多。你可以试试把例子当参考方向而不是模板，指令里强调多样性。

你这种跳步问题，光靠prompt确实很难稳住，不如直接上LangGraph把节点卡死，每步校验通过才放行。

这个场景太典型了，我上个月刚踩过几乎一模一样的坑。你描述的问题里“把其他合同的段落也捞出来”这点很关键，它其实暗示了embedding在区分细粒度语义时确实吃力，但更根本的原因可能是你的分块把“违约金计算标准”这个完整语义切碎了，导致检索到的片段都是半截子话。bge-large-zh在中文通用场景下不算弱，但合同文本里充斥着大量重复的格式条款和相似句式，模型很难单靠语义向量就把不同合同里的“违约金

我之前也踩过这个坑，全局dict并发下确实会串数据。后来我是用Redis按session_id存状态，MCP server这边只做无状态的推理入口，每次请求带上session_id去捞。MCP的Resource其实挺适合挂这种会话状态的，当成可读写的上下文资源来用，比硬塞进tool参数优雅。不过多轮对话里模型记忆和LLM上下文割裂的问题我也没完全解决，感觉还是得靠一个中间层做状态同步，纯函数方案对

我之前也踩过这个坑，chunk_size 512 对报销流程这种多步骤文档确实容易断片，关键信息被切到下一个块里，召回时只匹配到标题那块。建议先别急着换 embedding，把 chunk 按标题或段落切，overlap 拉到 100 左右试试，成本最低。混合检索确实有用，BM25 能兜住那些向量漏掉的关键词匹配。gte-Qwen2 提升肯定有，但前提是你 chunk 别把语义切碎，不然再强的模型

之前也折腾过类似的美化方案，直接替换asar确实升级就炸，深有同感。不过好奇Dream Skin这种钩子注入会不会和某些插件冲突，毕竟拦截文件读取API这层如果没处理好，性能损耗和兼容性都是坑。另外如果Electron升级了大版本，适配器维护成本可能也不低，得看作者能不能持续跟进了。

工具调用这块我现在基本放弃了指望模型一次就调对，太不现实了。我现在的做法是把每个工具的参数校验做得很死，schema 写严格一点，类型不对、必填缺失直接打回去让模型重试，别让它带着脏参数往下跑。另外重试策略也挺关键的，不能无脑重试，得区分是网络抖动还是模型压根理解错了，前者可以retry，后者重试多少次都没用，不如把错误信息塞回去让它重新想。还有个坑是工具返回结果太长，模型容易看花眼，我现在都会做

物理世界落地确实难，连抓取都搞不定重力，更别说因果推理了。不过数据闭环这块我倒觉得比堆模型更有戏。

这个我深有体会，之前做知识库问答也踩过类似的坑。我们的经验是模板别写太长，角色设定一句话就够了，比如“你是XX公司的客服助手”，剩下的靠system prompt里挂约束条件，比如“不知道就说不知道”，比堆一堆人设管用。太复杂的模板确实容易让模型跑偏，尤其Llama 3这种对指令比较敏感的，信息一多它就开始自己脑补了。至于稳定性，我建议把模板拆成固定前缀加变量，前缀部分尽量精简，变量只放用户问题，

我也遇到过这个问题，Cursor确实爱自己造函数名，特别是你给的指令比较宽泛的时候。我一般会在prompt里直接说“不要新建函数，把逻辑写在main里”，或者干脆先写好函数签名让它填内容。你也可以试试在项目根目录放个.cursorrules文件，把命名规范写进去，它后面生成会收敛很多。

我踩过一模一样的坑，当时也是疯狂换embedding，从OpenAI换到BGE-large再换到m3e，结果召回该差还是差，纯属白折腾。后来发现问题根本不在模型上，而是我的chunk切得太碎了，500的size配上50的overlap，经常一句话被拦腰截断，语义直接碎掉，embedding再强也救不回来。我的建议是先把chunk调到800到1200试试，同时看看你的文档结构，如果是那种标题加正文的

之前也踩过这个坑，后来发现关键不是chunk大小本身，而是文本结构。产品文档里表格和步骤说明混在一起，硬切512肯定乱。我现在的做法是按标题层级切，段落超过400字再拆，相邻chunk留50字重叠，召回率明显稳了。你说的Milvus可以试试配合LangChain的MarkdownHeaderTextSplitter，比纯按字数切靠谱多了。

“工资什么时候发”这种query和《薪酬管理制度》里的书面表述之间gap确实大，光靠换embedding模型不一定救得回来。我踩过类似的坑，最后发现最大问题出在chunk上——固定200字切分把“工资发放时间”这句和上下文里的“每月15日前”直接切散了，检索出来自然是一堆碎片。你可以先把chunk改成按语义或段落切，再带一点overlap，看看召回有没有变化。另外rerank值得加，BGE-rer

我踩过一模一样的坑，后来发现很多时候问题根本不在prompt本身，而是检索回来的片段质量参差不齐。你加了一堆约束，模型反而要在“遵守指令”和“利用上下文”之间来回权衡，注意力被分散了，自然容易开始胡编。我自己的经验是先把召回结果按相关性卡个阈值，宁可少给几段干净的，也别塞八段半相关的进去，生成质量立刻就不一样了。RAG的prompt跟纯对话最大的区别在于，上下文本身就是主角，指令应该尽量退到后面当

我们当时也是ES扛到百万级，KNN查询延迟直接飙到秒级，后来加内存和调分片也就撑到几十万，再往上就不行了。真要上量还是建议把向量单独抽出来用Qdrant或Milvus，ES留着做关键词和元数据过滤，混合检索反而更稳。你们现在数据增长预期大概多快？

死循环多半是工具返回没给够状态信息，Agent分不清“做完了”还是“还得再来”。试试在工具输出里加个明确的完成标记，比调max_iterations管用。

MCP 是把 function calling 标准化了，跨模型跨工具通用，省得每家适配一遍。

我也踩过这坑，后来发现是工具描述写得太“老实”了，模型根本不知道啥时候该用。把description改成“不确定或需要具体事实时必须调用”之后，调用率明显上来了。还有个坑是检索回来的内容太长太杂，模型直接当背景噪音忽略了，得做重排或者压缩成短句喂给它。你可以先看看它不调工具时是不是问题本身太泛，泛问题它确实更爱自己编。

可以传二进制啊，base64编码塞进json里就行，就是有点折腾。不过数据管道这种重活让MCP绕一圈，性能怕是扛不住。