长期关注品牌增长记

角色设定确实容易让模型“戏太多”，我一般只留一句身份，关键约束全塞用户输入里重复一遍，反而稳。

试试把“只基于上下文”改成“找不到就说不知道”，再让检索片段带上来源标记，模型会老实很多。

固定500字符切确实容易把语义切碎，尤其是合同这种结构化文档。我一般会先按标题层级切，再在段落内做二次切分，效果会好不少。另外你可以试试加个rerank模型，先粗召回再精排，能压掉不少不相关片段。

几万到百万这个区间其实Qdrant挺合适的，单机docker就能跑，后面要扩也能上集群，迁移成本比Milvus小不少。Milvus功能确实全但那个部署复杂度，小团队维护起来真的累，etcd、minio一堆东西。Chroma做demo无敌，但生产我是不太敢用，之前遇到过数据量上来之后查询明显变慢。其实还可以看看pgvector，如果你们本来就有Postgres，几百万级完全够用，省得再维护一套。

这种顺序乱跑的情况我也遇到过，本质上是让LLM自己规划步骤太不可控了。我后来改成用LangGraph把流程拆成显式节点，订单查完再走物流分支，工具调用就老实多了。你要是坚持用ReAct那套，可以试试在prompt里把前置条件写死，比如“查物流前必须已有订单号”，但说实话不如直接上状态机稳。

我也遇到过这个坑，后来发现让模型“考虑边界”基本没用，它压根不知道你的数据长啥样。我的做法是prompt里直接列几个具体的边界例子，比如“输入可能是空list、含None、或数字超过1e10”，比泛泛地说“考虑所有情况”管用很多。另外我会让它先写函数签名和docstring，再生成实现，这样它自己会先把异常情况想一遍。不过说实话，最后该review还是得review，AI写的防御代码经常是假防御，

这个坑我踩过，大概率是Agent框架的多轮拼接把微调时的格式分布带偏了。LoRA学到的JSON模式其实很依赖prompt结构一致，工具调用一插进来，历史消息和system prompt一变，模型就懵了。建议先固定住system prompt和输出模板，把工具返回也包成统一格式再喂回去，看看单轮和多轮是不是同一套上下文。另外3000条数据里如果混了带工具调用的样本，最好单独标出来做对比测试。

我之前也踩过这个坑，rerank本质是在候选集里挑更相关的，候选全是错的它也没法凭空变出来。你这个CMS简称的问题，最直接还是query改写加同义词词典，或者上混合检索让BM25兜一下。微调reranker收益不大，不如先把召回这层修好。

IVF_FLAT想上95%太难了，1.2亿数据直接换HNSW吧，nprobe再高也救不了量化损失。

我一般会在项目根目录放一个 .cursorrules 文件，把技术栈、组件库、目录约定都写进去，这样每次对话它都会自动带上这些上下文，比每次手动贴 package.json 省事多了。你说的 Ant Design Table 那个问题，其实可以在 Prompt 里直接点名“使用 src/components/BaseTable”，并且把那个组件的 props 接口简单描述一下，它就不太会乱引第三方

多步任务断掉太常见了，LangChain的Agent确实容易在中间状态丢失上下文。你试试把每一步的中间结果显式存到变量或文件里，别指望它自己记住，DataFrame这种大对象尤其要落盘。另外拆分任务时用Plan-and-Execute模式比ReAct稳不少，或者直接换LangGraph编排状态机。Prompt再细也救不了架构问题，得从流程控制上解决。

子图覆盖父图状态这个坑我也踩过，后来发现是节点里直接改了共享的dict，LangGraph的状态是不可变的，得返回新值才行。你那个list重复的问题，Reducer里用`operator.add`或者自己写去重逻辑都行，但关键是要确认每个节点返回的是增量而不是全量。Checkpoint机制主要是做持久化和恢复的，解决不了你现在的状态污染，建议先把图拆简单点，子Agent别嵌套太深。

loss降不代表生成对，LoRA最容易在数据格式和chat template上翻车。你确认下训练时是不是套了Llama3官方的special token和对话模板，没对齐的话推理阶段模型根本不知道啥时候该停。重复嗯嗯嗯和乱码一般是指令格式没学好，不一定是超参问题。可以先试试把lr降到1e-4，多检查几条训练样本decode出来长啥样，比调rank管用。

大概率是模型没吃透上下文，试试把top-5缩到top-2，噪声少反而更准。

我之前也踩过这个坑，MCP的stdio模式对JSON序列化特别严格，ndarray不光不能直接塞，连np.float32这种标量都会炸。建议你在tool返回前统一做一层转换，比如tolist()再包成{"vectors": [...], "payloads": [...]}这种结构。官方文档确实没细说，但本质上MCP就是纯JSON-RPC，任何numpy类型都得先转成原生Python类型。另外注意

大模型上TensorRT提速确实明显，小模型感知不强很正常，但生产环境多并发时原生PyTorch容易显存爆炸。

几万到几十万这个量级，pgvector其实没那么不堪，尤其是你已经有metadata过滤需求。pgvector配合B-tree索引做user_id和时间的预过滤，再走HNSW或IVFFlat，几十万条1536维一般还能扛，真正开始难受通常是几百万向量往上，或者QPS要求高、并发一上来内存吃紧的时候。Milvus功能确实全，但单机部署虽然能用docker-compose跑起来，调参、监控、升级这些隐

先别急着换模型，你chunk里“退款”和“退货”混一起，八成是切分把上下文切断了，加个重排试试。

后端光靠贴需求不够，得把接口契约和已有代码喂给它，不然它老自己造轮子。

试试限制并发数加动态批处理，Agent的上下文别留太长，KV cache用paged attention能省不少。