# TorchV Bot：一款真正能落地使用的RAG问答机器人 下面的内容主要分为： - TorchV Bot产品介绍 - 如何试用？ - 附录1：RAG简要说明 - 附录2：TorchV Bot操作说明 ## 一、TorchV Bot介绍 ### 1.1 TorchV Bot是什么？ TorchV Bot到底是什么？它是一款基于大语言模型（LLM）和检索增强生成（RAG）技术的人工智能问答机器人，属于TorchV旗下三款主要产品（Bot、Assistant和Analyst）中的一员。 简单来说，它的核心价值其实特别朴素：**把你业务中积累的各种文档扔进去，就能快速搭建出一个知识库和问答系统。这个系统可以对外当客服机器人用，也可以对内当业务助理用**。 TorchV Bot的背后是TorchV RAG中间件系统。从整体架构来看，大致是这样的：

整个架构从下往上可以分为几层： - **大语言模型（LLMs）**：默认采用在线大模型（API调用）或本地LLMs。考虑到OpenAI的ChatGPT、Anthropic的Claude等存在政策风险，面向国内市场客户时一律采用国产LLMs，比如通义千问（QWen-72B/14B）、百川（Baichuan2-13B/52B）、智谱（ChatGLM3-6B/ChatGLM-Turbo/ChatGLM4）等。特定业务场景下也会选用Deep-Seek、InterLM这类偏专业能力的大模型。如果需要本地化部署，通常会选取参数量更小的模型，或者采用类似MoE形式的多个LLMs混搭。 - **中间件层**：包括TorchV RAG和其他中间件，作用下文会具体展开。这一层的核心价值是帮助应用更好地利用LLMs的能力——减少幻觉、提高时效性、保障数据安全，同时提供更好的交互方式和更经济的推理成本。 - **基线产品**：TorchV Bot就是现有三款基线产品之一，功能完整，可以直接用于各种应用场景。这次的试用平台属于TorchV Bot的Beta 1版本，与具体业务无关，是一个通用产品。具体介绍和操作说明后面会详细讲。 - **业务应用**：基于TorchV Bot产品基线，可以结合不同业务类型和场景开发各种具体应用。比如加上名片应用就变成了“产业招商数字名片”；加上工业操作和检修标准手册知识，就成了工业专家机器人。应用场景非常丰富，目前TorchV已经有落地案例或正在开展合作的行业类型已达9类。 TorchV Bot是基于LLM和RAG的。为了让大家更容易理解，这里先介绍一下RAG。如果你已经对RAG很熟悉了，可以直接跳过1.2章节。 ### 1.2 RAG RAG（Retrieval-Augmented Generation，检索增强生成）简单来说，就是给大语言模型（LLMs）提供从数据源检索到的信息，然后基于这些信息生成回答。更直白一点，RAG把搜索技术和LLM的提示功能结合在了一起——模型根据搜索算法找到的信息作为上下文来回答问题。无论是用户的查询还是检索回来的上下文，都会被整合到发给LLM的提示中，然后让LLM根据这些事实内容进行润色输出。 2023年大语言模型逐渐火热之后，基于RAG架构的系统成了最受欢迎的技术路线。很多产品都依赖RAG架构，包括结合网络搜索引擎和LLM的问答服务，以及数以百计的数据交互应用程序。 #### **RAG的优势** RAG结合大语言模型使用，能有效解决LLM本身存在的三个核心问题： - **数据时效性问题**：RAG可以根据用户上传的最新知识，快速提升系统的知识时效性。传统LLMs要解决这个问题，需要进行成本高企的全量训练或微调。 - **幻觉问题**：LLM在面对用户行业知识匮乏的时候，容易出现幻觉。RAG可以基于给定内容进行检索，降低最终输出的幻觉风险。TorchV Bot还提供了系统级参数控制，甚至在检索召回内容质量不高的情况下，可以直接让系统回复“不知道”，不让LLM介入。 - **数据安全问题**：对于数据安全要求极高的企业用户，如果不想使用在线大语言模型，完全可以采用完全本地化部署。RAG可以极大降低对LLM的要求，配合百亿级别参数的可本地部署大模型，就能提供绝大多数AI服务，还能确保企业数据不出内网。 #### **RAG简要介绍** 关于RAG的技术实现细节，可以参看附录1。 ### 1.3 其他中间件 除了RAG，架构中还用了多个中间件，比如幂等分类器（IC）、执行器（Actuator）和连接器（Connector）。简单说一下它们的作用： - **幂等分类器（IC）**：它的作用是理解用户输入内容，把输入中的实体（entity）、时间段和意图（涉及行业分类、多学科分类等）进行识别，提前做路由判断，帮助检索系统找到更准确的内容。它能帮RAG系统过滤掉绝大部分干扰信息，加入更准确的辅助信息，从而帮助LLM减少幻觉。TorchV IC目前还处于开发的早期阶段。 - **执行器（Actuator）**：LLM生成的代码，特别是CSS等，会出现随机现象。执行器在执行过程中会加入全局样式，保证输出风格尽量统一。 - **连接器（Connector）**：只需要把文件目录、数据库链接、内部API等配置好，就能让本地数据在使用时自动完成格式转换和数据抽取，实现数据格式统一。后台还提供了清晰的UI界面，用户可以自行管理内部数据绑定。 ### 1.4 有哪些值得说道的特性？ #### 1.4.1 开箱即用 TorchV Bot的第一个特点是开箱即用。这里面其实有两层意思： - **开户即用**：开通TorchV Bot账号，马上就能开始使用。LLM+RAG整套架构的技术环节非常多，难点也不少。行业内大部分研发人员的感受是“入门简单，精通很难”。真正要实现生产级别的使用，不是搭一个RAG框架就能解决的，尤其是像我们这样采用国产LLM的就更少了。使用TorchV Bot，用户完全不需要关心技术细节、优化迭代和服务器问题。 - **无需维护**：传统NLP机器人最让人头疼的就是知识库维护。工作人员需要先理解内容，再抽取问答对（或FAQ），然后入库测试。更大的工作量还在后面——相似问法的匹配。比如你已经维护了“哪里有厕所？”这个问题和答案，用户如果问“哪里有WC？”、“哪里有洗手间？”，甚至有人问“茅坑在哪里？”，传统系统就无法理解了。这时候需要去维护各种相似问法，过程非常繁琐，即便维护了行业意图包也很麻烦。而基于LLM+RAG的TorchV Bot理解能力非常强，BM25（关键词检索）+ 语义检索（相近含义检索）+ LLM回复的组合，让Bot的理解能力至少能达到普通人类的水平。 开通即用、无需维护就能达到生产应用级别——这两个特点决定了TorchV Bot会越来越适合各种行业应用场景。 #### 1.4.2 访问权限控制 对于企业应用，即使是内部使用，一些敏感文件内容依然需要保密。比如销售报表，最好只能让总经理、销售本人和财务人员看到。如果直接放在LLM中，实习生也能问“我要看一下XX部门今年的销售数据”并得到答案。而TorchV Bot可以通过建立受保护的文件夹来有效设置访问权限。当然，这个特性目前仅在企业版中提供。 #### 1.4.3 高精确度 这其实是基本条件。TorchV Bot在这些方面已经获得了现有客户的认可。 我们没有做任何标准评测，以后应该也不会去参加各种评测。原因很简单——在我们接触的行业客户中，他们的提问我们都很难完全看懂，更别提判断输出答案是否优秀了。目前的反馈都来自约9个类型行业的真实客户使用反馈。客户试用之后的签约就是最好的证明，尤其是通过PLG来的客户。 #### 1.4.4 支持全量私有化 对于数据敏感的服务，比如涉及企业经营数据、合同、工艺流程等知识内容的场景，通常需要全量私有化部署，可以断开外网在企业内部使用。TorchV Bot支持全量部署，包括国产大语言模型（会配合客户申请Model的商用授权）、全套RAG架构以及应用。 #### 1.4.5 轻松扩展“+AI” TorchV Bot从标准版开始就支持API开放。客户可以使用API与自己的原有业务对接，包括小程序、HTML、APP、大屏数字人和具身机器人等。我们也在开发一键嵌入功能，很快就能让客户用极少的几行代码把TorchV Bot应用嵌入集成为原系统的一部分。 #### 1.4.6 配置灵活 系统后台配备了各类参数调整的界面，管理人员可以轻松调整参数。比如在专业性较强的应用场景，可以把alpha参数偏向于BM25；在通用场景下，让KNN的权重更大。关于大家关心的幻觉问题，我们可以设置系统在召回得分低于某个阈值时的回应方式——让LLM兜底回答，还是回复“据已有知识，暂时无法回答您的问题！” ## 二、如何试用？ 已经有部分朋友获得了试用地址和账号。原本打算在官网发布，但研发人员都在忙着TorchV Bot试用系统的上线。 **所以，本次先采用邮件方式。** ### 2.1 给我们发邮件吧 目前只接受**企业用户**试用，需要填写一些必要信息： - 邮箱：用来接收地址和账号 - 如何称呼您 - 所服务的公司 - 您的职位 当然，如果你能告诉我们你的使用场景，我们会更加感激！ ### 2.2 声明 你可以查看附录2了解TorchV Bot的使用说明。 目前TorchV Bot还处于Beta 1阶段，新版UI设计稿还在路上，预计Beta 2版本会换装。系统应该还存在一些未发现的问题，也希望大家在试用过程中不吝指出。 ### 2.3 合作方式 新的创新 = 新技术 + 业务需求。我们期望与各行业的朋友交流AI如何帮助企业提升业务。 最希望能帮助实现的是： - 提升商业收入——增加收入永远是第一位 - 极大降低业务成本，让利润增加——节流同样重要 - 共同开展创新业务，尝试以前不能实现的想法 ## 附录1：RAG简要介绍 #### 1. 数据索引（Index） **数据提取** - 数据清洗：包括数据Loader，提取PDF、word、markdown以及结构化的数据库数据和API数据等 - 数据处理：包括数据格式处理，不可识别内容的剔除，压缩和格式化等 - 元数据提取：提取文件名、时间、章节title、图片alt等信息——这一步非常关键 **分块（Chunking）** 取决于你的索引类型，包括文本类型和长度——文章和微博推文的分块方式就很不一样。 取决于你的模型类型：使用不同的LLM会影响分块策略，因为ChatGLM、ChatGPT和Claude.ai等的tokens限制长度不一样，直接影响分块的尺寸。 取决于问答文本的长度和复杂度：最好问答文本长度和分块尺寸差不多，这样对检索效率更友好。 应用类型：RAG应用是用于检索、问答还是摘要等，都会影响分块策略。 分块方式主要包括： - 句分割：最简单的方式是通过句号和换行做切分。也有通过专业意图包来切分的，常用的有基于NLP的NLTK和spaCy - 递归分割：通过分治的方法，用递归切分到最小单元 - 特殊分割：还有一些不常见的特殊场景分割方式 - 固定大小的分块方式：一般是256/512个tokens，取决于embedding模型的情况。但这种方式会损失不少语义，比如“我们今天晚上应该去吃个大餐庆祝一下”，可能被分成“我们今天晚上应该”和“去吃个大餐庆祝一下”两个chunk。解决方法是在512tokens的chunk中实际只保存480tokens，一头一尾去保存相邻chunk头尾的内容 - 基于意图的分块方式 **向量化（Embedding）** 这是把文本、图像、音频和视频等转化为向量矩阵的过程，让计算机能够理解。embedding模型的好坏直接影响检索质量，特别是相关度。目前常用的中文embedding模型有： - **BGE**：国人开发的中文embedding模型，在HuggingFace的MTEB上排名前2，实力强劲 - **Jina AI**：也是国人开发的中文embedding模型，在未正式发布前就给到我们团队测试过，总体很不错，还提供8K的长度 - **M3E**：同样是国人开发的中文embedding模型，之前用过，后来逐渐不太用了（维度偏低），不过某些场景下依然很适用 - **通义千问的embedding模型**：目前相对最好的商用国产embedding模型之一 - **Text-embedding-ada-002**：OpenAI的embedding模型，1536维，应该是目前最好的模型，但在国内基本用不了 - **自己训练embedding模型**：基于既有embedding模型进行优化，一般能让性能提升3%-10% #### 2. 检索环节（Retriever） 检索环节技术含量很高，一般包含以下几部分工作： **元数据过滤**：当索引被分成许多chunks时，检索效率会成为问题。通过元数据先进行过滤，能大大提升效率和相关度。比如问“帮我整理一下XX部门今年5月份的所有合同中，包含XX设备采购的合同有哪些？”——如果有元数据，就可以搜索“XX部门+2023年5月”的相关数据，检索量可能一下子变成全局的万分之一。 **图关系检索**：把实体变成node，它们之间的关系变成relation，利用知识之间的关系做更准确的回答。特别适合多跳问题，用图数据索引会让检索相关度更高。 **检索技术**：主要的检索方式包括： - 相似度检索：基本上应用六种相似度算法（欧氏距离、曼哈顿距离、余弦、切比雪夫距离、闵式距离、汉明距离），最通用的是余弦相似度检索 - 关键词检索：很传统的方式，但有时候也很重要。除了元数据过滤，还可以先把chunk做摘要，再通过关键词检索找到可能相关的chunk，增加检索效率 - SQL检索：传统方式，对于本地化企业应用来说是必不可少的一步，比如前面提到的销售数据查询 其他检索技术还有很多。 **重排序（ReRank）**：很多时候检索结果并不理想，因为chunks在系统中数量很多，系统为了效率会牺牲部分精确度。这时候需要一些策略对检索结果做重排序，比如使用Bge-Rerank模型，得到更符合业务场景的排序。这一步之后的结果会直接送给LLM进行最终处理，所以非常重要。 **查询轮换**：查询检索的方式，一般包括： - 子查询：在不同场景中使用各种查询策略，比如用LlamaIndex等框架提供的查询器，采用树查询（从叶子结点一步步查询、合并）、向量查询，或者最原始的顺序查询chunks - HyDE：一种生成相似或更标准prompt模板的方式 #### 3. 生成（Generation） 这一环最重要的是Prompt工程，很多因素决定最终输出质量： **Instruction优化**：检索召回的内容是与任务目标最匹配的文本块和结构化数据，需要被有效整合优化并最终输出。给LLM更多Instruction（指令），可以让最终输出质量更优。常用的指令优化方式包括角色带入（比如告诉LLM，它是一个英语专业八级的翻译家）、few-shot（小样本学习，给LLM举几个例子让它学着做）等。 **Prompt压缩**：Context（上下文）窗口指每次与LLM的交互长度。目前所有LLM的上下文窗口都有tokens限制，即使号称200K的GPT-4 Turbo，在输入超过一定数量（一般是72K左右）时依然会出现严重遗忘。所以prompt工程中还要做prompt压缩——剔除无效tokens，凸显关键段落，压缩整体长度。 **专家LLMs选择**：排除OpenAI的GPT-4之外，国产LLM各有不同能力优势。即使总分最低的LLM，也会在某些能力上表现出色。所以生成阶段会根据任务特点选择不同的LLM。不过本地化场景下，一般不会进行多LLM部署和选择。

以上就是RAG的技术解释。 ## 附录2：TorchV Bot操作说明 ### 一、Getting Start #### 登录

使用回复邮件中的地址和账号密码即可登录。 #### 知识维护 **知识库** 先排除各种理论知识，快速上手。登录成功后，点击“知识管理”→“知识维护”，会看到如下界面。

你可能登录后看到的内容会有差异，比如还没有任何文件。这时候点击右上角的“新建”先创建一个知识库，文档内容可以稍后上传。Beta 2版本中知识库可以进行管理，可以选择失效和生效，在知识库灰度升级时会很有帮助。 **内容上传** 新建知识库后，点击右上角的“快捷导入”上传文档（支持pdf、txt、markdown、word、excel和html格式）。 “知识导入”按钮会有一个下拉菜单，包括本地文件、WEB网页、纯文本和更多。“新建文件夹”用于文件分类，在高级版本中也会具备权限功能。 默认文件的有效时间是“永久有效”，当然也可以设定失效时间。

**数据清洗**

文件上传过程中可以设置失效时间，以及文件内容提取的解析预览（前10页）。 Beta 2版本会增加元数据标记功能，让用户可以填写元数据，比如文件内容的发布时间、所属部门等，另外也可以进行预览内容的修订。 选择确定，进入文件处理过程。 **文件处理时间** 文件上传限制大小为10MB，上传速度会比较快。但需要耐心等待一会儿，因为系统需要对文件进行处理。状态一栏会显示处理状态，如“待处理”、“处理中”和“处理成功”。处理大概持续1-3分钟。 #### 知识问答

点击“知识管理”→“问答对话”，对已经处理成功的文档内容进行问答。 需要注意：新建聊天（会话）后，同一个会话里会有上下文记录（实现多轮问答）。如果需要提上下文无关的新问题，可以新建聊天进行提问。

左下角是保存会话截图和清空会话的按钮。 默认情况下，**知识维护**和**知识问答**功能已经可以满足试用需求。如果需要进一步了解TorchV Bot的其他功能，请继续往下阅读。 ### 二、重要配置 #### Prompt管理

这是整个系统中最难的一部分，**默认情况下不建议自行调整！** **prompt编写**

这是RAG的最后一步——把内容提交给LLM处理。 默认情况下不建议调整。对绝大多数用户来说，这里推荐的仅仅是最上面指令内容（Instruction）的修改。比如可以设置大模型的角色，以及给大模型提一些对齐（Alignment）的要求。而“已知内容：${context}”和“问题：${question}”等内容，不建议非技术人员擅自改动。 **参数配置**

以上参数可以分为4组： - 问答库参数 - 知识库（RAG）参数 - 兜底回复方式选择 - 多轮对话参数 参数的基本含义可以查看每个参数的tips（问号标识）和上图的示意。 对于绝大多数用户，主要需要调整的是“**根据已上传知识库无法回复时**”的回复模式：自定义回复，还是大模型兜底？ - 自定义回复：可以自定义下方的“回复内容”，当根据已上传知识库无法回复时，让它据实回答——不知道 - LLM辅助回答：当根据已上传知识库无法回复时，直接把用户提问交给大模型回复 需要特别注意：大模型回复可能出现幻觉，有一定几率误导观众，请不要在严肃场景下使用。 这里的“根据已上传知识库无法回复时”，指的是根据用户的提问，所有召回的索引置信度均低于`kms`值。 反之，如果召回的索引置信度有≥`kms`值的，则下面的回复方式、回复内容不生效。 ### 三、知识运营 #### 对话记录

查看完整的对话记录。可以按用户ID查询所有对话，按时间段查询对话。 #### 反馈处理

用户对回复的评价。 #### 导航管理

导航管理目前仅针对微信小程序端首页体现的快捷语，后续会增加各端导航语的支持。