ONLYOFFICE 协作空间 AI 设置深度解析:LLM、联网检索与知识库的技术架构

引言

在企业级文档协作平台中引入大语言模型（LLM），并非简单地"接一个 API"那么简单。一个完整可用的 AI 助手，至少需要三层能力支撑：推理大脑、实时信息源、私有知识库。

ONLYOFFICE 协作空间的「AI 设置」面板恰好将这三层能力拆分为三个独立的配置模块——AI 提供商、网络搜索、知识库——每一个模块背后都对应着 LLM 应用架构中的一个核心技术环节。

本文将从技术原理出发，逐一拆解这三项设置的作用、配置要点与底层逻辑。

一、AI 提供商：为系统提供"计算大脑"

1.1 为什么需要配置 AI 提供商

大语言模型本身是一个庞大的神经网络推理引擎，需要消耗海量的 GPU 算力。对于 ONLYOFFICE 协作空间这类文档协作平台而言，自身并不内置 LLM 的推理能力，而是通过标准的 API 接口对接外部 AI 服务提供商（如 DeepSeek、OpenAI、Claude 等），将用户的自然语言请求转发给远端模型，再将生成结果返回给前端。

因此，AI 提供商的配置本质上是在为整个协作空间的 AI 功能指定"计算大脑"——所有 AI 聊天、文档摘要、智能体对话、文本生成等功能，最终都要调用这里配置的模型来完成推理。

1.2 配置项解读

如图所示，添加 AI 提供商时需要填写以下关键字段：

字段	说明
提供商	选择兼容 OpenAI API 格式的模型服务，如 DeepSeek、OpenRouter 等
名称	自定义标识，便于在多个提供商之间区分
URL	AI 服务的 API 端点地址，例如 `https://api.deepseek.com`
密钥	在 AI 提供商控制台生成的 API Key，用于身份鉴权与计费

配置完成后，还可以在「默认提供商」中指定全局默认使用的模型服务和具体模型（如 Claude Opus 4.8），这样协作空间内所有用户在使用 AI 功能时都会默认调用该模型，无需重复选择。

1.3 技术要点

API 兼容性
：ONLYOFFICE 采用 OpenAI 兼容的 API 协议，这意味着任何提供 OpenAI 格式接口的服务（包括本地部署的 vLLM、Ollama 等）都可以接入，实现私有化部署。
多提供商切换
：支持添加多个 AI 提供商，用户可在不同模型之间切换，兼顾成本与效果。
密钥安全
：API 密钥仅在保存时显示一次，随后被隐藏存储，避免泄露。

二、网络搜索：突破 LLM 的"知识截止日期"

2.1 LLM 为什么不能直接上网

大语言模型的知识来源于训练数据，而训练数据存在一个明确的截止日期（Cutoff Date）。例如，一个在 2024 年训练的模型，对 2025 年发生的事件一无所知。更重要的是，LLM 在推理过程中是一个封闭的自回归生成系统——它只能基于已输入的上下文文本逐 token 生成回复，本身不具备发起 HTTP 请求、访问互联网的能力。

这就导致了一个核心矛盾：用户经常会问"今天的股价是多少""最新的政策文件说了什么"，而纯 LLM 无法回答这类需要实时信息的问题。

2.2 网络搜索设置的作用

网络搜索模块的作用，就是为 LLM 接上一个互联网信息检索接口。ONLYOFFICE 支持对接 Exa 等专业搜索引擎 API，其工作流程如下：

用户向 AI 提出一个需要实时信息的问题；
系统判断该问题需要联网，将用户的查询关键词发送给搜索引擎 API；
搜索引擎返回相关网页的标题、摘要和链接；
系统将这些检索结果作为**上下文（Context）**拼接到 Prompt 中，一起发送给 LLM；
LLM 基于检索到的实时信息生成回答，并附上来源链接。

这种架构在技术上被称为**检索增强生成（Retrieval-Augmented Generation, RAG）**的联网变体——只不过检索源从私有知识库换成了公开互联网。

2.3 配置项解读

字段	说明
网络搜索引擎	选择搜索服务提供商，如 Exa
API 密钥	在搜索服务控制台申请的密钥，用于调用搜索接口

配置完成后，联网检索能力对协作空间内所有用户生效，AI 在回答时可以自动判断是否需要搜索，并引用最新的互联网信息。

2.4 技术要点

搜索即工具
：网络搜索在 LLM 应用架构中属于「工具调用（Tool Calling / Function Calling）」的一种，LLM 自主决定何时调用搜索工具。
时效性补充
：网络搜索弥补了 LLM 训练数据滞后的缺陷，适合回答新闻、政策、行情等时效性强的问题。
来源可追溯
：回答通常会附带信息来源链接，便于用户核实。

三、知识库：向量化存储与私有文档的语义检索

3.1 知识库要解决什么问题

如果说网络搜索解决的是"外部实时信息"的问题，那么知识库解决的就是内部私有文档的问题。

企业在协作空间中积累了大量文档——产品手册、规章制度、项目文档、会议纪要、技术方案等。这些文档包含了企业独有的知识，但 LLM 不可能见过这些私有内容。直接把整篇文档塞进 Prompt 既不现实（受上下文长度限制），也不经济（Token 成本高）。

知识库的核心思路是：将文档向量化后存储，用户提问时只检索最相关的片段，再交给 LLM 生成答案。

3.2 向量化（Embedding）的技术原理

ONLYOFFICE 知识库使用 text-embedding-3-small 模型对文档进行索引。向量化的过程如下：

第一步：文档分块（Chunking） 长文档无法直接向量化，需要先切分为较小的文本块（通常 200-1000 字），分块策略会直接影响检索精度。

第二步：向量编码（Embedding） 将每个文本块输入 Embedding 模型（如 text-embedding-3-small），模型会输出一个高维浮点数向量（例如 1536 维）。这个向量代表了文本的语义特征——语义相近的文本，在向量空间中的距离也更近。

第三步：向量存储 生成的向量连同原始文本块一起存入向量数据库（Vector Database），支持高效的相似度检索。

第四步：语义检索 当用户提问时，系统将用户的问题也用同一个 Embedding 模型向量化，然后在向量数据库中计算问题向量与所有文档块向量之间的余弦相似度（Cosine Similarity），返回 Top-K 个最相关的文档片段。

第五步：增强生成 将检索到的相关文档片段作为上下文拼接到 Prompt 中，LLM 基于这些私有知识生成精准回答。

这就是完整的 RAG（检索增强生成） 流水线，也是知识库功能的技术内核。

3.3 配置项解读

字段	说明
提供商	Embedding 模型的服务提供商，如 OpenRouter
API 密钥	用于调用 Embedding 接口的密钥

需要注意的是，知识库使用的 Embedding 模型（text-embedding-3-small）与 AI 提供商配置的对话生成模型是两个独立的模型——前者负责将文本转为向量，后者负责基于检索结果生成自然语言回答。

3.4 知识库与网络搜索的区别

维度	知识库	网络搜索
信息来源	企业内部私有文档	公开互联网
时效性	文档更新后重新索引	实时检索
检索方式	向量语义检索	关键词/语义搜索 API
适用场景	内部制度、产品文档、项目资料	新闻、政策、外部资讯
数据安全	数据留在企业内部	需将查询发送给第三方搜索服务

3.5 技术要点

Embedding 模型一致性
：文档向量化和查询向量化必须使用同一个模型，否则向量空间不一致，检索结果会失真。
分块策略影响效果
：过大的块会引入噪音，过小的块会丢失上下文，需要根据文档类型调整。
侧重查找而非生成
：知识库功能"侧重于查找相关信息，但不生成摘要或执行全局分析"——这意味着它更适合精准问答，而非长篇综述。
增量索引
：新增文档时只需对新文档向量化并入库，无需重建整个索引。

总结

ONLYOFFICE 协作空间的 AI 设置将 LLM 应用的三大核心能力解耦为三个独立模块，形成了一套完整的技术架构：

AI 提供商
是推理引擎层——通过 API 对接外部大模型，为所有 AI 功能提供计算大脑，决定了"谁来思考"。
网络搜索
是实时信息层——通过搜索引擎 API 突破 LLM 的知识截止限制，让 AI 能够获取互联网最新信息，决定了"能知道什么外部动态"。
知识库
是私有知识层——通过 Embedding 向量化和向量检索（RAG），让 AI 能够基于企业内部文档精准问答，决定了"能理解什么内部知识"。

三者协同工作：AI 提供商负责生成，网络搜索负责外部实时信息，知识库负责内部私有文档，共同构成了一个既懂通用知识、又能查实时信息、还熟悉企业内部资料的完整 AI 助手。对于企业用户而言，正确配置这三项设置，是将 ONLYOFFICE 从一个文档协作工具升级为智能知识平台的关键一步。

企业办公知识库首选-ONLYOFFICE 协作空间 3.7.2 正式发布：AI 智能体全面升级，CAD 图纸预览全新登场