一人公司使用大模型回答产品、服务或客户问题时，真正困难的通常不是“让模型说得像人”，而是让每个答案能够回答三个问题：依据哪份文档、依据哪个版本、没有依据时能不能停下来。
如果只是把几十份文件塞进提示词，文档一更新，旧规则仍可能被模型引用；如果只展示一段看似准确的回答，经营者也很难判断它来自内部资料还是模型补写。因此，知识库的价值不是让回答显得更聪明，而是建立“问题—检索证据—候选回答”的可追溯链路。
本文先用零依赖 Python 实现一个本地检索原型，再把同一套规则映射到阿里云百炼知识库和 OSS。示例代码已在本地运行；云端部分属于依据官方文档整理的架构方案，不代表已经完成真实账户部署、压力测试或费用验证。
一、RAG最小闭环不只有“上传文件”
RAG（检索增强生成）的基本思路，是先从外部知识中找出与问题相关的内容，再把证据交给大模型生成回答。对一人公司而言，最小闭环至少包含五步：
版本化文档
↓
切分与建立索引
↓
根据问题检索 Top-K 证据
↓
达到阈值：携带证据生成候选回答
未达阈值：拒答或转人工
↓
记录问题、证据版本和处理结果
这里有两个容易混淆的概念。
第一，知识库并不自动保证事实正确。如果原始文档本身过期、冲突或缺少生效日期，检索得再准确也只能召回错误依据。
第二，RAG降低的是模型脱离私有资料回答的概率，不是消除幻觉。系统仍需规定：模型只能依据检索片段作答；没有足够证据时输出“不确定”，而不是补全一个听起来合理的结论。
二、用零依赖Python验证检索规则
在开通云服务之前，可以先用一个小型本地原型验证文档字段、检索阈值和拒答逻辑。示例准备三份虚构但明确标注版本的规则文档：退款规则、发票说明和服务时间。它们只是教学数据，不代表任何真实公司的政策。
每份文档至少保存四个字段：
@dataclass(frozen=True)
class Document:
doc_id: str
title: str
version: str
text: str
为了让程序不依赖第三方库，示例把连续中文转换成双字片段，再使用 TF-IDF 权重与余弦相似度排序。这不是生产级语义向量模型，但足以验证“证据必须带版本”和“低于阈值必须拒答”两条业务规则。
核心检索接口如下：
def search(self, query: str, top_k: int = 2,
threshold: float = 0.08) -> list[dict]:
query_vector = self._vector(Counter(tokens(query)))
ranked = []
for document, counts in zip(self.documents, self.doc_tokens):
score = self._cosine(query_vector, self._vector(counts))
if score >= threshold:
ranked.append({
"doc_id": document.doc_id,
"title": document.title,
"version": document.version,
"score": round(score, 4),
"text": document.text,
})
return sorted(
ranked,
key=lambda item: item["score"],
reverse=True,
)[:top_k]
运行完整代码：
python aliyun-traceable-rag-knowledge-base.py
输入“我购买数字产品后还能退款吗”，程序会返回 refund 文档、版本日期、相似度和原始证据。它不会直接生成流畅答案，而是先构造一份可以交给大模型的证据包：
{
"answer_policy": "answer_only_from_evidence",
"query": "我购买数字产品后还能退款吗？",
"evidence": [
{
"doc_id": "refund",
"title": "退款规则",
"version": "2026-07-01"
}
]
}
如果查询与三份文档都不相关，evidence 为空，策略变成 insufficient_evidence。后续模型调用看到这个状态后应直接拒答或转人工，而不是继续编写答案。
三、从本地原型映射到阿里云百炼知识库
阿里云百炼的知识库能力使用 RAG 为模型补充私有数据和较新的信息，并支持从本地或 OSS 等来源导入资料。官方文档同时提示，当前知识库能力存在地域、规格、模型和计费条件，实际可选范围可能更新，因此部署前必须在目标账户和业务空间中核对。
本地原型与云端组件可以这样对应：
| 本地原型 | 云端职责 |
|---|---|
Document 列表 |
OSS中的版本化原始文档 |
| 双字词元与TF-IDF | 百炼知识库的文档解析、切片和语义检索 |
threshold |
知识库检索相似度阈值 |
top_k |
召回片段数量 |
evidence |
检索返回的文档片段和元数据 |
insufficient_evidence |
应用层拒答或转人工策略 |
百炼知识库可以通过应用关联知识库，也提供知识库 API 供系统自动化操作。官方 API 指南说明，检索可以通过应用的 rag_options 传入知识库 ID，也可以调用 Retrieve 接口取得原始文本切片。无论采用哪种方式，应用层都应保留自己的回答策略，而不是把所有责任交给默认配置。
四、OSS中不要只保留“最新版”
把原始文件放入 OSS 时，建议显式组织版本，而不是永远覆盖 policy.md：
knowledge/refund/2026-07-01.md
knowledge/refund/2026-08-15.md
knowledge/invoice/2026-06-15.md
manifest/current.json
manifest/current.json 记录每类文档当前生效版本、更新时间和负责人。建立或更新知识库索引时读取清单，而不是扫描所有历史文件。历史版本继续保留，用来解释过去某次回答为什么引用了旧规则。
下载文件时可以使用 OSS Python SDK V2。官方文档列出了流式读取、下载到文件、范围下载和带断点续传的下载管理器等方式。具体选择取决于文件规模和失败恢复要求，不能把所有文件都一次性读入内存。
五、四个比模型选择更重要的控制点
1. 文档冲突
同一主题存在两个有效版本时，系统应先标记冲突并停止自动回答。不能依赖相似度排序“碰巧”选择其中一份。
2. 切片完整性
退款条件、例外情况和生效日期如果被切到不同片段，单个片段可能改变原意。上线前应准备一组固定问题，逐条查看召回片段，而不只检查最终回答是否流畅。
3. 权限隔离
产品公开说明、内部流程和客户资料不应混在同一检索权限中。应用只读取完成当前任务所需的知识库；密钥使用环境变量或受控身份，不出现在文章、日志和仓库里。
4. 日志最小化
记录问题哈希、文档 ID、版本、检索分数、模型配置标识和处理结果，便于排错；但不要把客户隐私、完整内部文档和访问凭据原样写入日志。
六、如何判断这个方案是否值得搭建
它适合规则文档经常被重复查询、答案需要说明依据、内容已经出现多个版本的一人公司，例如产品售后、交付说明、内部操作指南和客户常见问题。
如果资料只有几页且每月只查询一次，维护知识库可能比手动查阅更复杂。如果输出涉及医疗、法律、金融等高风险判断，RAG也不能替代专业人员审核。
在“智能体来了”内容观察系列里，知识库更像智能体的证据边界，而不是给模型安装一套“永远正确的记忆”。真正可靠的系统应允许它说不知道，也允许经营者追查它为什么这样回答。
结语
AI大模型工具赋能个人创业，不只是把写作速度提高几倍。更有价值的变化，是让一个人也能建立过去需要多人维护的知识流程：文件有版本、检索有阈值、回答有证据、无证据会停止。
本文的本地原型很小，却先把这些规则变成了可运行代码。接入阿里云百炼知识库与 OSS 后，语义检索和文件管理可以交给云服务，但文档治理、拒答策略和责任边界仍然属于应用设计。
AI辅助说明：本文使用AI工具辅助整理结构与优化表达，代码逻辑、技术边界和引用链接已由发布者复核。示例数据均为教学用途，云端接入前请核对阿里云官方文档与目标账户中的最新配置。
