一、TorchV Bot介绍下面的内容主要分为：
TorchV Bot产品介绍； 如何试用？ 附录1：RAG简要说明； 附录2：TorchV Bot操作说明
1.1 TorchV Bot是什么？
TorchV Bot是一款基于大语言模型（Large Language Model，后文简称LLM）和检索增强生成（Retrieval-augmented generation，后文简称RAG）技术的人工智能问答机器人，属于TorchV最主要的三款产品（Bot、Assistant和Analyst）中一款。
在使用方面，TorchV Bot的产品价值最简单总结就是：将您业务中已有的各类文档扔进去，就可以快速形成知识库和问答系统，可以作为对外的客服机器人使用，也可以作为对内的业务助理使用。
TorchV Bot是基于TorchV RAG中间件系统的应用，从整体系统架构来看，具体如下：
在整套架构中，本文提到的TorchV Bot仅仅属于产品层的其中一个产品，下面我们从下往上逐层描述：
大语言模型（LLMs，后面统称LLMs或LLM）：默认采用在线大模型（API调用）或本地LLMs，因为OpenAI的ChatGPT、Anthropic的Claude等存在政策风险，所以本产品在面向国内市场客户时一律采用国产LLMs，常见的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 Bot产品基线，可以结合不同业务类型和场景开发多种具体应用，如加上名片应用之后形成的“产业招商数字名片”应用；加上工业操作和检修标准手册知识之后可以解决工业产业人员的日常工作知识咨询，成为工业专家机器人。应用场景业态丰富，目前TorchV已经有落地案例或正在开展合作的行业类型已达9类。
TorchV Bot是基于LLM和RAG的，为了方便更多朋友进一步了解，这里再介绍一下RAG，如果您对RAG已经了解，可以直接跳过1.2章节。
1.2 RAG
RAG（Retrieval-Augmented Generation，检索增强生成）是为大语言模型 (LLMs) 提供了从数据源检索的信息，以此为基础生成回答。简而言之，RAG结合了搜索技术和大语言模型的提示功能，即模型根据搜索算法找到的信息作为上下文来回答查询问题。无论是查询还是检索的上下文，都会被整合到发给大语言模型的提示中，然后让大语言模型根据召回的事实内容进行润色输出。
在2023年，大语言模型逐渐火热之后，基于RAG架构的大语言模型系统成为最受欢迎的技术。许多产品几乎全依赖RAG架构，这包括结合网络搜索引擎和大语言模型的问答服务，以及数以百计的数据交互应用程序。
RAG的优势
RAG结合大语言模型使用，可以有效解决大语言模型本身存在的三个主要问题：
数据时效性问题：RAG可以根据用户上传的最新知识，将系统的知识时效性快速提升，而传统LLMs则需要进行成本高昂的大模型全(或增)量训练或微调； 幻觉问题：LLMs对于用户行业知识匮乏的时候，会出现常见的幻觉问题。使用RAG可以基于给定内容进行检索，降低最终输出的幻觉。TorchV Bot提供系统级参数控制，甚至可以设置在检索召回内容质量不高的情况下，不让LLMs介入，而是直接回复“不知道”； 数据安全问题：对于数据安全要求极高的企业用户，如果不想使用在线大语言模型（如ChatGPT、通义千问、文心一言等），那么可以采用完全本地化部署。采用RAG可极大降低LLMs要求，配合百亿级别参数的可本地部署大模型即可提供绝大多数AI服务，还让企业数据保不出内网。
RAG简要介绍
关于RAG的简要介绍，特别是技术实现，可以参看附录1.
1.3 其他中间件
除了RAG，架构中还是用了多个中间件，如幂等分类器（IC）、执行器（Actuator）和连接器（Connector），下面简要叙述它们的作用：
幂等分类器（IC）：IC的作用是理解用户输入内容，将输入内容中的实体内容（entity）、时间段和意图（特别涉及到行业分类、多学科分类等）进行识别，提前做路由判断，帮助检索系统找到更准确的内容。帮助RAG系统过滤掉绝大部分信息，加入更准确的辅助信息，帮助RAG系统过滤干扰内容，帮助LLMs减少幻觉。TorchV IC尚属于开发的早期，还有不少工作需要继续迭代； 执行器（Actuator）：根据LLMs生成的代码，特别是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试用系统的上线，而我，来不及将官网（https://www.torchv.com，2024-01-25，也许过几天会上线）开发完成。
所以，本次就先采用邮件吧。
2.1 给我们发邮件吧
目前只接受企业用户试用，需要您填写一些信息，必要信息如下：
邮箱：用来接收地址和账号 如何称呼您： 所服务的公司： 您的职位：
当然，如果您可以告诉我们您的使用场景，我们将更加感激！
对了，可以发送到
另外，也可以直接加我微信（lxdhdgss）联系我。
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的，实际保存480tokens，一头一尾去保存相邻的chunk头尾的tokens内容； 基于意图的分块方式： 影响分块策略的因素： 向量化（Embedding）：这是将文本、图像、音频和视频等转化为向量矩阵的过程，也就是变成计算机可以理解的格式，embedding模型的好坏会直接影响到后面检索的质量，特别是相关度。一般我们现在常用的embedding模型有这些：
BGE：这是国人开发的中文embedding模型，在HuggingFace的MTEB（海量文本Embedding基准）上排名前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检索：传统方式，对于一些本地化的企业应用来说，SQL查询是必不可少的一步，比如前面提到的销售数据，就需要先做SQL检索。 其他：检索技术还有很多。 重排序（ReRank）：很多时候我们的检索结果并不理想，原因是chunks在系统内数量很多，系统为了检索效率会牺牲一部分的精确度，所以一次检索的结果可能就会在相关度上面没有那么理想。这时候我们需要有一些策略来对检索的结果做重排序，比如使用Bge-Rerank模型重排序，得到更符合我们业务场景的排序。因为在这一步之后，我们就会把结果送给LLM进行最终处理了，所以这一部分的结果很重要。
查询轮换：这是查询检索的一种方式，一般会有几种方式：
子查询：可以在不同的场景中使用各种查询策略，比如可以使用LlamaIndex等框架提供的查询器，采用树查询（从叶子结点，一步步查询，合并），采用向量查询，或者最原始的顺序查询chunks等； HyDE：这是一种抄作业的方式，生成相似的或者更标准的prompt模板。
3.生成（Generation）
这一环最重要的就是Prompt工程，在Prompt里有很多决定最终输出质量的因素：
Instruction优化：检索召回的内容仅仅是与任务目标最匹配的文本块（chunk）和结构化数据，它们需要被有效地整合优化并最终输出。这个过程需要通过LLMs进行处理。在输入过程中给LLMs更多Instruction（指令），可以让最终输出的质量更优。常用的指令优化方式有角色带入（如告诉LLMs，他是一个英语专业八级的翻译家）、few-shot（小样本学习，给LLMs举几个例子，让它学着做）等等； Prompt压缩：Context（上下文）窗口是指每次可以和LLMs的交互，目前所有LLMs的上下文窗口都有相应的tokens限制长度，即使号称200K的GPT-4 Turbo等LLMs，在输入tokens超过一定数量（一般是72K左右）时依然会出现严重遗忘的情况。所以在prompt工程中，除了设置角色、给定更多指令等之外，还会进行prompt压缩——剔除无效tokens，凸显关键段落，压缩整体长度； 专家LLMs选择：在排除OpenAI的GPT-4大模型之外，目前已知各类国产LLMs均有各自在不同能力上的优势。在下图（2023年9月的结果）的实际测试中可以发现，即使总分最低的LLM也依然会在某些能力上表现出色。所以，在生成阶段，我们会根据任务特点选择不同LLMs进行最终的生成。需要注意的是，在本地化场景下，一般不会进行多LLMs部署和选择。
以上就是关于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查询所有对话，按时间段查询对话。
反馈处理
用户对回复的评价。
导航管理
导航管理目前仅针对微信小程序端首页体现的快捷语，后续会增加各端导航语的支持。
