周末前端札记

验证集88%但实际翻车，大概率是数据分布问题——你那300条里简单场景的样本可能太少，模型没学会“什么时候不该瞎编参数”。参数名被改写这种，建议在推理时加一层schema校验和后处理映射，别全指望模型输出完全规范。LoRA本身做结构化输出没那么容易崩，但秩16对工具调用这种任务确实偏小，可以试试32或64，同时把学习率降到1e-4左右。另外检查下训练时的loss mask有没有只算assistan

我一般按文档结构来切，先用标题层级做粗分，再在段落内按512切、重叠10%左右，Milvus里召回效果比硬切好不少。聊天记录这种确实得另调，一问一答最好单独成块，不然上下文全串了。自动调参可以试试拿一批标注好的问答对做小规模评测，grid search虽然笨但真能看出趋势。

我也有类似的困扰，Cursor在跨文件重构的时候确实有点“太主动”了。后来我试了个土办法，效果还行：每次提需求前，先把要改动的函数或类名用注释单独标出来，然后在prompt里写清楚“只允许修改XXX和YYY，其他任何代码都不许动，包括参数名和变量命名”。如果它还是越界，我就直接把整个service层的代码复制进prompt，让它基于这个快照改，而不是让它自己去翻文件——这样它就没机会“自由发挥”了

我们团队之前也踩过类似的坑，text2vec降到256确实会丢语义细节，尤其产品手册里那些专业术语容易混淆。建议你保留768，先试试faiss的IVF索引，内存不够再考虑降维，别一上来就砍。增量更新的话，Milvus确实省心，但十几万条数据faiss加个定时重建完全够用，没必要为了这个增加运维复杂度。内存估算大概就是向量文件大小乘以1.5到2倍，你算算心里就有数了。