实战派知识库工程手记

我之前也踩过类似的坑，加了prompt模板反而让模型“戏太多”，开始自由发挥。你那个模板里的“专业但易懂”其实挺模糊的，模型容易自作主张去美化格式，不如直接限制它“只输出检索片段中的原话，不要额外解释”。另外RAG场景下prompt越简单越好，重点应该放在检索质量上，模板只需要交代清楚“基于上下文回答，不要编造”就够了，不然模型容易把注意力从上下文挪到指令上。

我最近也在折腾这个，试了一圈下来感觉真没啥万能参数，跟你情况差不多，技术手册和新闻稿简直就是两个世界。我现在基本放弃固定大小了，改成按文档结构走，比如技术手册就按标题和段落边界切，新闻稿就按自然段分，效果比死磕512还是1024稳定多了。overlap的话我一般设10%到15%，主要防止一句话被拦腰截断，但切太碎确实容易把关键信息打散，检索出来一堆片段拼不回去。你提到动态切片，我试过用LangCh

说实话你这个问题我折腾过挺久，最后发现本地7B和网页版根本不是一回事。网页版用的可能是更大参数的模型或者有额外的指令对齐，你拿同样的prompt去要求本地量化版，它理解力确实跟不上，所以输出就飘。 我的经验是，小参数模型对“格式约束”特别迟钝，你让它“提取三点”，它可能只记得“提取”忘了“三点”。与其调temperature，不如把prompt改成更结构化的，比如直接给它一个模板：“输出格式

量化到128肯定丢语义，建议先用768配HNSW，延迟不够再上量化不迟。

我之前也卡在这块很久，后来发现关键是把“运行环境”也喂给它，比如类之间的依赖关系用UML图或者直接贴调用链，它反而能老实点。另外你试过让AI先写测试用例再写实现吗？我这么干以后，它自己会去对齐约束，比单纯给例子管用。不过说实话，涉及改既有模块的业务逻辑，我还是觉得人肉写比调教它效率高，Prompt更适合从零憋个小函数那种。 --- 这题我熟，你试试把“不要做什么”也写进Prompt，比如明确告

你这显存和延迟都对不上，八成是驱动或者vLLM版本问题，535太老了，升到545+试试。

这问题我蹲过，4090 24G跑7B 4bit按理说真不该爆。你查的6-7G是纯模型权重，但vLLM的KV cache是按max-model-len预分配的，8192长度下KV cache能吃掉10G+，加上激活和碎片，24G确实会紧。可以先试试把gpu-memory-utilization调到0.9，然后max-model-len设成6144，再看nvidia-smi实际占用。另外vLLM对GP

16G跑7B长对话确实紧，试试把ctx降到2048再加--no-mmap，或者直接上Qwen2.5-3B-Instruct更稳。 量化救不了KV cache，换32G内存开offload到60%能缓解，但速度会掉一半，建议直接上24G卡。

chunk大小确实得跟着文档结构走，固定字数切很容易把逻辑切断，混合检索能救回来不少。

这题我太有同感了，prompt里写“不知道”对GPT-4来说更像是软性建议，不是硬约束。我试过把“请回答不知道”改成“如果没把握，必须只输出‘不知道’三个字”，能好一点，但细节问题还是偶尔会编。后来我发现根源不在prompt，而是检索回来的内容本身带了似是而非的片段，模型会脑补补全。你试试把输出温度调低，或者加一层校验逻辑，让模型先引用原文再回答，乱编的情况会少很多。

说实话换库大概率救不了你，pgvector在5万这个量级上性能根本不是瓶颈，召回质量跟索引关系不大。你描述的“语义相近但答案不同”恰恰是embedding本身的局限，两个query在向量空间里近，但语义上就是该区分开。我建议先试试重排序，比如用cross-encoder对top20再做一次精排，比换库直观多了。另外也别迷信混合检索，关键词和向量怎么融合权重，调起来又是一堆坑。

这问题太典型了，我也踩过一模一样的坑。光靠Prompt里写“只基于检索内容”真没用，GPT-4对指令的服从度远没你想的那么高，尤其是当它觉得“补全答案”比“遵循约束”更符合对话惯性的时候。我后来试了个稍微靠谱点的办法：在Prompt里把检索内容明确标成“临时事实清单”，然后加一句“如果清单里没有对应信息，直接回复‘未找到相关资料’”，并且把这句话放在用户问题之前，效果会好一些。但说实话，这只能降低

这个观点很实在，跑量的时候显存才是真瓶颈，快那几十毫秒真不如保精度划算。

说实话我之前也踩过这坑，光靠prompt约束真的不行，尤其库存这种动态数据，模型根本没法判断。我是直接把知识库里的商品信息和政策文档做成检索，把检索结果塞进system message里，再让模型只基于这些内容回答，效果稳很多。 另外角色设定放system message确实比user prompt管用，但关键是要加一句“如果信息不在给定资料里，直接说需要人工核实”，别让它自由发挥。你还可以试试

这问题太典型了，ReAct对工具依赖的建模确实弱，建议试试GraphAgent这类显式编排的框架。

rerank真得上，尤其你这种长文档场景，直接提升好几个点，先别纠结chunk了。

说实话你这个现象我太熟了，之前我用7B模型做function call也栽过同样的坑。先别急着怀疑人生，我觉得大概率是数据格式和训练策略的匹配问题，而不是模型能力天花板。你想想，单测的时候你给的输入输出都是规整的，但Agent框架里system prompt、历史对话、工具描述这些上下文组合起来，跟训练时的分布差太远了，模型一遇到没见过的情况就开始自由发挥。我建议你先做一件事：把Agent实际跑出

我之前也踩过这个坑，Qwen系对system prompt的遵循度确实比指令微调时弱一些，尤其是7B这种小参数量。你可以试试把约束条件同时塞进user message里，或者用few-shot给两个JSON输出的例子，比单纯写在system里管用。另外vLLM的上下文长度设置默认是2048，如果对话一长，早期的system内容会被截断，但你这个例子不像截断，更像是模板生成的惯性。要不先关掉chat

别急着换模型，1536维正常用就行，召回率问题多半是chunk切分或检索策略的锅，PCA真没必要。 embedding模型定下来就别动了，换模型所有向量都得重来，成本太高不划算。

这数据量做分类确实紧了点，建议先试试直接冻结base用embedding+分类头，别折腾LoRA了。