星河远航

我一般不会只调K，先看召回阶段有没有问题。你可以拿一批标注问题测一下recall@K，看关键chunk到底排在第几，如果本来就在10名开外，那调K意义不大，得先换embedding或者改切分。实际项目里我常用K=10到15先召回，后面加个rerank把无关的压下去，比单纯把K设小或设大稳很多。512的chunk配bge-large其实还行，但重叠区最好留一点，不然边界信息很容易被切丢。

7B做RAG检索质量比生成更关键，先把embedding和rerank换强的试试。

父文档检索确实管用，把小块检索映射回大块再喂给LLM，连贯性会好很多。

是不是训练数据里assistant回复开头总爱复述一遍问题？LoRA在5000条上很容易学到这种模式。我遇到类似情况时把训练集里带复述的样本清了，或者把用户长指令改写成简洁版再喂进去，推理就正常多了。另外你loss降到0.8可能已经过拟合，试试early stop或者调低rank看看。

先查召回吧，把query和top5 chunk打出来看，八成是embedding没抓住流程类语义，换bge试试。

微调LLM其实改不了检索本身，它影响的是拿到chunk之后怎么用。你检索准确率没变太正常了，因为召回靠的是embedding模型，LLM微调管不着这块。想让LLM更好地利用检索片段，数据构造得更讲究点，比如故意混入无关chunk让它学会忽略，或者训练它引用原文而不是自己编。1000条数据3个epoch确实容易欠拟合或者过拟合，得看loss曲线才知道。

工具定义全塞进上下文确实会拖累选工具的准确率，我这边也踩过这个坑。后来把不常用的几个server改成按需加载，只在prompt里保留当前任务相关的工具，响应快了不少。生产环境我一般控制在3到4个核心server，其余走路由或者子Agent分发。你七八个常驻的话，建议先看看哪个server的tool数量最多，那个往往是罪魁祸首。

几十万切片这个量级其实挺尴尬的，Chroma确实能撑住，但它的索引策略比较粗糙，默认hnsw参数不一定适合你的数据分布，所以查不准未必全是embedding的锅。你可以先固定同一个embedding模型，只换检索库对比一下top-k结果，这样能排除掉模型变量。我自己试过用bge-m3配Chroma，召回明显比默认的all-MiniLM好，但前提是得把distance metric调对，Chroma

阈值太死确实容易翻车，我一般先检索top-k再重排，比卡0.8这种硬线稳多了。

我搭RAG的时候也踩过这个坑，后来发现是few-shot里的示例格式太“强势”了，模型会优先模仿示例的句式而不是去读检索内容。你试试把示例改成只展示“如何引用上下文”的推理过程，而不是直接给问答对，比如让示例里出现“根据手册第X节……”这种锚定检索结果的写法。另外示例别放system里，塞在检索结果后面当assistant的草稿更稳，我用这招后幻觉少了很多。

先别急着怪量化，FP32转ONNX就可能因SiLU近似实现掉点，建议逐层对比输出找偏差源头。

7B写复杂SQL确实勉强，14B也就好一档，建议直接上32B或者干脆用API。

说实话你这问题我太有共鸣了，之前搞过类似的代码评审流水线，三个Agent串起来后也是各种读脏数据。我后来发现核心不是等不等的问题，而是LangGraph的state更新本质上是节点返回后整体覆盖，你得把每个Agent的输出字段设计成带版本号的独立channel，比如retrieval_result带个时间戳，下游节点读取时校验版本，而不是靠执行顺序去猜。另外你说的Send API，我建议别急着上，

试试用pytorch的autograd检测钩子，在backward之前打印每层tensor的size，配合`torch.cuda.reset_peak_memory_stats()`和`torch.cuda.max_memory_allocated()`分段跑，比如把每个transform单独拎出来过一遍，基本能锁定是哪个操作在涨。我之前遇到过类似情况，最后发现是自定义Dataset里把整张图的所

这问题我太有同感了，之前用类似配置调一个法律问答模型，也是loss降得挺漂亮，一测生成直接崩。你提到中英混杂，我猜数据里可能有不少英文模板或者标点符号混进去了，LoRA对这类噪声特别敏感，模型会误以为新格式就是标准输出。另外2e-4的学习率配合rank=32对8B来说有点激进了，我后来降到1e-4甚至5e-5，然后把epoch砍到1，效果反而稳很多。还有个坑是数据里如果客服回复带了太多固定话术，模

我之前也遇到过类似情况，排查下来发现是输入到模型里的feature map在forward时被重复保存了，比如某些自定义模块里用了多次forward调用。你可以试试在推理模式下跑一遍（不更新梯度），如果显存占用明显下降，那就是中间变量缓存的问题。 另外建议用torch.cuda.memory_summary()看下具体是哪块内存峰值高，或者装个pytorch_memlab逐层打印，很快就能定位到

试试把检索内容按相关度排序后只留前三段，再在prompt末尾加一句“若文档无关请明说”，效果会稳很多。

我之前也卡在切片这块挺久的，后来发现固定字符数确实不靠谱，现在基本按语义边界切，比如markdown标题或段落，再配个50-100的overlap。技术手册这种结构化的文档用递归切片效果好，新闻稿反而直接按句子切更稳。你可以试试LlamaIndex的SentenceSplitter，或者用RAGAS跑个检索质量评估，比手动调参数直观多了。

几万条文本块其实Chroma完全扛得住，我拿它跑过类似量级的项目，查询延迟基本都在毫秒级。Milvus那个全家桶配置确实劝退，除非你要做分布式或者上亿向量，不然前期成本太高了。建议先Chroma把功能跑通，真到几十万量级再考虑迁移也不迟，毕竟数据格式又不是绑死的。另外可以看看Qdrant，单机版部署比Milvus轻不少，性能也挺稳的。

我之前也踩过类似的坑，rerank用LLM微调不是简单套个LoRA就行的。你loss降了但效果差，很可能是训练数据里query和文档的“相关性”标注太模糊，模型学到的是表面文本匹配，不是真正的排序意图。另外，几百条样本对7B模型来说太少了，LoRA微调很容易过拟合到训练集，泛化不到真实检索场景。建议先试试直接用Qwen2-7B的zero-shot打分，或者用更小的cross-encoder（比如b