一线低代码手记

我之前也踩过这个坑，Qwen2.5-72B已经算听话的了，但工具结果一长它就容易“自由发挥”。我的做法是在工具返回后加一层轻量校验，比如把JSON里的关键字段抽出来做正则匹配，生成回复前先检查有没有出现工具里没有的数字或天气词。另外模板拼接确实有用，但别只塞system，最好在user轮里用固定格式再强调一遍“仅根据以下数据回答”。如果还偶发，可以考虑让模型先输出一个引用片段，再基于片段生成最终回

提示词确实有用，但得配合模型和参数一起调，光堆词真跟抽卡差不多。

我也遇到过，感觉不完全是错觉。Prompt里约束多了，模型注意力会被格式和规则分走一部分，反而对检索内容没那么“上心”，特别是要求“不知道就说不知道”时，它更容易直接摆烂或者硬编。我后来是把引用格式放到后处理做，生成阶段只留一句“优先依据上下文回答”，召回和回答质量都稳了不少。你可以试试把约束拆开，别全塞在生成Prompt里。

我一般会在prompt里加一句“只根据检索内容回答，不要自己发挥”，然后再加个输出格式的约束，比如“先给结论再列依据”。之前也遇到过答案啰嗦的问题，后来把温度调到0.2左右就好多了。你要不试试在片段前面标一下来源文档名，模型有时候会参考这个来组织答案。

能跑不代表能维护，建议现在就逼自己把关键模块手写一遍，不然下次改需求准翻车。

我一般会把需求拆成两三轮来问，先让AI把文件读写和目录遍历的架子搭好，跑通了再加重命名和合并逻辑。提示词里把Python版本、用pandas还是csv模块、文件路径长什么样都交代清楚，它臆想的空间就小很多。另外别指望一次就给完美代码，报错信息直接贴回去让它改，比重新描述需求快多了。

我觉得这俩根本不是一个层面的东西，Prompt是在教模型怎么用已经拿到手的材料，检索参数是在决定材料本身对不对。你那个“先总结再综合”的改法有效，很可能是模型之前拿到片段就直接拼答案，没做信息整合，这跟检索质量好坏不冲突。但要是chunk切得太碎或者阈值把关键段落筛掉了，那提示词再巧也救不回来，模型总不能凭空编。我一般先拿一批问题看召回率，召回没问题再回头抠Prompt，不然容易在错的方向上反复调

先把检索结果单独拉出来看，看答案到底在不在召回里，不然改prompt就是碰运气。

同感，我用了半年Copilot后也有类似体验，但后来想通了——这就像用计算器，你不需要手算平方根，但得知道什么时候该开根号。我现在的做法是每周抽两小时不看AI写点小工具，纯粹保持手感。至于混合代码的坑，最烦的是AI生成的变量命名和逻辑风格跟老代码不统一，后面改的人容易懵，建议给AI生成的代码加个注释标记一下来源。

工具描述最好放进system prompt里，别省这点token，不然模型根本不知道有哪些工具可用。我试过单独做工具选择任务，效果一般，后来改成完整轨迹样本——用户query、模型决策、function call参数、工具返回、最终回复全串起来，参数格式错误明显少了。模糊指令那块可以专门造一批hard negative，比如两个工具描述很像的情况，让模型学会区分。数据量不用太大，几百条高质量的就够

图片去重这个场景还真能用，但别指望它比pHash快，向量检索胜在能捕捉语义相似度，比如两张不同角度但同一只猫的头像，pHash就挂了。我之前拿CLIP抽特征灌进Milvus做商品图去重，召回率确实高，但延迟比pHash高一个量级，得看业务能不能忍。日志异常那块也有人搞过，本质就是用embedding做聚类，不过数据量不大的话Faiss甚至sklearn就够，不一定非上向量DB。

说实话Prompt占的权重比你想象的大多了，尤其是本地部署的模型，底座能力就那样，全靠提示词把它的潜力挖出来。我自己的经验是别急着背模板，先把你想要的结构拆成“背景+具体要求+示例”三块，比如让它先复述问题再分点作答，效果立竿见影。另外可以多翻翻模型卡里的建议，很多开源项目都给了官方推荐的prompt格式，比你自己瞎试靠谱得多。你与其纠结“通用模板”，不如针对你这几个常用场景各存一套固定写法，慢慢

3000+文档对向量索引来说是个分水岭，你这大概率不是chunk或者embedding的问题，而是召回链路里少了rerank这一层。全量检索时向量相似度会被无关片段干扰，相关片段排到十几名开外很正常，建议先看下召回的top20里有没有正确答案，有的话直接加个cross-encoder做精排，效果立竿见影。至于并发飙到8秒，查下是不是用了暴力检索没走HNSW或者IVF索引，线上环境必须建索引，不然3

试试按语义边界切，比如句号或换行处，overlap设个50-100字符，代码和论文确实得分开调。

先查查是不是表格被切碎了，长表格建议单独走OCR或者结构化提取。 试试把embedding换成bge-m3，对中文长尾query友好很多。

同感，工具调用格式这块儿真的比模型智商还让人头大。我试过把数据库返回的JSON先转成纯文本描述再塞给模型，让它别直接碰原始数据，出错率能降不少。另外别迷信LangChain的默认prompt，很多坑都是它那套模板引出来的，自己写个极简的few-shot例子反而稳。

说实话这个量级真不用太纠结，10万chunk用384维Milvus检索也就几十毫秒的事，768维顶多多花个十几毫秒，体验上几乎没差别。准确率倒是跟你文档切分质量和query改写关系更大，bge-small跑你这个场景大概率够用。不过要提醒你，换模型确实得重新embedding一遍，Milvus那边倒不用重建索引，但数据得删了重灌，所以前期最好把原始chunk和元数据单独存一份，不然到时候哭都来不及

做过类似的项目，给历史对话按时间衰减权重，检索时只挑跟当前问题最相关的几条记录，比单纯截断窗口靠谱。

Qdrant试过没？Docker单机跑也不难，检索速度比Chroma稳，迁移成本也低。

说实话你这个全塞进system prompt的做法我也踩过坑，token一上去模型就跟喝完断片儿似的，前面的任务要求全变背景板了。我觉得短期和长期真得分开管，短期用滑动窗口加个简单的状态机就够，比如当前对话轮次、正在跑的步骤、刚改过的偏好，这些结构化存一下，每轮动态拼进prompt里，比纯文本历史靠谱得多。长期记忆倒是适合走向量检索，但别光把用户画像当静态文本存，最好拆成“事实型偏好”和“行为模式