做 RAG 原型很快：切分文档、生成向量、取回 Top-K、交给模型。可是从 Demo 到可用产品之间，常常隔着三个不起眼的工程问题。
一、索引之前的数据质量
格式混乱、版本过期、权限不明的文档，不会因为向量化就变好。每个知识片段都应带上来源、更新时间、权限与稳定标识。切分策略也应服从内容结构，而不是机械地每 500 字截断。
chunk = {
"content": normalized_text,
"source_id": stable_document_id,
"updated_at": timestamp,
"access_scope": ["team:infra"]
}
"content": normalized_text,
"source_id": stable_document_id,
"updated_at": timestamp,
"access_scope": ["team:infra"]
}
二、没有评估，就没有优化
先从二十到五十条真实问题开始。记录期望答案、必要事实与应命中的来源，把“回答是否好”拆成检索召回、事实忠实度和任务完成率。评估集不必完美，但必须可重复。
每次调整 embedding、切分方式或提示词，都跑同一组问题。否则团队只是在凭最新的几个例子做判断。
三、用户反馈需要可行动
一个“赞/踩”按钮的信息量很低。更有用的反馈是：答案过时、没有回答问题、引用错误，还是操作步骤不可执行。分类后的失败样本才能回到评估集和数据管道。
最后
可靠的 RAG 产品，本质上是一套知识维护与质量控制系统。模型会不断更新，但高质量数据、可重复评估与反馈闭环仍是最耐用的资产。