基于贵方数据的 AI

本服务包含哪些内容

我们打造一个 AI 助手，它能基于贵公司的企业文档、知识库、规章制度和往来邮件存档来回答问题。「基于贵方数据的 AI」这项服务指的是一个完整闭环：采集并清洗数据源、把文本切成片段、构建向量索引、接入大模型，以及供员工使用的网页界面或机器人。我们编写程序部分、配置数据处理流水线，而不是兜售一个装着别人内容的现成产品。如果业务闭环中有客户的设备——服务器、GPU 工作站或操作员工位——我们针对这些硬件准备软件和配置，但设备本身仍归您所有、在您一侧物理运行。最终您得到的是一套用您文件中的事实作答、而非从互联网搬来泛泛之词的系统。

RAG 的本质如何运作

其核心是 RAG（检索增强生成）方案——以检索到的文档为依据来生成回答。首先，您的所有文本通过嵌入模型转成数值向量，存入向量库，语义相近的片段在其中彼此相邻。当员工提问时，系统把问题也转成向量，找出几段最相关的文本，连同问题本身一起交给大模型。模型严格依据所提供的片段组织回答，而非它当年从别人数据中学到的内容。这种做法能给出出处链接，并大幅减少事实臆造，因为回答被锚定在您文档的具体段落上。

RAG 的由来

RAG 这一术语和方案于 2020 年在论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》中提出，作者为 Facebook AI Research、伦敦大学学院和纽约大学的帕特里克·刘易斯等人。该论文在 NeurIPS 2020 大会上发表，表明把库检索与生成模型结合，能给出比模型单干更准确、更有事实依据的回答。这一思路立足于更早的向量检索历史：用数值向量表示词语，是在托马什·米科洛夫团队 2013 年于 Google 推出 word2vec 之后才普及的。到 2020 年，嵌入向量和大模型的质量已提升到足以把检索与生成合进一条流水线、并切实可用的程度。如今，正是这套方案构成了大多数基于自有数据的企业助手的根基。

为什么精度至关重要

如果企业助手言之凿凿地给出错误数字、或编造出根本不存在的规章条款，那它就毫无用处。这里的精度不靠模型的魔法，而靠工程化配置：文档如何切分、选用哪个嵌入模型、给上下文喂多少片段、如何剔除不相关内容。隐私同样系于程序部分：「基于贵方数据的 AI」可以把数据留在您的内网、不发往外部服务，并按角色分级授权。流水线里的任何错误都不会立刻显现，因此我们用真实问题把系统跑一遍、在正式上线前核对回答。助手的质量是软件和参数调试的结果，而非一次性安装就能得来。

技术栈与工具

基础技术栈是 RAG、向量库、嵌入向量和大模型（LLM），合成一条流水线。向量库按数据量和部署要求来选：可以是带 pgvector 扩展的 Postgres、用作本地索引的 FAISS，或 Qdrant、Milvus 这类专用存储。嵌入模型和 LLM 本身则在精度、速度和隐私之间权衡选择——从云端 API 到部署在客户设备本地的模型皆可。程序外围封装用 Python 编写，配以用于请求编排、文档处理和回答质量管控的库。技术栈按您的任务来选配，而非反过来：如果数据不能外泄，整条链路都留在您的内网中。

关键工具诞生于何时

现代技术栈源自几个关键日期。词的向量表示在 2013 年 word2vec（米科洛夫等人，Google）之后走向大众。用于向量快速检索的 FAISS 库由 Facebook AI Research 于 2017 年 3 月发布，至今仍被用作本地索引。2017 年 12 月，Transformer 架构随 Google 研究者的论文《Attention Is All You Need》问世；2018 年 10 月，基于它的 BERT 模型发布，嵌入向量和大模型自此具备了切实可用的质量。正是在这些基石之上，RAG 方案于 2020 年成形，我们在本服务中加以应用。

Почему это к нам

我们开发团队的累计经验超过 45 年 IT 资历，对待助手是把它当作一套工程系统，而非一次性演示。我们不生产硬件、也不出售现成机箱——我们编写程序部分、按具体任务配置客户的设备，无论是本地服务器还是您内网中的 GPU 工作站。正式上线前，系统会用您真实的问题接受检验：我们查看每个回答的来源，并在员工开始使用之前修好流水线。「基于贵方数据的 AI」搭建得很透明——您能看到回答的出处，并掌控哪些数据流向何处。这意味着可预期的成效，以及一套可以持续升级、而非一次性安装的系统。