自动化研究笔记

先别急着换模型，扫描件和表格没清洗干净，切出来全是噪声，召回准才怪。加个reranker能救一下，但根子还在文档预处理上。

topk=5其实不算大，但问题可能出在你把5段全拼一起，模型注意力被稀释了。我之前也踩过这个坑，后来改成先让rerank模型（比如bge-reranker）过一遍，只留top2-3，效果稳很多。prompt里可以加一句“如果上下文没有相关信息，直接说不知道”，比单纯说“仅根据以下内容”管用。另外每段前面标个序号，让模型引用时能对上，幻觉会少一些。

微调把模型训成只会背QA了，检索文档它当噪声。试试把检索片段混进训练样本，或者先别微调直接RAG。

13B模型在A100 80G上并发一高就OOM，大概率不是模型权重本身的问题，而是KV Cache把显存吃光了。你可以先算一下vLLM里gpu_memory_utilization设了多少，默认0.9的话留给KV Cache的空间其实很有限，把max_model_len调小或者限制max_num_seqs往往比换量化方案来得更直接。GPTQ 4bit确实能压权重，但KV Cache是跟序列长度和并

温度调低点先稳住，模板里加一句“找不到就说不知道”比角色设定管用。

我之前也踩过这个坑，后来改成把每步检索结果先塞进外部存储，Agent 只拿摘要和引用去推理，需要细节再回查。动态摘要确实有用，但别整段压，按 chunk 打分保留关键句更稳。另外可以试试分阶段跑，先对比再总结，别让一个 prompt 扛所有中间状态。

这问题太真实了，我去年做批量摘要也踩过一模一样的坑。说白了prompt里那些角色和格式只是表层，真正决定效果的是模型对你任务里“隐含假设”的理解，换个数据集分布变了，它抓的重点就全歪了。我后来发现最有效的诊断方式是做消融测试，把模板里的每个部分单独删掉跑一批看输出变化，经常能定位到是示例带偏了还是格式约束太死。另外你提到的漏字段，大概率是模型在长上下文里把注意力分给了风格而不是结构，这时候别加fe

换模型维度变了肯定得重索引，10万条不算多，bge-small够用，别盲目追高维。

这问题太真实了，反爬本质是跟人斗智斗勇，AI没那意识，不如自己抓包看token咋生成的再喂给模型。

说实话，我最近也踩过类似的坑，LangChain的Agent一旦任务链条拉长，那个重复调用工具的问题真的挺头疼。我后来发现，光靠调max_iterations和写prompt其实治标不治本，因为ReAct本身对“什么时候该停手换策略”的判断太弱了，它只会按当前观察结果硬着头皮走。你可以试试给工具调用加个“副作用检测”，比如记录每次工具输入输出的哈希值，如果发现完全一样的调用连续出现两次，就强制让它

试试把max_length固定成2的幂，然后padding到那个长度，我这边动态shape也踩过坑。

试试加一层父子分块，父块保留完整语义，子块做检索命中后再映射回去，效果立竿见影。

这问题我踩过类似的坑，A10跑7B理论够但vLLM默认会预分配整卡KVCache，你设了max-model-len但并发上去每个序列的KV还是会动态撑爆。试试把gpu-memory-utilization降到0.7，然后显式加--max-num-seqs 4限死batch，另外AWQ的量化粒度也可能导致显存碎片化，换个GPTQ或FP8对比下。

我之前也卡在这过，后来发现chunk_size跟模型max token关系真不大，核心还是语义完整性。你试试按文档的小标题或段落来切，别死守500这个数，尤其内部知识库很多是表格或条款，硬切会把上下文切断，召回自然就飘了。另外reranker不是最后才上的，检索结果一塌糊涂时先加个bge-reranker，成本低见效快，比折腾embedding模型靠谱。GraphRAG那是后话，先把基础切片和重排

说实话你这问题太典型了，我调RAG prompt也踩过一样的坑。后来发现系统提示词里只放角色和硬性规则，把“怎么组织答案”的具体要求全塞进用户提示词，跟检索内容放一起，效果明显稳多了。另外上下文有限的话，我一般会按相关性排序后只取前3-4段，再在prompt里明确说“如果这些内容不够支撑回答，直接说信息不足”，比硬凑要靠谱。你试试把few-shot改成那种“先提炼要点再展开”的格式，可能比给完整例

我跟你说，这个我太有同感了，之前我们项目也是20多万条数据，加了租户过滤之后延迟直接翻了好几倍，后来排查发现是标量过滤的字段没建索引，Milvus默认是倒排索引，但如果你过滤的字段基数很高（比如时间戳这种），倒排反而会退化得很厉害。你试试把过滤字段改成字典树或者用范围过滤的专用索引，延迟能降不少。另外还有个坑，就是过滤条件如果导致候选集太小，Milvus内部可能会退化成全量扫描，尤其是你数据量不大

我之前也踩过这个坑，后来发现改写query这事儿真不是万能药。bge-small本身对口语容忍度还行，但你把口语转成书面语后，反而可能跟知识库里原文的表述方式拉开距离，相关性下降挺正常的。建议先别急着改prompt，拿原始query和改写后的query分别跑一遍，对比下召回的top10文档到底差在哪，有时候问题出在改写时丢了关键实体词。另外可以试试只在原始query召回结果不理想时才触发改写，做个

你这情况我太熟了，bge系列中文确实偏字面匹配，同义改写基本靠不住。8G显存跑bge-m3有点悬，但可以试试把chunk调小到200-300，让片段更聚焦，再配合一个简单的query改写，比如把问句转成关键词组合，效果立竿见影。另外topk别死磕5，先拉到10再过滤，有时候召回对了排序不对才是真问题。

说实话500字prompt不算长，但问题可能不在长度，而是你把“分类标准”和“语气判断”混在一起了。边缘case翻车很正常，因为模型对“建议”和“抱怨”的边界理解本来就模糊，few-shot给几个例子反而会让它过度拟合到例子里的用词。我建议你把分类任务拆成两步：先让模型判断“用户是否提到了具体改进点”，再决定是建议还是抱怨。另外试试把输出格式改成结构化JSON，强制它先给理由再给标签，准确率会明显

说实话你这个量级我建议先别碰GraphRAG，2万份文档听起来多，但真跑起来实体抽取那步的算力和维护成本会把你团队拖垮的。我自己的经验是，先试试调整chunk size，别死守512，可以按文档类型分开设，比如技术文档用256加重叠40%，会议纪要这种半结构化数据直接按段落切，效果可能比统一参数好很多。至于reranker，我觉得是必须上的，尤其你提到跨段落问题，用个cross-encoder哪怕