生产级RAG研究笔记

这问题我之前也踩过，大概率不是梯度的问题，推理模式下本来就不会存梯度。核心是每次把历史token拼进去后，KV cache会跟着变长，PyTorch这边如果不手动释放旧的graph或缓存，显存自然就堆上去了。建议试试在每轮生成后用del清掉上一次的output和past_key_values，再配合empty_cache，或者干脆用vLLM这类支持自动管理KV cache的框架，省心很多。

先试下把max-num-seqs调小，vLLM默认并发缓存吃显存挺狠的，小流量能立刻缓解。

这问题我太有共鸣了，之前调RAG的时候也被chunk折磨得够呛。我个人的经验是，固定字符数切块真的很难兼顾细节和连贯性，尤其是技术文档里经常有代码块和表格，按字符切很容易把逻辑拆碎。后来我改成按markdown的标题层级来切，段落太长的再递归切，效果明显好了不少，至少“答非所问”的情况少了很多。关于重叠，我觉得64到128都行，但更关键的是要看你的检索策略，如果用了重排序，重叠可以小一点，否则还是

我之前也碰到过类似玄学，换SGD按理说省显存，但优化器状态和AdamW差异挺大的，momentum的buffer有时候反而会挤占碎片空间。gradient checkpointing只开forward的话，backward还是会额外存激活值，试试把recompute也用在backward上？另外建议监控一下第三步的显存分配曲线，很可能就是CUDA缓存碎片化到临界点了，可以试试在epoch开头清一下

这种“踢皮球”我太熟了，大概率不是Recursion Limit的问题，而是每个Agent的Prompt边界太宽，导致它们都以为对方该多干点。建议你给每个Agent写死“输入必须包含哪些字段，输出必须给到什么格式”，缺了就明确报错，别让它们自由发挥“补充信息”。另外仲裁Agent先别急着加，容易变成新的瓶颈，不如先试试让逻辑分析Agent在检索结果不完整时，直接输出“需要哪些具体数据”的清单，而不

说实话你这配置跑7B确实有点勉强，6G显存对int4量化来说还是太紧张了，llama.cpp里--n-gpu-layers能塞多少层就塞多少层，剩下的全靠内存硬扛，内存带宽跟不上自然就卡成PPT。我自己的经验是，这种场景下改线程数作用不大，瓶颈在显存带宽和内存速度，除非你把CPU线程全开让内存通道吃满，但那样温度又压不住。你要是真想7B能稍微动起来，可以试试把KVCache量化到8bit或者干脆关

这个问题我最近也踩过坑，试过把历史记录按窗口截断，但效果不稳定。后来改成只保留跟当前问题实体相关的几轮对话，再配合一个轻量的意图识别去过滤，体感好很多。不过你那句“对比Q2”其实还依赖隐式指代，光靠截断可能不够，要不要试试把上一轮的答案结构化存下来，下次直接检索？这样token能省不少。

4090跑7B按理说确实不该这么紧张，你试试把`--gpu-memory-utilization`降到0.8或者干脆别设，让vllm自己算KV cache的容量。还有个坑是vllm默认会给每个seq预留很多KV cache空间，你并发5-6个时可能缓存碎片化严重，可以加`--max-num-batched-tokens`限一下batch总token数。另外确认下是不是用了最新的vllm版本，旧版本

试过冻结前几层只调后面，效果还行，但负样本构造才是关键，得让模型学会区分检索内容和幻觉。

7B模型对few-shot确实容易过拟合示例表面形式，尤其量化后指令遵循能力会打折。我之前用Qwen2.5-7B跑分类也踩过坑，后来把示例砍到1个，而且特意选边界案例（比如“退货”和“退款”的混杂说法），效果反而回升。你试试把示例里的具体商品名、订单号都换成占位符，让模型抓结构而不是背话术。另外可以对比下0-shot加详细定义+输出格式约束，有时候小模型吃这套比few-shot稳。

说实话我基本只敢让它写胶水代码和测试桩，核心业务逻辑还是自己手写，主要是不敢赌它对我项目里那些隐式约定和状态流的理解。RAG那块我试过拿公司内部文档做向量库，效果比裸模型强不少，但遇到跨模块调用还是容易跑偏，感觉关键还是得靠人工review把住最后一道关。

我也遇到过类似的情况，尤其是它自作主张加props那块，简直跟我家猫一样，明明只要个碗，非要给你叼只死老鼠回来。后来我试了试在项目根目录放个.claude或者.cursorrules文件，把“禁止添加未明确要求的props”“只用函数组件”“不用TS泛型”这些直接写成硬性规则，效果立竿见影。不过说实话，它有时候还是会抽风，特别是上下文太长之后，我怀疑它把之前某次对话里的需求串台了。你说的“记住风格

这问题我太有同感了，之前拿Qwen做函数调用微调也踩过一模一样的坑。单轮准确率漂亮得不行，一上多轮就露馅，连基本的记忆都断片。我觉得核心问题不在LoRA本身，而在你喂的数据结构——纯问答对训练出来的模型，本质是在学“输入到输出的映射”，根本没建立“工具调用-观察结果-继续推理”这种状态机的概念。你想想，Agent推理链条上每一步的输入其实都包含了历史上下文和当前观察，但你的微调数据里压根没这种样本

说实话两个框架我都试过，JAX在显存回收上确实更“狠”，xla编译器会把中间张量重算和释放的策略优化得更彻底，但代价是调试时你根本不知道它到底什么时候释放的，经常是loss突然变成nan或者某个step卡住，查半天发现是buffer复用的问题。PyTorch这边我反而觉得不是框架不行，而是你还没把内存榨干，7B多模态输入里视觉encoder的feature map很容易被忽略，试下把图像token

20个例子塞进去确实太多了，模型反而会被噪声干扰，我之前做分类任务时发现5-8个高质量例子比堆数量强得多。关于放system还是user，我个人习惯放system里当全局指令，user里只留当前输入，这样稳定性会好一些。温度这块，分类任务我直接设0，因为任何随机性对意图判断都是致命的，上午下午结果不一样大概率是API负载导致的采样波动，建议固定seed试试。你那个退货和退款的区别，可以试试把例子改

3000条数据做LoRA确实有点尴尬，但问题大概率不在数据量上，而是在“任务不匹配”上。客服问答本质是限定域生成，但你用开放域基座直接微调，模型会把训练集里的固定话术当成“正确答案”来死记，反而破坏了原本的泛化能力——这跟你学率、rank关系不大。我试过类似场景，建议你先别急着调参，把验证集拆出来看看loss曲线，如果训练loss降得很快但验证集不降，那就是过拟合了，这时降低rank到8、加大dr

试试把异常处理写进需求里的示例代码，模型照着补全比凭空生成靠谱多了。

这个太真实了，做政务问答基本都会踩这个坑。我当时的土办法是把每轮检索到的chunk id存进session，下一轮检索完先做一次过滤，把跟当前问题相关性低但跟历史重合的段落直接丢掉，效果立竿见影。不过要注意别过滤太狠，有时候用户追问里隐含了之前的上下文，完全去掉反而会答非所问。另外你用的LangChain的话，可以试试在retriever里加个custom filter，把历史doc的score做

说实话我觉得这锅不全在AI，Excel处理这种活儿看似简单，但列名、格式、边界情况全是坑，AI猜错太正常了。我自己的经验是别让它一步到位写完整脚本，先让它生成一个能跑的骨架，然后你手动把列名和路径这些硬编码的部分一次性填对，后面再迭代改就顺很多。另外你可以试试给它一个“失败示例”，明确告诉它“上次你猜错了，这次必须用我提供的确切表头”，有时候比单纯给正例管用。工具方面，Copilot在这种具体数据

这个坑我太熟了，之前折腾MCP的时候也是被工具选择折磨得够呛。后来发现一个比较管用的思路是别把Prompt当说明书，而是当“路由规则”——每个工具描述里只写清楚“什么时候用我”和“用我前必须确认什么”，少写参数细节，参数结构放到工具本身的input schema里去约束。这样模型在选择阶段负担小，等它真调用了再按schema校验，能挡掉不少乱传参的情况。另外你说让模型先思考再调用，其实可以试试在工