RAGFlow 一、介绍 RAGFlow是一个完整的、开源的RAG（检索增强生成）系统。你可以把它看作一个已经搭建好的智能问答应用框架。 RAGFlow不是一个需要你从零编码的库，而是一个可以直接运行起来的服务。它内置了我们聊过的RAG的完整流程：上传文档 -> 自动解析 -> 切片 -> 调用Embedding模型生成向量 -> 存储 -> 检索 -> 调用大模型生成回答。 RAGFlow 官网 二、搭建一个智能问答系统 整体架构： 你的文档 (PDF/Word/PPT) ↓ [RAGFlow核心] ├─ 深度文档解析 → 保留表格/图片/格式 ├─ 智能分块 → 按语义切割文档 ├─ 向量化 → 调用Embedding模型 └─ 向量存储 → 存入数据库 ↓ 用户提问 → [检索引擎] → [你的微调模型] → 带引用的精准回答 2.1 部署RAGFlow 这里使用 Docker 方式 环境要求： CPU ≥ 4 cores (x86); RAM ≥ 16 GB; Disk ≥ 50 GB; Docker ≥ 24.0.0 & Docker Compose ≥ v2....

向量数据库Qdrant使用 一、什么是向量数据库？ 向量数据库是专门用于存储、管理和检索“向量嵌入（Embedding）”的数据库。 Embedding 的本质： 深度学习模型（如 OpenAI 的 text-embedding-3 或本地的 BGE 模型）能将文本、图片等转化为一串高维数值（向量）。在这个高维空间中，语义越接近的数据，其向量距离就越近。 核心功能： 与传统数据库通过 SQL WHERE 子句匹配关键词不同，向量数据库通过“最近邻搜索（ANN）”寻找语义上最相似的内容。它是实现 RAG（检索增强生成）技术的关键。 常见向量数据库 数据库 特点 适用场景 Milvus 超大规模、分布式 海量数据、互联网 Qdrant 易部署、性能高、支持过滤 企业级 AI 应用 Weaviate GraphQL、模块丰富 AI 平台 Chroma 轻量级 本地开发、测试 Pinecone SaaS 云服务 快速上线 pgvector PostgreSQL 扩展 已有 PostgreSQL 项目 二、Qdrant介绍 2.1 什么是 Qdrant？ Qdrant 是一款使用 Rust 开发的开源向量数据库，专门用于高性能相似度搜索。 主要特点： 高性能 ANN 检索 HNSW 索引 REST API gRPC Payload 元数据过滤 多向量支持 Snapshot 备份 集群部署 Docker 支持 2....

RAG技术 （检索增强生成） 引言：当大模型遇上知识库 想象一下，你正在参加一场开卷考试。你的面前有两样东西：一个记忆力超群但知识停留在去年的天才同学（这就是大语言模型），以及一个可以随时查阅的最新版百科全书（这就是外部知识库）。你让这位同学回答问题，他既可以凭借自己的记忆作答，也可以随时翻阅百科全书获取最新、最准确的信息。 这个场景，就是 RAG（检索增强生成）最形象的比喻。 它不是要取代大模型，而是为大模型装上了一个可以实时更新的"知识图书馆"。 一、什么是 RAG？ 1.1 官方定义 RAG 全称是 Retrieval-Augmented Generation，中文译为"检索增强生成"。它是一种将信息检索系统与大语言模型的生成能力相结合的技术架构。 核心思想很简单：在让大模型回答问题之前，先从一个知识库中检索出与问题最相关的信息，然后将这些信息作为"参考资料"连同原始问题一起交给模型，让它基于这些资料生成最终答案。 1.2 为什么要用 RAG？ 传统的大语言模型存在三个先天性缺陷： 缺陷 表现 后果 知识截止日期 模型训练完成后，新发生的事件一概不知 问"今天的天气"、“最近的新闻”，模型只能道歉 幻觉问题 模型会"自信地胡说八道" 在金融、医疗等严肃场景无法直接使用 缺乏专业深度 对企业内部知识、专业领域知识不了解 无法回答基于私域数据的专业问题 RAG 的出现，一次性解决了这三个问题： 知识实时更新：只要更新知识库，模型就能"知道" 答案可追溯：每个回答都能找到对应的参考资料 低成本私有化：无需训练模型，只需构建知识库 1.3 RAG 的三步工作流程 一个标准的 RAG 流程包含三个核心步骤： 用户提问："去年的销售额是多少？" ↓ [第一步：检索] ↓ 在向量数据库中搜索 → 找到"2023年财报.pdf"中的相关段落 ↓ [第二步：增强] ↓ 构建新的提示词： "基于以下资料回答问题： 【资料】2023年公司财报显示，全年销售额为1.2亿元... 问题：去年的销售额是多少？" ↓ [第三步：生成] ↓ 大模型生成："根据公司财报，2023年的销售额为1.2亿元。" 二、RAG 的核心技术组件 要深入理解 RAG，需要认识它的三个核心技术组件： 2.1 向量化与嵌入模型 是什么：将文本转化为计算机能够理解的数学向量（一组数字）。 为什么需要：计算机无法像人类一样理解文字的"含义"，但它擅长计算数字之间的"距离"。通过将文字转化为向量，我们可以用数学方式衡量两段文字的相似度。 像 OpenAI 的 text-embedding-3-small 模型，或者本地的 bge-large-zh 模型，都是常用的嵌入模型。...

模型微调 一、模型微调到底是什么 简单来说，模型微调就是让一个已经博学多才的“通才”，通过针对性的“岗前培训”，变成精通某个领域的“专家”。 预训练模型（通才大厨）：就像一位精通全球菜系的米其林大厨，他掌握了所有的基础知识和烹饪技巧，但未必了解你餐厅的特色。 微调（岗前培训）：你想开一家川菜馆，于是让这位大厨用三个月时间，专门学习川菜的食材、调料和烹饪手法。 微调后的模型（川菜大师）：最终，他不仅保留了原有的厨艺基础，更能做出一手地道的麻婆豆腐，成为了川菜领域的专家 。 这个过程直接调整模型的“大脑”（参数），让学到的技能内化为模型自身的能力。相比于RAG（它更像是让大厨在做菜时随时翻阅菜谱），微调后的模型在推理时速度更快，且能深度掌握某种特定的风格或知识 。 二、 核心技术：LoRA——四两拨千斤的微调利器 你可能会担心，重新训练一个包含几十亿甚至上千亿参数的大模型，得需要多强大的计算资源？这正是LoRA（低秩自适应） 技术大显身手的地方。 它的核心思想非常巧妙，我们可以继续用“川菜大厨”的比喻来理解 全量微调：相当于让大厨忘掉过去的一些习惯，全身心地重新学习川菜的每一个步骤。效果最好，但成本极高，需要强大的算力支持。 LoRA微调：我们不动大厨已经固化的核心“厨艺”（预训练权重），而是给他一个轻量级的“川菜秘方贴纸”（低秩矩阵）。这张贴纸只记录了川菜的关键调整点，比如“多加花椒”、“牛油比例提升”。大厨在做川菜时，只需要在关键步骤上参考这张贴纸即可 。 这样做的好处是巨大的： 显存占用低：可训练的参数通常只有不到1%，让在消费级显卡（如RTX 4090）上微调大模型成为可能。 训练速度快：大幅缩短了训练时间。 模型性能高：在绝大多数任务上，效果可以媲美全量微调。 QLoRA 则是LoRA的进阶版，它先把基础模型“压缩”（量化）到4位精度，再应用LoRA，进一步降低了硬件门槛。 三、 具体如何实现 理解了原理，我们来看看如何上手。 你完全不需要从零开始写复杂的训练代码。这里有两条清晰的路径： 路径一：使用云端服务（最简单、快速上手） 这是最省心的方式，你只需要准备好数据，在云平台上点点鼠标，就能完成微调。例如华为云的ModelArts Studio，流程大致如下 ： 准备数据：整理好你的训练集（如客户问答对、特定风格的文本等）。 选择模型：在平台界面选择你想要微调的基础模型，例如盘古大模型。 配置任务：选择“微调”训练类型，并可以灵活选择“全量微调”或“LoRA微调” 。然后设置一些基本参数，如： 学习率：决定模型参数更新的幅度，通常设为很小的值如 2e-5 。 训练轮数：整个数据集被训练的遍数，通常设为 3 以避免过拟合。 数据批量大小：每次处理的数据量，根据你的资源情况设定。 启动训练：提交任务，等待训练完成。过程中可以观察损失值（Loss） 曲线，它应该呈下降趋势，代表模型在有效学习。 部署使用：训练完成后，平台会自动生成一个微调后的模型版本，你可以像调用普通API一样，通过PHP代码来使用这个专属模型。 路径二：使用本地开源工具（更灵活、适合动手实践） 如果你想在自己的电脑上体验整个过程，Ollama + Python是一个非常棒的组合，它让微调变得异常简单 。步骤如下： 1. 安装Ollama 参考另一篇 Ollama搭建本地 我们选择一个轻量级模型，普通电脑也能流畅运行 ollama pull llama2 2. 准备微调数据 微调的核心是数据。我们将创建一个非常简单的数据集，让模型学习用莎士比亚的风格回答问题。 2.1 创建项目目录 在合适的位置新建一个文件夹： mkdir ollama-finetune-demo cd ollama-finetune-demo 2.2 创建Python虚拟环境...

Embedding：理解语义的基础 引言：当计算机学会了"理解"含义 在上一篇文章中，我们讨论了大语言模型的工作原理。但有一个根本问题还没解决：计算机是如何"理解"词语含义的？ 计算机只能处理数字，它不认识"猫"，不认识"爱情"，更不懂"苹果"和"橘子"的相似性。但今天的AI不仅能理解这些概念，还能进行语义推理。这一切的基石就是 Embedding（嵌入）。 一、什么是Embedding？ 1.1 从一个思想实验开始 想象你要向一个来自外星、不懂任何人类语言的外星人解释"苹果"这个词。你会怎么做？ 你可以给他一个多维度的描述： 维度 描述 颜色 通常是红色或绿色 形状 圆形 大小 拳头大小 味道 甜或酸甜 口感 脆 用途 可以吃 … … 如果把这些维度变成数字，就得到一个向量： 苹果 = [红色: 0.9, 圆形: 0.8, 大小: 0.5, 甜度: 0.7, 脆度: 0.8, 可食用: 1.0, ...] 这就是Embedding的基本思想：用一个数字数组（向量）表示一个概念的含义。 1.2 正式定义 Embedding（嵌入） 是将离散的符号（词语、句子、图片等）映射到连续向量空间的技术。每个符号被表示为一个固定长度的实数向量。 关键特性： 语义相近的符号，向量距离也相近 向量之间可以进行数学运算 向量的维度（长度）通常在几十到几千之间 1.3 直观理解：语义空间地图 可以把Embedding想象成绘制了一张"语义空间地图"： [国王] ↑ 男人 ↑ [苹果] ← 水果 → [橘子] [王后] ↑ / 女人 / ↑ / [女王] 在这张地图上：...

AI Agent：从"回答问题"到"主动行动"的智能体 引言：当AI从"思考者"变成"行动派" 到目前为止，我们讨论的所有AI应用都有一个共同点：被动响应。你问一个问题，模型给出一个回答。就像一位知识渊博但从不主动行动的学者。 而 AI Agent（智能体） 将彻底改变这个模式。它不再是单纯的"问答机器人"，而是一个能够自主理解目标、规划步骤、调用工具、执行行动的智能系统。 用一个形象的比喻来理解AI的进化： 阶段 比喻 能力 基础LLM 刚毕业的大学生 知识丰富，但只会回答问题 RAG增强 配备了图书馆的大学生 能查阅资料，回答更准确 微调模型 经过专业培训的专家 在特定领域更精通 AI Agent 项目经理 + 执行团队 能接收任务，规划执行，调用资源，交付成果 一、什么是AI Agent？ 1.1 核心定义 AI Agent（智能体） 是一个能够感知环境、自主决策、执行行动以达到特定目标的智能系统。它具备以下核心特征： 自主性：无需人工干预，自主运作 目标导向：所有行动都围绕达成目标 工具使用：能调用外部工具完成任务 记忆能力：记住历史，持续优化 规划能力：将复杂任务拆解为可执行的步骤 1.2 Agent vs 传统程序 vs LLM 对比维度 传统程序 大语言模型(LLM) AI Agent 工作方式 按固定逻辑执行 按输入生成输出 自主规划并执行 灵活性 低，只能做预设的事 中，能处理多种问题 高，能适应新任务 工具使用 内置固定功能 无（需外部配合） 主动调用各种工具 记忆能力 有状态但有限 会话级记忆 长期记忆+经验积累 目标理解 执行指令 理解问题 理解意图并拆解 1....

理解大模型工作原理 引言：当计算机学会了"说话" 想象一下，你正在和一个"人"对话，他能理解你的问题，能写出优美的诗句，能解释复杂的科学概念，甚至能帮你写代码。但这个"人"其实是一个运行在服务器上的软件程序。它如何做到的？ 这就是大语言模型（Large Language Model, LLM）创造的奇迹。在本文中，我将用一个PHP开发者的视角，带你深入理解这个"数字大脑"的工作原理。 一、大模型是什么？ 1.1 从一个形象的比喻开始 传统程序 vs 大模型 对比维度 传统程序 大语言模型 工作方式 按照程序员写的代码执行 根据海量数据"学习"出的规律工作 知识来源 程序员明确告诉它 从数万亿文本中自己"领悟" 灵活性 只能处理预设的场景 能应对从未见过的问题 类比 按照菜谱做菜的厨师 尝过百万道菜后自己创造新菜的大厨 1.2 从数字到智能：三个关键洞察 洞察一：词语可以用数字表示 就像我们可以用经纬度表示地球上的任何位置，我们也可以用一组数字（向量）表示一个词的含义： "国王" = [0.8, 0.3, -0.2, 0.5, ...] "王后" = [0.7, 0.4, -0.1, 0.6, ...] "苹果" = [0.1, 0.9, -0.8, -0.3, ...] 洞察二：词语之间的关系可以用数学计算 经典的"国王 - 男人 + 女人 = 王后"实验表明，这些数字向量之间可以进行数学运算，而且结果符合语义！ 洞察三：上下文决定含义 “苹果"在"苹果很好吃"和"苹果发布了新手机"中含义不同。大模型需要理解这种差异。 二、大模型的核心架构 2.1 从神经元到神经网络 单个神经元（生物类比）： 树突（接收信号） → 细胞体（处理信号） → 轴突（输出信号） 人工神经元（数学抽象）： 输入 × 权重 + 偏置 → 激活函数 → 输出 2....

macOS & Linux 通过设置 http_proxy、https_proxy，可以让终端走指定的代理。 配置脚本如下，在终端直接执行，只会临时生效： # 设置代理 export http_proxy=http://127.0.0.1:8899 export https_proxy=$http_proxy # 或是一行命令 export https_proxy=http://127.0.0.1:8899 http_proxy=http://127.0.0.1:8899 # 还原代理 unset http_proxy https_proxy 8899 是 http 代理的端口，请根据你的实际情况修改。 Windows 以下代理生效情况均使用 curl -I http://www.google.com 进行验证。 Git Bash 设置方法同 “macOS & Linux” # 设置代理 export http_proxy=http://127.0.0.1:8899 export https_proxy=$http_proxy # -I/–head 只显示请求头信息 $ curl -I http://www.google.com ... # 还原代理 unset http_proxy https_proxy $ curl -I http://www.google.com curl: (28) Failed to connect to www.google.com port 80: Timed out PowerShell # PowerShell 中的 curl 语法： curl....

设计模式原则 设计模式的原则是理解和使用设计模式的基石。这些原则是面向对象设计的核心指导思想，设计模式本身就是这些原则在特定场景下的具体体现。 最重要的设计原则是 SOLID 原则，此外还有一些其他关键原则。 一、 SOLID 原则 SOLID 原则是五个最常用、最经典的设计原则，由 Robert C. Martin 提出。 1. 单一职责原则 核心思想： 一个类应该只有一个引起变化的原因。 详细解释：一个类只负责一项职责或功能。如果一個类承担的功能过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。 比喻： 一家餐厅，厨师负责做饭，服务员负责点菜和上菜，清洁工负责打扫。如果他们职责混杂，效率就会低下。 违反示例： 一个 UserService 类，既负责用户信息的增删改查，又负责将用户数据导出为PDF报表，还负责发送邮件通知。 修正： 将 UserService 拆分为 UserService（用户业务逻辑）、UserReportGenerator（报表生成）和 EmailService（邮件服务）。 2. 开闭原则 核心思想： 软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。 详细解释： 当需求发生变化时，我们应该通过添加新的代码来扩展功能，而不是修改已有的、已经工作正常的代码。这是最重要的原则，是很多设计模式的目标。 比喻： 一台电脑，你可以扩展USB设备（鼠标、键盘、硬盘），而无需为了支持新设备而拆开主机修改主板。 违反示例： 一个 AreaCalculator 类，有一个 calculate 方法，里面用 if-else 来判断是圆形还是矩形来计算面积。如果要增加三角形，就必须修改这个类的代码。 修正： 定义一个 Shape 接口，包含 calculateArea 方法。让 Circle 和 Rectangle 类实现这个接口。AreaCalculator 只需遍历 Shape 列表调用其方法即可。要新增三角形，只需创建 Triangle 类实现 Shape，无需修改任何现有类。 3. 里氏替换原则 核心思想： 所有引用基类的地方必须能透明地使用其子类的对象。 详细解释： 子类必须能够完全替代它们的父类，而不产生任何错误或意外的行为。也就是说，子类只能在保持原有行为的基础上进行扩展，而不能覆盖或改变父类的核心行为。 比喻： 你父亲会开车，你作为儿子继承了他，你也会开车（保持了父亲的行为），但你可能会开得更快或者还会修车（扩展），你绝不能把“开车”这个行为重定义为“游泳”。 违反示例： Rectangle 类有 setWidth 和 setHeight 方法。Square 类继承 Rectangle，并重写了 setWidth 和 setHeight，使其同时设置宽和高。那么，一个接收 Rectangle 参数并调整其宽高的函数，如果传入一个 Square 对象，就会得到错误的结果。 修正： 重新考虑继承关系，或者让 Rectangle 和 Square 都实现一个 Shape 接口，而不是使用继承。 4....

MySQL 中主要的日志类型 MySQL 提供了多种日志类型，每种都有其特定的目的和格式。理解这些日志对于数据库管理、性能调优、数据恢复和故障排查至关重要。 下面我将详细介绍 MySQL 中主要的日志类型及其格式 总结概览 日志类型 主要目的 格式 是否默认开启 错误日志 记录 MySQL 启动、运行、停止时的错误、警告和提示信息。 文本格式 是 二进制日志 记录所有更改数据的语句，用于主从复制和数据恢复。 STATEMENT, ROW, MIXED 否 (8.0默认开启) 通用查询日志 记录所有到达 MySQL 的客户端连接和执行的语句。 文本格式 / CSV 格式 否 慢查询日志 记录执行时间超过指定阈值的查询，用于性能优化。 文本格式 / CSV 格式 否 重做日志 InnoDB 特有的，用于保证事务的持久性和崩溃恢复。 物理格式（二进制） 是 回滚日志 InnoDB 特有的，用于保证事务的原子性和 MVCC。 逻辑格式 是 详细解析 1. 错误日志 这是 DBA 首先需要查看的日志，当数据库出现任何异常时，它通常是排查问题的起点。 内容：启动/关闭信息、错误信息、警告信息、在复制环境中从服务器线程的启动信息等。 格式：纯文本格式，易于阅读。 配置参数： log_error：指定错误日志文件的位置。 示例内容： 2023-10-27T08:00:00.000000Z 0 \[Note\] Server started. 2023-10-27T08:01:23.456789Z 5 \[Warning\] Aborted connection 5 to db: 'test' user: 'root' host: 'localhost' 2....