RAG 项目里难的是业务闭环

RAG 项目容易从技术栈开始：向量库、Embedding、重排、Prompt、评测。技术栈是必要条件，业务闭环才决定产品能否长期有用。

RAGon 是一个面向电商场景的混合 RAG 系统。它包含后端 API、前端界面、Pinecone 索引、JWT 认证和接口文档。技术上不复杂，难点在于这些能力如何服务一个真实场景。

电商场景里的 RAG，通常不是为了“让模型回答问题”。它可能帮助客服查商品，帮助运营理解规则，也可能帮助用户找到更合适的答案。目标不同，数据结构、权限边界和评估方式都会不同。问题没有定义清楚，再复杂的检索策略也只是堆技术。

RAG 项目早期常让人兴奋。接上文档，写好 Prompt，模型给出一段流畅回答，demo 就已经像个产品。难点通常出现在第二周：用户问了一个很具体的问题，系统命中了错误文档；规则更新了，索引没有同步；答案看起来有依据，但引用的内容已经过期。

RAG 产品的答案不能只看流畅度。它需要可追溯：依据来自哪里，命中了哪些文档，是否过期，用户能不能继续追问。尤其是电商场景，错误答案可能直接影响交易和售后，产品不能只追求“看起来像对的”。

RAG demo 可以很快做出来，长期可用要靠一套更朴素的运营指标：召回率、引用命中率、无依据回答比例、过期文档比例、人工纠错闭环、失败问题回收速度。没有这些指标，系统看起来会回答，实际上没有变得更可靠。

这里的“科研精神”并不神秘，就是愿意面对失败样本。把答错的问题收集起来，看它是检索没命中、文档本身缺失、重排失败、Prompt 诱导错误，还是业务规则没有写清楚。每一类失败都对应不同的修复方式，不能全都归因于模型不够强。

业务闭环的价值也在这里。一个客服问题被答错后，谁来标记，谁来补文档，索引什么时候更新，下次同类问题是否变好，这些动作构成了 RAG 产品的生命线。没有这条线，系统只是把文档换了一种说法。

把 RAG 当成问答接口，产品会停在 demo；把它当成运营系统，才会自然关注数据更新、失败样本、人工复核和反馈循环。模型生成答案，产品负责让答案逐渐变得可信。

一个可用的 RAG 产品，最好能经得起朴素的问题：一个月后，它是不是比第一天更少胡说；新增文档后，相关问题是不是更容易答对；错误答案出现后，系统有没有留下可修复的痕迹。如果这些问题答不上来，技术栈再完整，也还只是半成品。