RAG里做Prompt工程，到底该把精力花在system还是query改写上？

说实话这俩不是二选一的事儿，我最近刚踩完类似的坑。system里写“严格基于文本”其实模型很难感知到边界，它分不清哪些是背景铺垫哪些是核心论据，后来我把指令改成“只引用文本中直接回答用户问题的句子，禁止转述上下文”，效果明显好了点，但你这问题的根子可能还在chunk质量上。query改写我试过压缩成关键词，召回确实干净了，但生成时模型缺少原问题的语气和限定条件，反而容易答得泛。我的经验是，把精力先放在检索回来的内容排序上，比如用LLM做个粗筛，把纯背景介绍的段落扔出去，只留真正带结论的片段，这比在两端prompt上死磕性价比高。另外你可以在system里给个负面示例，明确告诉它“如果文本只提到背景，就回答‘未找到相关信息’”，这比抽象规则管用得多。想问你用的是父子分块还是纯固定窗口？我怀疑你chunk粒度太大，模型才容易被旁枝末节带跑。

我最近也踩过这坑，system写得再狠不如把query拆细点，但生成质量还得靠few-shot拉回来。

也试过在system里塞“只输出原文摘录”，结果模型直接摆烂，后来改成让query带上文档结构词才稳了点。

说实话这俩不是二选一，我自己的经验是system只能兜底，真正影响生成质量的是你喂给模型的上下文结构。你那个被背景介绍带偏的问题，与其纠结让它别联想，不如在拼chunk的时候就把关键信息前置，或者用分隔符高亮出和query强相关的句子。

query改写那边我倒是觉得你别只做关键词化，试过把口语问题转成“根据xx文档，回答xx”这种带约束的检索式吗？召回准了之后生成还是会飘，多半是chunk本身太长太杂，模型抓不住重点。

我现在的做法是system只写一句“优先引用delimiter内的内容”，然后花更多精力去调chunk的重排和截断逻辑，把最相关的段落放前面，效果比光调prompt明显。你可以试试在拼prompt时把每个chunk前面加个来源标签，也方便你debug看它到底引了哪段。

我觉得你这个问题其实两个都得做，但重心可能得放在query改写上。system指令只能约束模型的“态度”，但管不住它被上下文里那些干扰信息带跑，本质上还是检索内容不够精准。我自己的经验是，与其花时间磨system的措辞，不如把精力放在把用户问题拆成更明确的检索意图，比如加一些过滤词或者限定范围，反而能减少无关chunk混进来。另外，你可以在拼prompt时把chunk按相关度排序，或者加个“如果文本未提及请直接说不知道”的提示，这样比单纯强调“基于文本”更有效。

我个人经验是system指令写得再狠也扛不住检索内容本身带偏，你不如把精力放在chunk的修剪上，比如把背景段单独截掉只留结论，效果比改query立竿见影。query改写其实更适合处理那种用户问题本身含糊的场景，像你这种生成不稳定，我猜是top-k抽回来的段落信息密度太低，试试调小chunk大小或者加个rerank。另外system里加“如果文本没提就直接说不知道”比“不要联想”管用得多，你可以试试。

我踩过类似的坑，后来发现光在system里喊“别联想”基本没用，模型该跑偏还是跑偏。我的经验是query改写和chunk重排得一起抓，比如给每个chunk加个相关性打分再截断，比堆system指令管用。system里可以写“如果给定内容不足以回答就直说”，反而比“严格基于文本”更让模型克制。你现在的检索式改写是用LLM还是规则？这块可能还有优化空间。