能回答您内部文档的聊天助手——并标注来源。

答案锚定在您自己的数据上，来源可见。在您既有的文档与历史记录之上做检索增强生成（RAG）。

一个能就您的合同、作业规程、故障历史或产品目录作答的助手。每条回答都附带其出处文档，让阅读的人可以去核实，而不是只能选择相信。

没有出处的回答，问题在哪

通用语言模型对任何问题都用同样的笃定语气作答，不论它是否真的知道。在闲聊里这只是让人不快；而在有人要依据这条回答去行动的场景里，它是一种运营风险。

解决办法不是换更大的模型，而是限定模型可以引用的来源，并强制它标明所述内容的出处。

我们如何构建

• 入库。文档、表格、邮件或系统日志被切分为可检索的单元，每一个单元都保留其来源。
• 检索。问题去寻找相关片段，只有这些片段进入模型。不在库中的内容，不会出现在回答里。
• 强制引用。回答须标明所用文档。没有来源，就没有回答。
• 权限。检索遵守「谁能看什么」的既有规则。两位权限不同的员工，对同一个问题会得到不同的回答——这正是应有的结果。
• 置信阈值。当检索找不到充分依据时，系统会回答「不知道」，而不是编造。

您将获得

• 把助手嵌入团队本来就在用的地方——内网、内部系统、Teams 或 API。
• 使用看板：高频问题、缺乏充分来源的回答占比，以及分期成本。
• 知识库的更新机制，避免内容在无人察觉中过时。
• 问答的完整日志，既用于审计，也用于以真实数据持续改进系统。

关于数据隐私

我们在一开始就界定：什么可以离开您的基础设施，什么不可以。有些情形必须使用私有部署的模型，另一些情形下，签有「不留存数据」条款的商用 API 就已足够。决定权在您，并且是在知情的前提下；架构的设计原则是——更换模型不需要重写系统。

常见问题

我们的文档会被用于训练模型吗？

不会。知识库只在提问的那一刻被检索，不用于训练。若采用商用 API，我们会签订不留存数据的服务模式。

需要多少份文档才够？

几十份即可开始运行。比数量更重要的是：内容是最新的，并且能分清哪一版才作数。

如果助手答错了怎么办？

每条回答都可追溯到来源，因此错误是可诊断的：要么来源本身有误，要么检索取回了错误的片段。两者都能修正。这正是它与「无出处回答」的根本区别。

← 全部服务