一线架构案例库

几十万切片Chroma够用，真上生产再迁Milvus也不迟，别提前焦虑。

这问题我也遇到过，感觉是agent类工具的通病，它拿到上下文后总想“顺手优化”一下。我后来在rules里加了句：只允许修改与报错直接相关的行，其他一律不准碰，再配合让它先列改动计划再动手，稍微好点。还有个偏方是先把无关文件从上下文里排除掉，减少它自由发挥的空间。实在不行就分两步，先让它只定位问题别改，确认后再单独下指令改那一处。

微调时没混工具调用格式的话，MCP塞回来的tool result模型确实会懵，建议把工具调用样本加进训练数据里。

顺序这事儿确实挺关键的，我踩过类似的坑。你描述的情况我怀疑不只是顺序问题，而是chunk之间的语义连贯性被切碎了，模型看到一堆孤立片段自然拼不出完整逻辑。我自己的经验是，单纯调顺序收益有限，上reranker才是质变的那一步，bge-reranker-v2-m3性价比挺高，本地跑也不贵。但重排只是把最相关的排前面，跨chunk的答案还是可能断，我后来加了一层相邻chunk扩展，就是命中某个chun

7B写复杂SQL确实容易翻车，换CodeQwen或14B会好很多，模板的话可以看看LangChain的SQL agent提示词。

80万这个量级其实两家都能扛，但你担心的点挺实在。我这边用Qdrant跑过千万级，带payload过滤的混合检索延迟稳定在几十毫秒，它那个filterable HNSW做得确实不错，不用太怕涨量。Milvus功能多是真多，但部署和运维成本摆在那，小团队容易把自己拖进去。至于K8s，除非你后面要上集群分片或者多租户，不然单机加好SSD就够撑到千万级了。

上线后飘多半是召回不稳，先把top5提到10看命中率，再查embedding对内部术语是不是真拉胯。

你这个情况我遇到过，LangChain的ConversationBufferMemory确实容易把不同轮次搞混。后来我换了个思路，每轮只把上一轮的“用户问题+Agent摘要结果”拼进prompt，工具调用日志单独存，不往context里塞。这样token省不少，追问时基本能接上。你要是场景不复杂，可以试试手动维护一个轻量历史列表，比向量库省事多了。

我目前是把 embedding 单独抽成一个轻量服务，MCP Server 只管切片和调接口，Qdrant 那边只存向量和 payload。这样换模型或者调维度不用动数据库，Qdrant 自带的插件我试过，灵活度还是差些。查询延迟主要看 embedding 那一步，本地小模型基本几十毫秒，真嫌慢就加个 query 缓存，重复问题直接命中。

我最近也碰到类似的情况，prompt里堆太多规则反而让模型顾此失彼，尤其是那种“信息不足要说明”的指令，模型有时候宁可说不知道也不去仔细看检索内容。后来我改成把约束放在系统提示里，用户那轮就简单说“根据资料回答”，效果好不少。感觉关键不是约束多少，而是别让指令和检索内容抢注意力，另外bge-m3本身对中文政策类文本召回还行，问题可能更多出在排序或者截断上。

按句子切确实容易把条件句和主句拆散，你这个“保修期一年”丢了“非人为损坏”的例子太典型了。我后来试过一种折中做法，是按语义段落切，但控制每块在200到400字之间，同时保留上一段最后一句和下一段第一句作为重叠上下文，效果比纯按段落或纯按句子都稳一些。FAQ这种短问答其实可以单独处理，把问题和答案绑成一个chunk，别硬拆。产品手册里那种带层级标题的，我会把标题路径拼到每个chunk开头，检索时命中

loss降这么低但准确率不动，八成是过拟合了，试试减到1个epoch或者调低lr？

我们这边也是Qdrant加MCP这套，最后选了一个大collection加payload过滤的路子。动态建collection听着干净，但MCP那边tool一多，schema和连接管理真的会炸，而且Qdrant本身过滤性能没那么拉胯，加个tenant_id字段建好索引就够用。唯一要注意的是别让单collection无限膨胀，定期按时间归档一下，不然HNSW内存扛不住。你们现在量级大概多少，几千还是

500条确实太少了，模型很难从这么点数据里学到稳定的回复模式，loss卡住很正常。你可以先试试把数据扩到两三千条，或者用数据增强把现有对话改写几遍。另外学习率2e-4对LoRA来说偏高了，换到1e-4甚至5e-5再跑跑看，rank也可以提到16或32。还有个小坑，检查下数据格式是不是严格按chat template拼的，格式不对loss也会降不下去。

10个并发延迟就十几秒，感觉瓶颈可能不在算力而在调度。A10跑7B用vLLM，可以先把gpu_memory_utilization调到0.9左右，再把max_num_seqs压到8试试，长文本场景下KV cache占显存很凶。FP8量化对7B收益一般，画质和稳定性还可能掉点，不如先看是不是prefill排队堵住了，开chunked prefill会舒服很多。真要加卡，两张A10张量并行比换一张大卡

工业场景那段太真实了，我们厂里试过几个号称能理解物理的模型，抓个零件连重心偏移都算不明白，更别提多步骤装配了。Transformer那套注意力机制对因果关系的建模确实先天不足，堆再多数据也补不上这个洞。不过我觉得数据闭环这个方向倒是有戏，毕竟物理世界的反馈信号比纯文本丰富多了，就看谁能先把仿真和真机之间的gap填上。

我跟你遇到的情况一模一样，之前做法律政策问答时也是疯狂往prompt里塞“禁止发挥”，结果模型直接变成复读机，连原文能推断出来的答案都不敢给了。后来我琢磨着，问题不在“写多细”，而在“约束的锚点”放哪儿——与其禁止模型做什么，不如明确告诉它“回答必须包含检索片段中的至少一个关键句”，这样它自由发挥的空间就被结构限制住了。另外你那个年假和调休的问题，其实很可能是检索回来的chunk里压根没同时提到两

这坑太典型了，问题基本就出在embedding不一致上。MCP那边默认走服务端的embedding模型，跟你入库的bge-large-zh肯定对不上，向量空间都不一样检索结果自然就飘了。建议直接在工具函数里显式调用你之前的embedding逻辑，别依赖MCP的默认配置，相当于把query向量化这步完全接管过来。我当初是这么解决的，效果立刻回到正常水平。另外可以顺带在工具描述里注明输入需要是原始文本

我之前也踩过这坑，bge-m3召回没问题但生成乱编，后来发现是没把文档按相关度标序号，模型不知道哪条才是重点。建议你在user prompt里把文档写成“文档1：...文档2：...”这样，然后加一句“优先参考文档1和文档2，其余作为补充”，输出会明显收敛。另外“不知道就说不知道”这个必须加，能砍掉不少幻觉内容。模板大概是：system里写“你是企业知识库助手，只基于提供文档回答，无依据时直接说不

实话实说，两个都不太成熟，PyTorch那个报类型错误八成是官方文档没跟上实际实现，TensorFlow的配置复杂度又劝退。我之前搞跨框架通信直接绕开MCP，用ONNX或者gRPC自己封装了一层，虽然要多写点代码但至少不用跟实验性API死磕。如果你非要二选一，建议看下GitHub上最近的issue活跃度，PyTorch那边修bug速度其实比TF快一些。另外你也看看huggingface那个mcp适