理论

前戏 前文, 我们使用ollama离线部署了一个qwen-5b模型, 今天我们对RAG一些名词进行系统解释, 白话文解释, 再也不用懵逼了。 RAG是Retrieval-Augmented Generation的缩写, 中文意思是检索增强生成, 顾名思义, 没啥争议。 举个不恰当的例子, 想象你在写一篇关于小狗的文章, 但你对小狗的知识有限。RAG就像你使用搜索引擎查找关于小狗的信息, 然后将这些信息作为参考资料,来帮助你写出更全面的文章。至于增强的过程, 就是你通过整理这些参考资料, 去掉一些没用的, 甚至可能还会返回去图书馆找资料, 只为了给你的读者具象化地讲解, 最好是图文并茂。至于生成, 就是把检索增强后的文档丢给大模型, 然后由大模型回答问题。 除了这三个大概念外, 其实还有些预处理过程, 也是必不可少的优化手段。 我们按照顺序一一厘清, 尽可能覆盖所有的细节。 预处理 预处理是指用户输入和知识库构建的过程。可能涉及到的一些步骤如下。 数据清理 数据清理是RAG中一个重要的步骤, 它包括对原始数据进行预处理, 包括文本清理、实体识别、实体链接等。 分块 在 RAG 系统中, “分块”(Chunking)是指将长文本或文档分割成更小、更易于管理和处理的片段或块的过程。分块有利于提高检索效率, 改善上下文管理, 增强检索相关性。 以下是分块的一些优化手段： 固定大小分块(Fixed-size Chunking): 将文档分割成等长的块, 每个块包含固定数量的单词或字符。 结构化分块(Structured Chunking)：根据文档的结构(如段落、标题、句子)来分割文档。 上下文丰富的分块(Context-rich Chunking)：在分块时, 保留一些额外的上下文信息, 以便每个块都能提供足够的信息。确定合适的重叠量, 以便在块之间保持上下文的连贯性。 语义分块(Semantic Chunking): 基于文本的语义内容来分割文档, 确保每个块包含相关的概念或主题。使用 NLP 技术(如主题建模)来识别和分割语义上连贯的段落。 多模态分块(Multimodal Chunking)对于包含多种类型内容(文本、图像、视频)的文档, 采用适合不同模态的分块策略。为每种内容类型定制分块方法, 以保留各自的语义信息。 … 知识库构建 知识库是RAG的核心, 它包含所有与用户需求相关的信息, 如文档、问题、实体等。 实体识别和链接: 在文本中识别出实体(如人名、地点、组织等), 并将它们与知识库中的相应条目链接起来。 知识提取: 从文本中提取结构化信息, 如事实、关系和概念, 并将它们存储在知识库中。 知识表示和存储: 选择合适的数据模型来表示知识, 如语义网络、图数据库、向量数据库等。 索引构建: 为知识库中的数据构建索引, 以加快检索速度。 检索分类器 确定哪些请求是否要走检索, 大模型的知识储备是否已经足够。如果已经足够, 直接跳过检索, 避免频繁的检索导致性能下降。 ...

前戏 老花: 话接上回, 我们今天总结下MongoDB分片集群部署模式下, 需要注意一些地方。 分布式全量备份和恢复实践 首先, 明确一点, mongdump/mongorestore支持热备份和热恢复。 为了提升备份工作流的并发性能, 我们可以将命令改为多个shard同时后台下发, 那么如何确保这些备份任务及时下发和反馈进度呢? 我们可以引入一个管控面, 这可以是一个组件暴露成接口, 也可以是k8s上的一个job或者cronjob, 定时去执行。 不管怎么说, 它理论上应该有这些功能: 异步下发指令。 监控指令完成。 执行下一个指令。 最终返回备份成功或者失败的状态, 以及一些其他附加信息。 我们把这个流程画成时序图。 全备时序图 主要步骤: 管控系统遍历每个Shard查找主节点：管控系统首先需要确定每个分片（Shard）的主节点。 并行执行mongodump异步命令：对于每个Shard，管控系统并行执行mongodump命令来备份数据。这里需要进行二次封装，确保每次执行后都能写入一个本地的status文件，记录备份的成功或失败状态。 轮询每个Shard上的状态文件：管控系统需要轮询每个Shard上的状态文件，检查备份是否成功。如果所有Shard都返回成功，则备份成功；如果存在失败或文件不存在，则需要继续轮询。 完成Shard备份后执行Configsvr备份：一旦所有Shard的备份都成功完成，管控系统将开始备份Configsvr。这同样需要查找Configsvr的主节点，然后执行备份。 Configsvr备份结果：Configsvr备份完成后，管控系统将收到备份结果，完成整个备份流程。 由此可见, 封装mongodump后的需要附加以下功能: 对接不同的灾备产品, 比如oss 对备份进行切分, 将备份上传到存储系统 上传备份数据到远程存储 全量恢复时序图 主要步骤: 管控系统遍历每个Shard查找主节点：管控系统首先需要确定每个分片（Shard）的主节点。 主节点上下载远程的存储文件：管控系统从远程存储下载备份文件。 重命名本地存储或发起本地备份：管控系统将下载的文件重命名或备份到本地存储，以便在恢复程序报错时支持数据回滚。 并行执行mongorestore异步命令：对于每个Shard，管控系统并行执行mongorestore命令来恢复数据。这里需要进行二次封装，确保每次执行后都能写入一个本地的status文件，记录恢复的成功或失败状态。 轮询每个Shard上的状态文件：管控系统需要轮询每个Shard上的状态文件，检查恢复是否成功。如果所有Shard都返回成功，则恢复成功；如果存在失败或文件不存在，则需要继续轮询。 完成Shard恢复后执行Configsvr恢复：一旦所有Shard的恢复都成功完成，管控系统将开始恢复Configsvr。这同样需要查找Configsvr的主节点，然后执行恢复。 Configsvr恢复结果：Configsvr恢复完成后，管控系统将收到恢复结果，完成整个恢复流程。 上面的时序新增了远程存储, 但是恢复的时候需要先下载到容器中, 可能导致数据有可能的三份膨胀: 下载到本地的远程的备份 本节点的原有备份数据 恢复过程中的数据 除了数据膨胀, 如果原先孵化pod的pvc存储不够, 可能会直接导致失败。 可能有人会这样想: 直接把本地数据删除, 然后远程下载解压不香吗? 还有人这样想, 我直接搞个新集群, 恢复完了, 再重命名回来? 第一个问题, 可以是可以, 但是服务就相当于宕机了, 而且恢复失败, 回滚也是比较费事了。第二个问题呢, 云原生里面的设计, 多租户隔离比较常见的, 可能这么操作比较不优雅。 ...

前戏 小白: 嘿，老花，我最近在研究 MongoDB 的日志系统，你能给我介绍一下 MongoDB 有哪些日志吗？ 老花: 当然可以，小白。MongoDB 主要有四种日志：系统日志、Journal 日志、主从日志（oplog）和慢查询日志 。让我一一解释给你听。 首先, 我们看下不同组件的配置文件描述信息。 不同组件的配置文件 shardsvr 下面我们演示从之前部署的集群上获取一个数据节点shardsvr的启动配置: $ kubectl -n mongodb-sharded exec -it mongodb-sharded-shard0-data-0 -- bash $ ps -ef UID PID PPID C STIME TTY TIME CMD 1001 1 0 2 Nov30 ? 00:46:47 /opt/bitnami/mongodb/bin/mongod --config=/opt/bitnami/mongodb/conf/mongodb.conf $ cat /opt/bitnami/mongodb/conf/mongodb.conf # mongod.conf # for documentation of all options, see: # http://docs.mongodb.org/manual/reference/configuration-options/ # where and how to store data. storage: dbPath: /bitnami/mongodb/data/db directoryPerDB: false # where to write logging data. systemLog: destination: file quiet: false logAppend: true logRotate: reopen path: /opt/bitnami/mongodb/logs/mongodb.log verbosity: 0 # network interfaces net: port: 27017 unixDomainSocket: enabled: true pathPrefix: /opt/bitnami/mongodb/tmp ipv6: false bindIpAll: true #bindIp: # replica set options replication: replSetName: mongodb-sharded-shard-0 enableMajorityReadConcern: true # sharding options sharding: clusterRole: shardsvr # process management options processManagement: fork: false pidFilePath: /opt/bitnami/mongodb/tmp/mongodb.pid # set parameter options setParameter: enableLocalhostAuthBypass: false # security options security: authorization: enabled keyFile: /opt/bitnami/mongodb/conf/keyfile 这个 MongoDB 配置文件包含了多个部分，每个部分都用于设置 MongoDB 实例的不同配置选项。以下是对每个部分的详细分析： ...

前戏 小白：嗨，老花，我听说 MongoDB 挺火的，但我对它不是很了解。你能给我讲讲 MongoDB 是啥，它和 MySQL 这样的 SQL 数据库有啥不同吗？ 老花：当然可以！MongoDB 是一种 NoSQL 数据库，它以文档存储的形式存储数据，这使得它在处理大量半结构化数据时非常灵活和高效。与 MySQL 这样的关系型数据库相比，MongoDB 不需要预定义的模式，支持动态字段，这对于快速发展和频繁变更的数据模型来说是一个很大的优势。 以下是 MySQL 和 MongoDB 进行增删改查操作的基本 SQL 语句和命令的对比： MySQL CRUD INSERT INTO table_name (column1, column2, column3, ...) VALUES (value1, value2, value3, ...); DELETE FROM table_name WHERE condition; UPDATE table_name SET column1 = value1, column2 = value2, ... WHERE condition; SELECT column1, column2, ... FROM table_name WHERE condition; MongoDB CRUD db.collection_name.insert({ field1: value1, field2: value2, field3: value3, ... }); db.collection_name.insertMany([ { field1: value1, field2: value2, field3: value3, ... }, { field1: value1, field2: value2, field3: value3, ... }, ... ]); db.collection_name.remove({ condition: value }); db.collection_name.deleteMany({ condition: value }); db.collection_name.update( { <filter> }, { $set: { <field1>: <value1>, <field2>: <value2>, ... } }, { multi: <boolean> } ); db.collection_name.find({ field: value }); 在 MongoDB 中，<filter> 是查询条件，<field1> 和 <value1> 是要更新的字段和值，multi 参数是一个布尔值，如果设置为 true，则更新所有匹配的文档，否则只更新第一个匹配的文档。 ...