野生全栈手记

温度降到0.3试试，另外把示例固定成few-shot，输出格式用JSON Schema约束会稳很多。

我一般直接加一句“只改这行，别动结构”，基本就不乱重构了。

几十万切块其实不算大，ChromaDB卡大概率是并发和索引没调好，它默认配置本来就不适合线上多并发。我当时也纠结过，后来直接上了Milvus，资源吃得多但延迟稳，etcd和minio用docker compose一把梭也没那么可怕。Qdrant我觉得挺香的，单机部署轻，几十万级别延迟和内存都比Milvus友好，运维也省心。索引这块别急着上HNSW，先IVF_FLAT压测一下，分片在小数据量下反而容

rank别贪大，我中文客服试过32就过拟合了，16反而稳。数据少就8起步，先跑通再调。

我们之前也纠结过，最后选了Milvus，数据量跟你差不多。运维确实有点门槛，但用Docker Compose单机跑起来其实还好，不一定非得上K8s。查询延迟和召回都挺稳的，中文也没遇到啥坑，分词和embedding模型选好就行。Pinecone省心是真的，但量大了账单涨得也快，建议先拿Milvus试个POC再决定。

我之前也遇到过类似的情况，后来发现光靠调top_k和temperature确实治标不治本。你可以先看看检索出来的chunk是不是真的和问题语义相关，有时候是embedding模型对中文支持一般，换个bge或者m3e试试。另外Agent那层最好加个判断逻辑，让它先确认检索内容能不能回答问题再生成，不然很容易硬凑。chunk overlap影响没那么大，512配50到100就够了，重点还是召回质量。

你这个问题其实挺典型的，我刚开始用GPT写代码也踩过同样的坑。后来发现关键不在指令“够不够硬”，而是你给的约束太抽象了，模型没法把它翻译成具体行为。比如“考虑边界情况”这种话，它理解成“加个if判断”就算交差了，但你要的其实是文件不存在、编码错误、空行、列数不匹配这些具体场景。我现在的做法是把边界条件直接列出来，比如“文件路径不存在时抛FileNotFoundError并打印友好提示”、“空文件返

先看看query时是不是把embedding模型搞混了，存和查用的模型不一致维度对不上就会空。

先别急着换embedding，你chunk带50字重叠很可能把“退款”和“退货”混一块了，重排加关键词过滤比换模型管用。

工具描述这块真的别偷懒，我踩过一模一样的坑。后来把每个工具的description写得特别具体，包括什么时候该用、什么时候不该用、参数格式长什么样，甚至把几个容易混淆的场景直接写进描述里做区分，效果一下子好很多。Agent不调用工具八成是它觉得自己的知识够用了，你得在系统prompt里明确告诉它“涉及实时数据必须走工具，不许自己编”。 循环调用那个问题我遇到过更离谱的，同一个工具连着调五六次。后

我们生产环境是用streamable HTTP配nginx做前置，鉴权走的OAuth2 proxy加自定义header透传，跑了大半年还算稳。stdio确实只适合本地单进程，多客户端并发还是得换HTTP。进程管理可以看下supervisor或者直接上k8s，日志统一丢loki省心很多，systemd硬扛短期能撑但出事排查太累。

我踩过这个坑，后来在工具返回里加了状态码而不是自然语言描述，比如查订单返回 status: “not_found” 而不是“不确定，可能需要更多信息”，模型就不会反复试探了。另外图里加个轻量的意图路由节点确实有用，但别用LLM判断，用规则匹配关键词快得多。真正治本的是给每个工具定义清晰的终止条件，比如连续两次返回相同状态就直接跳出循环走兜底话术。

20万切片top20召回60%确实不算离谱，但肯定还有空间。我比较好奇你说的召回率是怎么算的，是拿标注好的query-doc对来测，还是凭感觉看答案对不对？如果是后者，那问题可能根本不在检索环节。bge-m3本身对中文长文本还行，但它有个坑是不同任务模式（dense/sparse/colbert）出来的分数分布差异很大，你要是直接拿dense分数去卡阈值，很可能把不少相关的给截掉了。混合检索权重这

我之前也踩过这个坑，top-10一股脑塞进去反而干扰更大。后来发现关键问题不在prompt，而是召回片段之间语义重复太多，真正有用的信号被稀释了。可以试试先做一轮MMR去冗余，或者把top-3精排后再喂给模型，效果比硬塞10条稳不少。

用tokenizer自带的padding_side配合attention_mask就行，模板固定部分别进pad，分两段拼更省事。

模板这东西确实挺玄学的，我试下来感觉指令动词比形容词重要，“请回答”和“直接输出答案”效果差挺多。分隔符建议用三引号或者###把输入和指令隔开，不然模型容易把材料当成指令的一部分。变量位置尽量放后面，前面先给清楚任务定义，不然关键信息真会被忽略。另外别一味堆细节，太长反而稀释重点，简洁明确通常更稳。

5000条数据训7B模型确实有点紧，loss卡1.8不一定全是rank的锅，更可能是数据本身多样性不够，模型在死记硬背。lr 2e-4对LoRA来说偏高了，可以试试降到5e-5到1e-4之间，配合cosine调度看看。还有验证集答非所问，建议先检查一下数据格式和label mask对不对，有时候prompt部分没mask掉loss也会假性下降。rank 16其实不算高，真不行换8试试对比下，但我觉

1亿条768维单机确实有点吃力了，瓶颈大概率在内存和索引重建上。HNSW召回快但吃内存，IVF_FLAT省内存但精度和速度要权衡，你这个量级建议先试试HNSW加PQ量化压缩，或者直接考虑分片部署。另外每天几百万增量的话，索引频繁重建也会拖慢查询，可以看看Milvus的Growing Segment机制有没有调好。单机上GPU其实提升有限，不如先把分片和量化做起来。

我也有过这个阶段，越想控制它，结果它越不听话。其实你观察得很准，那些角色设定和step-by-step指令会抢占注意力，模型会把精力花在满足格式要求上，反而对核心逻辑敷衍了事。尤其是“专家模式思考”这类话，很容易触发它过度设计的倾向，好像不搞几个抽象类就对不起专家身份似的。我现在写prompt基本就三段：目标是什么、输入输出大概长啥样、有什么硬性约束，其他全交给模型自己发挥。Aider里我还会刻意

我前阵子也踩过类似的坑，后来发现光靠prompt加例子不太够。会议纪要这种任务，最好把“决策”和“待办”拆成两步做，先让模型标出所有带行动指向的句子，再二次过滤。另外可以试试在prompt里明确排除标准，比如“不含具体负责人和时间点的内容不算待办”，比只给正例管用。