企业内部的 RAG 项目往往不缺一个能回答问题的 Demo，真正缺的是文档管理、出处追踪、权限隔离、流式交互、Agent 编排和链路诊断能够同时工作的完整系统。Ollmo v0.1.0 的定位正是这类生产场景：面向私有化部署和团队协作，把 RAG、可视化 Agent、GraphRAG 与可观测能力整合到一个平台中。
从“能检索”走向“答案可核验”
典型 RAG 流程包括文档解析、文本切分、索引构建、召回、重排和答案生成。用户最终看到的可能只是一段回答，但系统质量取决于整条链路是否可靠。
Ollmo 强调答案带有精准出处，这一点对内部知识库尤其重要。员工查询制度、合同、产品手册或故障记录时，模型给出的答案只能作为入口，引用的原始文档和片段才是核验依据。实际验收时，不能只检查“答案读起来是否合理”，还应检查：
- 引用是否确实支持答案中的关键结论；
- 文档更新后，旧索引是否能被替换或失效；
- 无答案时，系统是否会明确拒答，而不是拼接看似合理的内容；
- 用户是否只能看到自己有权访问的引用内容。
内置混合检索意味着平台可以结合不同检索策略处理问题。关键词检索适合产品编号、错误码和专有名词，语义检索则更适合自然语言改写。两者结合通常比单一路线更稳，但仍需要使用真实业务问题调整召回数量、切分粒度和排序策略。
多租户不是界面上的团队下拉框
团队协作场景中的隔离必须贯穿数据链路。租户标识不仅要出现在用户表中，还要进入文档元数据、索引命名空间、检索过滤条件、会话记录、Agent 配置和审计日志。
例如，A 团队上传了一份尚未发布的报价策略，即使 B 团队提出了高度相似的问题，检索阶段也不能召回这份文档。只在生成答案前过滤引用已经太晚，因为敏感内容可能已经进入模型上下文。
评估 Ollmo 的多租户能力时，可以重点验证以下边界：
- 同名文档在不同租户下是否拥有独立索引和生命周期；
- 管理员、成员和只读用户的上传、删除、查询权限是否明确；
- 检索日志和模型调用记录是否携带租户信息；
- 删除租户后，向量数据、对象存储文件和会话记录是否同步清理。
Agent 画布、GraphRAG 与可观测性如何配合
可视化 Agent 画布适合把检索、模型调用、条件判断和外部工具连接成可维护的工作流。它的价值不只是降低编排门槛，更在于让团队能够看到执行路径，并对失败节点进行定位。
GraphRAG 则适合实体关系明显的问题，例如组织架构、供应链、设备依赖或项目关系。普通向量检索擅长找到语义接近的文本，图关系可以补充“谁依赖谁”“某个实体经过哪些节点关联到另一个实体”这类结构化上下文。它并不意味着所有知识库都应立即图谱化：文档规模较小、关系稀疏或数据变化频繁时，构图成本可能高于收益。
全链路可观测能力应该帮助团队回答几个具体问题：一次请求召回了哪些片段、排序分数如何、使用了哪个模型、每个 Agent 节点耗时多久、失败发生在哪一层。没有这些数据，RAG 效果下降时只能反复修改提示词，很难判断问题究竟来自解析、检索还是生成阶段。
用一组冒烟测试验收知识库
下面是一份可以改造的 API 冒烟测试。由于摘要没有给出 Ollmo 的实际接口定义，这里明确假设平台暴露了上传文档和流式提问两个 HTTP 端点。运行前需要根据实际 API 文档修改路径、字段名、鉴权方式和租户请求头。
#!/usr/bin/env bash
set -euo pipefail
BASE_URL="${BASE_URL:-http://localhost:3000}"
TOKEN="${TOKEN:?Set TOKEN before running}"
TENANT_ID="${TENANT_ID:-team-a}"
DOCUMENT="${1:-./handbook.md}"
if [[ ! -f "$DOCUMENT" ]]; then
printf 'Document not found: %s\n' "$DOCUMENT" >&2
exit 1
fi
printf 'Uploading %s...\n' "$DOCUMENT"
curl --fail-with-body --silent --show-error \
-X POST "$BASE_URL/api/documents" \
-H "Authorization: Bearer $TOKEN" \
-H "X-Tenant-ID: $TENANT_ID" \
-F "file=@${DOCUMENT}" \
-F "collection=engineering-handbook"
printf '\nQuerying the collection...\n'
curl --fail-with-body --no-buffer \
-X POST "$BASE_URL/api/chat/stream" \
-H "Authorization: Bearer $TOKEN" \
-H "X-Tenant-ID: $TENANT_ID" \
-H "Content-Type: application/json" \
--data '{
"collection": "engineering-handbook",
"question": "生产事故升级流程是什么？",
"include_citations": true
}'
可以将脚本保存为 smoke-test.sh，准备一份测试文档后执行：
chmod +x smoke-test.sh
TOKEN="replace-with-token" \
TENANT_ID="team-a" \
BASE_URL="https://ollmo.example.internal" \
./smoke-test.sh ./handbook.md
除了检查 HTTP 状态码，还应验证响应中是否包含可打开的引用、流式连接是否会正常结束，以及同一个问题换成另一个租户后是否无法看到原租户的文档。后者是比单纯问答成功更重要的上线门槛。
上线时从一条受控链路开始
Ollmo 后端采用 Go 与 Fiber，前端使用 Next.js App Router 和 shadcn-ui，这套组合适合构建响应式管理界面与流式服务，但技术栈本身并不能替代生产治理。正式接入前仍应确认模型凭据管理、对象存储备份、索引重建、限流、审计和数据删除流程。
更稳妥的落地方式是先选择一个边界明确、文档质量较高的知识库，建立 20 到 50 个带标准答案和预期引用的问题。每次修改切分、检索或模型配置后都重跑这组问题，并记录引用命中率、拒答表现、首字延迟和完整响应耗时。
v0.1.0 已经提供了覆盖 RAG 与 Agent 生产链路的能力组合，但版本号也意味着团队需要保守评估升级兼容性和运维边界。先验证隔离与可追溯性，再扩展知识库数量和 Agent 工作流，通常比一次性接入全部内部数据更可控。