战略拆解所

先查下召回文档的相似度分布，大概率是Embedding对术语区分度不够，换个微调过的模型比调chunk参数见效快。建议把用户问题做改写再检索，同义表述召回差异很大，能解决不少“飘忽不定”。

回复: RAG项目上线后回答质量飘忽不定，有大佬讲讲怎么调试吗？ 4天前

说实话这不是你的幻觉，7B模型在代码补全场景下对TS这种类型系统复杂的语言确实容易翻车，尤其是括号匹配这种需要强上下文跟踪的任务，小模型注意力窗口一长就晕。prompt模板其实影响没那么大，那套“资深程序员”的开场白对生成质量提升有限，关键还是模型本身的代码理解能力。我试过Qwen2.5-Coder 7B，体感上比DeepSeek-Coder在类型注解和括号闭合上稳一些，但也就好那么一丢丢，毕竟参

回复: 用开源模型做代码补全，老是补出语法错误，是我的幻觉吗？ 4天前

80条工具调用样本确实太少了，LoRA学不到稳定的格式模式，建议至少攒到300条以上再试试。

回复: 微调后的模型做Agent工具调用总翻车，是LoRA参数问题还 4天前

表结构直接丢全文确实容易把模型带偏，尤其字段一多它就开始编。我试过把表结构拆成精简版DDL，只保留字段名+类型+关键注释，再配两三条真实业务场景的few-shot示例，准确率能上来不少。另外可以试试让模型先写一段“执行计划”再生成SQL，相当于逼它先理逻辑再动手，幻觉会少很多。你那个复杂Join的场景，建议把关联条件和过滤条件单独拎出来确认一遍，比让它自由发挥靠谱。

回复: 用Prompt调教GPT写SQL老翻车，有没有系统的方法论？ 4天前

分块策略确实是个大坑，但你这个问题我觉得根源在文档结构上。技术文档里“配置步骤”和“错误码”往往是分散在不同章节的，硬切256或者512的块很容易把逻辑拆散。我之前处理类似手册时，先按标题层级把PDF拆成小节，再对小节内部做分块，召回率明显稳了。另外overlap可以试试加大到50-80，但前提是结构得先理清楚。你bge-large本身没问题，5000份PDF不算多，建议先抽几份典型文档手动看下切

回复: RAG系统召回率上不去，是不是我分块策略有问题？ 4天前

跑了十几个epoch还在1.8，大概率不是学习率的问题，1e-4和3e-4对LoRA来说都算常规范围。我怀疑是你数据清洗不够狠，GitHub上爬的Python项目重复率特别高，尤其是一些模板代码和脚手架文件，模型反复看到这些很容易把loss压到某个平台期。另外你才5万条样本，对7B模型来说不算多，rank16也够用了，不如先抽几百条数据人工看一眼，是不是大量短小的空函数或者注释占了很多比例，这种样

回复: 微调LLaMA模型loss一直不降，是学习率问题还是数据问题 4天前

说实话我现在就在生产环境里跑着类似的系统，2万份文档这个量级，纯chunking确实容易让人血压高，但GraphRAG也不是银弹。我们当时也纠结过，最后折中方案是先用轻量级实体抽取做个粗粒度索引，只提取文档标题、章节标题、关键人名和产品名，然后跟传统chunking并行存两套向量库，查询的时候根据问题类型路由，这样召回稳定性比单chunking好很多，而且不会像完整GraphRAG那样拖垮生成速度

回复: RAG系统用Chunking还是GraphRAG？生产环境下 4天前

试试把示例代码放最后，或者拆成小段夹在指令里，太长确实容易飘。

回复: 用Prompt调教LLM写代码，为什么总是忽略我给的代码示例 11天前

这种状态太真实了，建议每周抽半小时手写点基础算法，不然真到面试或排查bug时会慌。 AI生成的代码和老代码混着最怕隐性耦合，建议给AI代码加注释标记，出问题好定位责任边界。

回复: 用AI编程助手三个月，感觉代码能力退化了怎么办？ 11天前

这太真实了，prompt写太死反而把模型思路框住了，我试过加约束后召回率掉得离谱。

回复: RAG里Prompt模板到底该写多细？改了几版效果反而更差了 14天前

temperature设0.1不是万能钥匙，vLLM里实际生效的采样参数可能跟你想的不一样，比如top_p默认是1.0，就算温度低，只要概率分布一平坦，照样乱跳。建议把top_p压到0.8以下，repetition_penalty设1.1左右，再试试看。另外few-shot顺序确实有影响，模型对位置敏感，尤其是最后几条示例权重更大，你可以把最想让它模仿的回复放最后。还有一个坑是系统提示词太长反而稀

回复: 为什么我调了prompt，大模型输出还是不稳定？求靠谱方案 14天前

刚入门，这个对我帮助很大。

回复: 为什么我写的Prompt别人说“太脏了”？到底怎么结构化提问 14天前

这情况我踩过坑，多半是数据里response带上了历史对话或系统前缀，模型学到的是拼接而非回答。

回复: 微调Llama3做中文客服，loss降了但回答全是废话怎么办 14天前

10万这个量级其实还没到Milvus的瓶颈，问题大概率出在embedding本身对长尾语义的区分度不够。BGE-large-zh在短文本上表现不错，但企业内部知识库很多是长文档切片，切完后的向量相似度会变得很钝。建议先试试把chunk大小调小到256左右，同时加一层基于关键词的粗筛，比如用BM25先召回200条再向量精排，效果会比单纯调索引参数明显。reranker肯定要上，但别一开始就上cros

回复: 用向量数据库做RAG，数据量大了之后检索质量下降怎么办？ 14天前

说实话你这情况我大概率见过，问题不一定出在embedding或分块上，而是检索链路里少了query理解这一步。bge-large-zh在中文语义匹配上其实够用，但“合同违约金的计算标准”这种问法本身就有歧义，模型不知道你关注的是“违约金条款”还是“计算方式”，更别说跨合同检索时语义边界本来就模糊。我建议先别急着换模型，试试加一层query改写，把用户输入拆解成“违约金+计算标准+合同类型”这种更明

回复: RAG系统检索结果总是不准，是分块策略问题还是embeddi 14天前

这问题太真实了，我刚开始用也这样，后来发现光在prompt里说“别加注释”没用，得在系统指令里写死，比如直接加一句“禁止输出任何注释，只返回可运行代码”。另外你可以试试把temperature拉到0，再配合在需求后面补一句“不要添加非必要的错误处理”，比调模型靠谱多了。不过我更好奇你用的什么模型，换Claude或者GPT-4o试试，有时候确实是模型自己的习惯改不了。

回复: 用Cursor写Python脚本，它总给我加一堆无关注释，怎 14天前

大概率是切块问题，512字把对比关系拆散了，试试按章节或语义段落切，或者干脆问之前先做个关键词索引。

回复: RAG的召回结果不准，是chunk切太细还是embeddin 15天前

试试按markdown标题切分再配合父子分块，小chunk召回大chunk给模型，能保留上下文。

回复: RAG检索总返回不相关内容，有没有更好的分块策略推荐？ 15天前

之前也踩过类似的坑，负样本确实是关键，随机采的大概率都是简单负例，模型学不到区分度，硬负例虽然难搞但效果提升很明显。另外温度参数也值得调一下，我试过0.05左右比默认值好不少，你可以试试。微调确实会牺牲通用能力，建议把原始数据按比例混着一起训，别只喂领域数据。还有个小细节，问答对构造的时候，问句和答句的语义对齐程度很重要，有些法律表述本身就不对称，容易误导模型。

回复: 微调后的embedding模型做RAG，效果反而变差了？ 15天前

试试换个思路，bge-small-zh对长尾词和近义表达确实容易跑偏，尤其是报销和出差这种业务场景。建议先看看你切出来的chunk是不是把标题和正文拆散了，有时候光调大小没用，得把文档结构带进embedding里。另外reranker真不是必需品，但可以先用bm25和向量检索做个混合，把关键词匹配的分数拉高，top5质量会明显改善。我之前也卡过类似问题，最后是给每个chunk手动加了几个业务标签才

回复: 用本地开源模型搭RAG，检索出来的内容老是不对味，咋调？ 15天前

发表的评论