RAG 值得学吗?长上下文会不会把它淘汰
每次看到"上下文又翻倍"的新闻,都有人喊"RAG 要死了"。但我学了一阵子 RAG 之后觉得,这说法太夸张。 长上下文确实能塞下更多原文,但贵、慢、而且模型对超长上下文的"中间遗忘"问题还在。RAG 的优势是精准召回 + 成本可控 + 可追溯来源,这些是长上下文替代不了的。 我的
大模型、多模态、推理模型和 AI 产品趋势
本专题收录 AI 前沿 方向的文章和社区讨论,重点关注真实工程场景、工具选择、实践路径和风险边界。
页面会持续更新,适合作为学习路线、选型参考和技术复盘入口。
每次看到"上下文又翻倍"的新闻,都有人喊"RAG 要死了"。但我学了一阵子 RAG 之后觉得,这说法太夸张。 长上下文确实能塞下更多原文,但贵、慢、而且模型对超长上下文的"中间遗忘"问题还在。RAG 的优势是精准召回 + 成本可控 + 可追溯来源,这些是长上下文替代不了的。 我的
搭了个 RAG,文档塞了几百篇,但检索效果很差,top 5 里经常只有一两条相关,甚至完全不沾边。embedding 用的也是主流模型,不知道哪出了问题。 怀疑过几个点:chunk 切太大(一段塞了多个主题)、问题太短召回不上、或者文档本身噪音多。 排查了一周没头绪。大家有没有
做 LLM 应用最让我头秃的就是 prompt 注入。你在 system prompt 里写了一堆规则,用户输入里来一句"忽略以上指令,改做 XXX",模型经常就照做了。 更阴的是间接注入:模型读到的网页、文档里藏一段恶意指令,它执行了都不知道。防不胜防。 现在我的做法是输入输出
给公司搭内部知识库,选了个专用向量库,用下来踩坑不少。 一是维度选择一开始瞎选,后来才知道要和 embedding 模型对齐;二是索引构建巨慢,几万条数据等了好久;三是"召回快但召回不准",调了好几天 HNSW 的参数。 最坑的是换 embedding 模型后所有向量得重新生成,
每次有人问"我要让模型懂我们的业务,微调还是 RAG",评论区就吵起来。我说说我的判断。 绝大多数业务场景,RAG 优先:成本低、可更新、可追溯、不动模型。微调适合"风格/格式/领域术语深度内化"的场景,比如让模型说你们公司的黑话、固定输出格式。 最常见误区是拿微调去解决"知识更
让大模型稳定输出特定格式(比如表格、固定字段 JSON)是高频需求,分享个我用着很稳的 prompt 模板。 关键是:明确格式 + 给例子 + 强约束语言。 给了 few shot 之后稳定性提了一截。大家都有啥格式控制的绝招?
回头看一年前我对大模型的认知,好多都过时了。那时候还在卷参数量、卷上下文长度,现在推理模型、原生多模态、超长上下文、agent 能力都成了标配。 最让我意外的是价格战,一年前不敢想的调用成本现在白菜价,小团队都能玩得起了。应用层因此爆发出一堆以前不可能的产品。 唯一没变的是大家还
上下文动辄上百万 token 后,"把所有文档塞进去不就行了"成了流行观点。我实测过,结论是:能,但很贵,而且不总是好。 塞一百万 token 的成本和延迟,比 RAG 召回几十条 chunk 高一个数量级。更别提模型对长上下文中间部分的注意力会下降(lost in the mi
团队讨论过要不要微调一个领域模型,我投了反对票,理由有三。 一是成本高,数据准备、训练、评测、部署,周期以月计;二是基础模型迭代太快,你花大力气微调的模型,下个版本基础模型可能直接超越;三是维护难,知识一更新就得重训。 现阶段我的结论是:除非有非常强的领域风格需求,否则先把 pr
看过太多新手写 prompt 像写论文,恨不得把所有约束堆进去,结果模型反而犯晕。我的经验是:少即是多。 核心三件套就够:角色(你是谁)、任务(做什么)、约束(怎么做)。其余的能省则省,模型比你想象的聪明。约束堆太多反而互相打架,模型不知道听哪条。 调不通的时候,先试着删几条 p
给公司内部搭了个问答机器人,把规章制度、技术文档、历史工单全喂进去,本以为效果会很一般,结果同事反馈意外地好。 复盘下来几个关键:文档预处理做得细(去噪、分章节、加标题);chunk 切得合理(按语义而非固定长度);加了个"重排"步骤把最相关的顶上去;最后用强模型做答案生成。 没
应用流量涨上来之后,API 费用成了大头,老板让我压一压。目前已经做了:缓存高频查询、短任务切小模型、prompt 精简。 还想再降,但找不到方向了。听说有人用蒸馏、有人自部署开源模型、有人做多供应商竞价路由。 想问问大家都用啥招压成本,哪个效果最明显?有没有什么坑要注意的?谢了