稳步前行低代码修炼册

这个思路不错，收藏了。

我之前也遇到过类似问题，后来换了方案。

有没有更详细的教程推荐？

我之前也踩过这个坑，全量历史塞进去确实会稀释注意力，尤其是中间那些工具调用的原始返回，特别占token还容易让模型跑偏。我后来改成用状态字典的思路，每一步只把关键实体提取出来存着，比如用户ID、订单号这种，后面步骤直接引用这个精简状态，而不是翻整个对话记录。向量库我也试过，但对这种结构化任务其实有点杀鸡用牛刀，检索出来的东西不一定准，还多一次调用延迟。另外有个技巧是在系统提示里明确告诉模型当前处于

我现在的做法是工具只返回top-k的摘要加doc_id，让模型判断要不要再拉全文，这样大部分请求根本不会把窗口撑爆。真要返回原文的话，可以在工具层做个重排加压缩，比如用小的rerank模型筛一遍，再按句子粒度截断，比直接切字符强很多。MCP本身确实不管这些，得自己兜住。另外Claude Desktop那边系统提示词也占不少，能精简就精简。

这个问题的核心其实不是截断，而是查询改写没做对。我一般会让LLM先把“他们的毛利率呢”改写成独立query，比如“A公司毛利率”，再去检索，历史就不用全塞进去了。另外每轮检索完可以做个轻量摘要，把关键实体和结论压缩成一两句话存到state里，下一轮只带这个摘要加当前query。这样既保住了指代，context也不会炸。

我一般会把状态流转写成类似伪代码的注释块塞进prompt里，比如“选部门 → 清空日期 → 重置页码”，这样比纯文字描述稳很多。禁用useEffect做联动这个思路我试过，但得留个口子，不然它连必要的副作用都不写了。其实更管用的是直接给几个“反例”告诉它别这么干，比抽象禁止有效。

让大模型自己判断危险输入不太靠谱，模型对注入类攻击的识别其实挺飘的，同一个payload换个写法就绕过去了。我一般是把参数校验和模板渲染拆开，server端先做白名单过滤，用户名只允许字母数字下划线，项目名走正则匹配，过不了的直接拒绝而不是清洗。MCP协议确实没管这块，但你可以把它当成普通web输入来对待，该有的校验层一个都别省。模板拼接改成占位符替换，别用字符串直接拼，这样至少不会把危险内容混进

我之前也踩过这个坑，256的chunk对技术文档确实太碎了，像数据库连接超时这种问题，原因往往分散在配置、代码示例和注意事项好几个段落里，切太细反而把完整逻辑打散了。你调大到512召回上去了但上下文变杂，我觉得问题可能不完全在chunk大小，而是单一粒度本身就不够用。可以试试小chunk做检索、大chunk或者整段父文档喂给LLM的思路，llama-index里有sentence window和p

这个现象挺典型的，2万条全是法律垂直数据，模型基本被你拽到法律分布里去了，日常能力不掉才怪。降学习率只能缓解，治不了根，因为问题出在数据分布上而不是优化器。我自己做过类似的医疗LoRA，后来掺了大概15%的通用指令数据进去，遗忘立马好转很多，你可以先从10%到20%这个比例试。另外3个epoch对LoRA来说其实偏多了，1到2个epoch往往就够，跑太多容易把小模型往窄路上带。AdamW和Adam

固定500字切分确实容易把语义割裂，尤其技术手册里表格和代码块很吃上下文。我建议你先试试按文档标题或段落结构做递归切分，配合自定义分隔符，块大小可以放宽到800左右，超长部分再二次切分。另外检索端也别只看top-k，可以试试混合检索加rerank，bge-large做embedding但相关性排序不一定最优，用bm25粗筛再精排往往能救回来不少。

研究清楚TF1.x的底层逻辑，再看PyTorch会通透很多，毕竟核心概念就那些。

这个问题我太有同感了，代码RAG的召回逻辑跟自然语言完全两码事，光靠embedding相似度根本分不清业务主线和工具函数。我觉得你可以试试在chunk里拼上文件路径和类名做前缀，很多情况下这比rerank管用。另外代码专用模型像codebert或者starencoder对结构感知确实强不少，bge-m3泛化好但在这个场景有点吃亏。你那个cross-encoder是不是没针对代码pair微调过？直接

500条测试集其实不算大，bge-large-zh对长文档的切块方式很敏感，你试试把chunk_size调到300-400，overlap设50左右，召回率可能直接涨几个点。另外Pinecone的metric是不是用的cosine？有时候换dot product效果差挺多。还有，你手动标注的相关段落是整段还是句子？如果标得偏细，top-20算召回本身就不太公平，网上那些85%+的很多用的是宽松匹配

建议先试下把切块调小到300字左右，另外bge-small-zh对中文长尾词确实弱，换个bge-large或text2vec-large可能立竿见影。

几百万条这个量级其实不用太纠结，Milvus的milvus-lite或者单机版跑起来完全够用，K8s那套后面数据涨了再上也不迟。Pinecone胜在省心，但中文分词和embedding的适配性你得自己测，召回率未必比开源方案好。我们之前从Pinecone迁到Qdrant，延迟和成本都改善不少，社区版够用。你最好拿真实数据跑个benchmark，别光看文档。

说到这个我太有同感了，之前做摘要任务时试了十几种模板，最后发现把任务拆成“先提取要点再组织语言”两步走，比堆砌什么角色和格式描述都管用。感觉思维链这东西得看任务复杂度，简单问题硬套反而容易让模型放飞自我。要不你试试把“步骤”写得更像给新员工的任务清单？另外不同模型对同样措辞的敏感度确实差挺多，我一般会先拿三个典型case快速过一遍，再挑表现最稳的那个方向继续调。

这问题太真实了，我也被坑过。后来发现光在prompt里强调规则没用，得把eslint配置直接贴进对话里，或者干脆在项目里建个`.cursorrules`文件，把react-hooks/rules-of-hooks的报错示例写进去，它下次生成前会参考。另外你可以试试让它先写纯逻辑函数，再单独写JSX部分，分两步走成功率会高很多。 --- 我一般会在提示词里加一句“先列出所有hooks，再写ret

这问题太典型了，LoRA rank 64确实偏大，7B模型学1.5万条很容易就把“委婉”这种高频风格给固化了，试试把rank降到16甚至8，同时只训练最后两层。另外检查下你的工单数据里，是不是有大量“建议人工”这类话术，哪怕不是兜底，客服日常回复也常带这种语气，模型会把这当成一种整体风格来模仿。我上次处理类似问题，最后是把所有“不确定”类表达在数据里替换成“无法回答”后，再加了20%的原始模型回答

说实话你这个情况我太理解了，调一周真的会崩溃。我感觉你现在的问题核心不在reranker，而是切片粒度跟文档结构完全脱节了，固定500字硬切PDF很容易把逻辑上独立的章节拆得稀碎，重复覆盖又让向量空间里同一段话占了太多位置，召回的多样性自然就差了。我建议你先别急着改query，试着用文档自带的标题层级或者段落边界做切分，哪怕每个切片长一点（800-1000字）都行，先保证每个切片是个完整语义单元，