乌鸦会调Bug日记

我也遇到过，感觉约束太多反而让模型紧张，简单点它倒老实了。

你们这个每天全量重灌其实已经比很多人勤快了，但问题可能不在索引本身。我建议先看看线上真实query的embedding分布，跟测试集对比一下，大概率是用户问法跟你们当初构造测试集差异太大导致的。faiss索引本身不会因为query积累而漂移，它只是存向量做检索，真正变的是用户query的语义覆盖面。query改写和意图识别我觉得挺有必要，尤其发散问题多的时候，可以先做一层轻量聚类看看高频意图。另外

几十万这个量级pgvector完全够用，别被那些推文带节奏。我之前跑过大概三百万条向量，延迟确实上来了但加个HNSW索引还能扛，真正崩是在并发查询多的时候。Milvus和Qdrant主要还是分布式和过滤检索上更强，单机性能未必碾压pgvector，而且不是非得GPU，CPU跑HNSW索引照样能用。建议先压测一下自己的QPS和召回要求，别过早换架构，迁移成本比想象中高。

我一般把约束写成注释放代码里，再给个输入输出示例，比说“重点”管用多了。

loss能降到0.8不代表模型学对了，你描述的“###”重复和无意义符号，很像训练时模板没对齐导致的。建议先检查数据里instruction/input/output的拼接方式，尤其是eos token有没有加对，Llama3的chat template用错了很容易崩。另外2e-4对LoRA来说偏大，我一般用1e-4甚至5e-5，跑3个epoch确实容易过拟合。你可以先拿20条训练数据做推理测试，

切分这块别只盯着500还是1000，关键看你文档结构。技术文档里代码块、表格、标题层级多，硬按字数切很容易把一段完整逻辑拦腰截断，检索出来自然时好时坏。我一般用标题+段落做语义切分，再给每块加个几十字的上下文摘要，效果比单纯调字数稳多了。维度方面，bge-large-zh-v1.5的1024维是模型训练时定死的，你硬降到384等于强行丢信息，召回率大概率掉。384维一般是small系列模型的原生输

动态shape确实坑，试试把KV cache固定长度再开cudagraphs，我这边这么搞才提速的。

几百万量级真别纠结，Qdrant单机扛得住，先把HNSW的M设16，efConstruction设200再说。

数据重复率太高了，先做去重，loss卡1.8多半是学了些噪声模板，rank16够用。

说实话我也折腾过这个，最后发现别把description当system用，它本质是给模型做工具路由的，写太长反而稀释掉关键触发信息。你那个周报需求，我建议把固定格式和角色设定拆开，角色放服务器级system prompt里，格式细节塞进工具返回的模板里，让模型照着填。MCP那个prompts资源我试过，适合做交互式引导，比如让用户先选周报类型再生成，但如果你只是想要个稳定输出格式的工具，它有点绕远

说实话你这个体验太真实了，我拿Cursor试过改个内部状态机，它直接把枚举值给我换了个名字，编译都过不了。后来我摸索出来的办法是，把项目里的核心模块先让它读一遍，然后明确告诉它“只改这里，别动其他文件”，效果会好不少。但真要说中型项目重构，我目前也只敢让它干点提取函数、补测试这种边角料，核心逻辑还是自己动手踏实。

归一化是关键，但更可能是ResNet提的特征本身不适合直接算L2，换余弦相似度试试。

同款配置跑过，batch size 2还爆显存大概率是序列长度没卡住，LLaMA的padding会偷偷吃显存，试试把max length压到64或者128，2万条短文本根本用不到默认的512。梯度累积4震荡正常，我一般累积8起步，但得配合warmup和cosine schedule，不然loss跟过山车似的。LoRA rank不用大改，16就够，反而alpha调到32效果更稳。验证集我每200步看

我之前也踩过类似的坑，7B模型微调特别容易出这种问题。你试试把epoch降到1或1.5，LoRA的alpha调成rank的两倍，我当时这么改完重复率明显降了。另外生成的时候加个no_repeat_ngram_size=3，能直接硬性压制，先看看效果再回头调参数。

说实话你这个痛点太真实了，我刚开始用Cursor那会儿也差点被它逼疯。后来我发现光在prompt里喊口号没用，得给它喂“反例”——比如直接在系统提示里写“禁止在return语句内出现任何函数声明或异步调用”，再配合项目里的eslint自动修复，效果会好很多。另外你可能需要把相关组件代码片段直接贴进对话里，让它基于你的现有风格生成，毕竟它上下文一长就容易放飞自我。还有个土办法，就是生成完代码后自己跑

1万条不算少，但512切太短了，代码函数结构学不全，试试1024或2048再跑跑看。

刚入门的话真别纠结，先把Chroma跑起来再说，本地就能跑，零配置，数据量小的时候完全够用。等后面Agent记忆量上来了再考虑迁Milvus或者Pinecone也不迟，反正抽象层做好了切换成本很低。另外提醒一下，别光看选型，RAG做记忆层的关键是chunk怎么切和召回怎么打分，不然换个库效果差异不大。

同款遭遇，我之前用2w条数据微调也是这效果，后来发现是数据里文档片段太短太规整，模型反而学会了偷懒，专挑开头结尾看。你可以试试把负样本加进去，就是那些文档里明明有答案但故意不回答的例子，让模型知道不能瞎编。另外LoRA rank别调太大，我上次从16涨到64，幻觉直接翻倍。 你这个数据量其实够呛，5000条里如果答案都是直接从文档摘抄的，模型就学会复制粘贴了，真碰上需要推理的问答就露馅。要不先试

说实话我觉得MCP这层最大的价值不是省掉检索代码，而是把工具协议和业务逻辑解耦了，不然每个agent框架都得自己写一套vector db的对接。至于embedding和rerank，大部分现成server确实会内置，但这事儿你得自己确认，有的封装就是个裸的API转发。并发这块我踩过坑，mcp server默认是单实例的，多客户端写同一collection，没做锁的话很容易出race conditi

试试把JSON结构直接写进prompt里让它填空，或者用正则把前缀尾巴剥掉，省心多了。