需求拒绝内耗工程日常

有没有更详细的教程推荐？

我之前也遇到过类似问题，后来换了方案。

有没有更详细的教程推荐？

写得挺好，建议补充一些性能数据。

学到了，感谢分享！

学到了，感谢分享！

先别急着微调embedding，混合检索加BM25试试，口语化query纯向量确实容易飘。

这个问题我遇到过，而且折腾了挺久才摸清楚Cursor的脾气。它默认会把整个文件甚至关联文件都当成可编辑范围，你让它补组件，它顺手看到Hook里有点“不顺眼”的地方就一起动了。关键是要在提示词里明确划定边界，比如加上“只新增组件代码，不要修改任何已有Hook的定义和实现”，或者直接用@符号把Hook文件排除在上下文之外。我现在的习惯是把要改的文件用#File固定住，然后告诉它只允许在这个范围内操作。

chunk大小这事真不能孤立调，得看你文档本身的粒度。我之前的经验是，技术文档512到800比较稳，但如果是FAQ或者产品手册，按语义段落切比按固定token切强太多，LangChain那些splitter默认按字符切很容易把一句话劈成两半。你那个“苹果手机”和“苹果种植”的问题，其实跟chunk关系不大，更像是embedding模型对领域词不敏感，ada-002在中文短查询上确实容易翻车。bge

我之前也踩过这个坑，Chroma里堆了一堆历史对话，结果检索出来的东西跟当前话题八竿子打不着。后来发现单纯靠向量相似度确实不够，尤其是对话这种短文本，语义漂移特别明显。你说的调高阈值到0.85，我试过类似操作，结果是该召回的也漏了，因为很多真正有用的记忆表述方式跟当前query差异挺大。我现在的做法是加一层时间衰减加权，越近的记忆给一点额外分，但权重别太狠，不然就变成只看最近几条了。另外chunk

我自己的经验是模板别写太长，角色设定一两句就够，堆太多约束反而容易让模型跑偏。建议先固定一个最小模板跑一批测试问题，再针对badcase一点点加规则，这样比直接抄网上的稳。速度方面模板长度影响其实不大，关键还是输出token数，控制回答长度更管用。

loss降了不代表生成对，代码任务得看pass@k，光看loss容易过拟合。

几百条数据做LoRA确实容易这样，格式是学会了，但模型原本的多步推理能力被带偏了。我之前的经验是工具调用微调数据里最好混入一些多步任务的完整轨迹，光教它输出格式不够。另外可以试试调低LoRA的rank或者只微调部分层，别让原版能力丢太多。

异步MCP配同步DataLoader确实坑，我后来用队列解耦，专门开个线程收结果，训练那边照常迭代，凑合能跑。

几万条数据这个量级其实挺尴尬的，Chroma 变慢大概率不是向量检索本身的锅，而是它默认的 HNSW 参数和元数据过滤那块没调好，内存占用高也跟它把索引和原始文档都往内存里塞有关系。FAISS 确实快，但你要接受它只管索引不管存储，持久化、增删改、元数据过滤全得自己包一层，几万条还好，上了几十万条维护成本就上来了。我自己后来换成了 sqlite-vec，图的就是一个文件搞定，备份和迁移都省心，检索

技术文档按标题层级切最稳，聊天记录得带上下文窗口，我一般重叠给个10%到15%就够。

这种问题我也踩过坑，说实话大概率不是工具本身不行，而是Composer在处理跨文件、多步逻辑的时候特别容易“过度发挥”。你描述的场景里，它把useStore初始化逻辑改掉，本质上是它没分清“状态定义”和“状态流转”的边界，你让它加上一步保留数据，它可能理解成要重构整个store。我自己的经验是，别在Composer里直接描述功能目标，而是先手动把要改的文件和函数范围圈出来，比如只选中onSubmi

我上周也拿Composer试过批量处理Excel，跟你情况差不多，逻辑跑通前基本都在修变量名和缩进。后来发现把任务拆成单文件小函数让它逐个生成，再自己拼起来会稳不少，多文件协作确实容易乱编。另外像pdfplumber这种库它有时候会混着fitz的API一起写，最好在prompt里直接点名用哪个库、哪个版本。

几万条数据Chroma确实吃力，我后来换sqlite-vec了，轻量还省心，持久化也自带。

模板变量替换基本都是在客户端拼好再发给模型的，MCP协议本身传的是拼完的最终文本，所以变量多少对首token延迟影响不大。真正吃时间的是拼完之后上下文变长，模型prefill那一段才是大头，上千字的话延迟主要来自这里。我这边八到十个变量的模板跑下来没感觉明显变慢，倒是条件拼接逻辑写太绕容易出bug，建议把复杂逻辑放代码里算好再塞进去。