cczywyc

上一篇文章是关于 RAG 的一些基本介绍，这篇主要是根据上篇的流程来实现一个简易的 RAG 系统，进一步加深对 RAG 工作流程的理解。本文所列举的示例代码非常简单，完全是按照上篇文章中所划分的三个阶段来的，但是包含了 RAG 系统所有的必要步骤。 数据源加载与分块1234567891011from typing import Listdef split_into_chunks(doc_file: str) -> List[str]: with open(doc_file, 'r') as file: content = file.read() return [chunk for chunk in content.split("\n\n")]chunks = split_into_chunks("doc.md")for i, chunk in enumerate(chunks): print(f"[{i}] {chunk}\n&quo...

基础原理RAG（Retrieval-Augmented Generation）中文叫做检索增强生成，它是一种将外部知识库与大语言模型（LLM）相结合的技术。其核心思想是在大模型生成回答之前，先检索文档将检索到内容作为上下文输入给模型，从而提高回答的准确性和时效性。 在一个典型的 RAG 系统中，首先会对外部文档进行预处理并向量化存储形成知识库，当用户提出问题，系统会将问题转化成向量，并且计算出向量相似度，在知识库中找出与用户问题相近的片段，然后将用户问题和相似片段一起丢给大模型（prompt），大模型在此基础上生成答案。 总结上述过程，大致可以分为三个阶段： 准备阶段：分片、索引 检索阶段：召回、重排 生成阶段：生成 使用场景通过上述的介绍不难发现，RAG 适合用做智能客服或者企业内部知识库等私有化数据的场景。一般来说，传统的 LLM 通常都有上下文的限制（即使 Gemini 有百万的上下文），这就导致大模型在工作时始终有上下文局限，我们不可能把大量的私有数据一下子全部喂给大模型，而 RAG 通过分片、向量化存储和向量相似性等手段解决了 LLM 根本局限性。 总结一下，可以归...

模型上下文协议（MCP）是一个开放协议，用于标准化应用程序向大语言模型提供上下文的方式，由 Anthropic 于 2024 年 11 月推出。在 MCP 出现之前，将 AI 模型连接到各种数据源通常需要为每个源开发定制化的集成方案，导致系统碎片化、难以扩展且开发成本高昂，MCP 则通过提供一个通用的、标准化的协议来解决这个问题。 MCP 架构MCP 的核心架构遵循客户端-服务器模型，主要包含三个组件： MCP 主机（MCP Host）：指的是希望通过 MCP 利用外部数据或工具的应用程序。例如 AI 助手（如 Claude Desktop）、集成开发环境（IDE）、或其他 AI 工具。MCP Host 负责管理 MCP 客户端实例，并控制权限和安全策略。 MCP 客户端（MCP Client）：嵌入在主机应用程序中，是实现 MCP 协议客户端逻辑的部分。它负责与一个或多个 MCP 建立并维护安全、一对一的连接，管理通信、状态和能力协商。 MCP 服务器（MCP Server）：是实现协议服务器端逻辑的程序。它连接到具体的数据源（本地文件、数据库等）或远程服务（API），并通过...

Paxos 背景和介绍进入正文之前先来简单说一下几个概念和 Paxos 的由来。 分布式一致性问题在分布式计算领域，一个核心且基础的挑战是如何让一组独立的计算机（或称为节点、进程）在可能发生故障（如节点崩溃、网络消息丢失或延迟）的环境下，就某个值或状态达成一致 。这个问题被称为共识（Consensus）。达成共识的能力对于构建可靠的分布式系统至关重要，这些系统需要在多个副本之间维护数据一致性，例如分布式数据库、分布式锁服务、以及实现状态机复制（State Machine Replication）等场景 。状态机复制是一种强大的技术，它允许将任何单机上的确定性算法转化为一个容错的、分布式的实现，确保即使部分副本发生故障，整个系统对外也能表现得像一个永不宕机的单体服务 。 一个健壮的共识算法通常需要满足几个关键属性： 有效性（Validity）：最终被选定的值必须是某个进程实际提议过的值。 一致性（Agreement/Consistency）：所有做出决定的正常进程必须对同一个值达成一致 。这是共识最核心的保证。 完整性（Integrity）：每个进程最多只能决定一个值。...

MIT 6.824 课程的第二个 lab 是实现一个 key/value server，这里是官网的 实验说明。本篇文章是关于 key/value server 实验设计思路及实现过程。 实验概述本实验要求实现一个单机版的 kv server，支持 Put、Append 和 Get 三种操作。该服务保证所有的操作都必须是线性化（linearizable）的，确保操作顺序符合实时顺序，并且能够处理网络故障（例如消息丢失），保证操作只执行一次。实验目标是能够满足不同客户端以及不可靠网络等场景，确保服务器在并发和故障情况下都能够正常工作。 设计 线性化：通过使用 Go 的互斥锁（mutex）保护共享数据，确保并发访问时操作顺序一致。 网络故障处理：客户端为每个请求分配唯一序列号（sequence number），服务器通过客户端唯一标识（Client ID）和请求序列号检测重复请求，确保幂等性。 操作定义： Put(key, value): 将键 key 的值设置为 value，覆盖原有值。需确保线程安全，并记录序列号以防重复。 Append(key, arg): ...

MapReduce 是一种处理大量数据的编程模型以及实现，它使用 Map 和 Reduce 两个函数对于海量数据计算做了一次抽象，用于在集群上使用分布式算法处理和生成大数据集。MapReduce 最先由 Google 在 2004 年提出，并且在内部得到了大量的实践，简单说来，MapReduce 模型由一个 Map 函数处理一个基于 key/value pair 的数据集合，输出中间的基于 key/value pair 的数据集合，然后再由一个 Reduce 函数用来合并所有的具有相同中间 key 值的中间 value 值。 仔细分析发现，现实世界中有很多满足上述处理模型的例子，关于 MapReduce 的产生背景和详细的介绍本文不再详细叙述，强烈建议阅读 Google 的论文，一定会对 MapReduce 模型有更进一步的理解。 说起分布式系统，大家应该都知道 MIT 有一个明星课程 6.824，它是专门讲解分布式系统的，这个课程还设置了一系列非常有难度的实验来检验你对课程的掌握。为了进一步加深我对分布式系统的理解，前段时间我便开始完成 2024 年春季 6...

上篇文章，详细介绍了 WebRTC 技术。我们知道，WebRTC 标准中并没有规定信令服务器的实现，它把这部分的实现交给了程序开发者本身，一方面基于 WebRTC 的应用形态和技术栈可能是多种多样的，这样不但保持了技术中立性，还最大限度的确保了技术的灵活性和开放性；另外一方面，协议的设计是极其复杂的，要兼顾的场景很多，这样也保证了技术标准的简洁性。因此，只要符合 WebRTC 的通信流程和架构设计理念，信令服务器的实现方案应该是非常灵活的。 本文是此系列文章的第二篇，介绍 WebRTC 中信令服务器的设计。 信令介绍在 WebRTC 的技术栈里，详细定义了一整套的规范，例如它的接口设计，使用 SDP 进行媒体协商、使用 ICE 收集网络地址并进行联通性检测等，这些规范使得客户端与客户端之间的数据交换变得非常容易和方便，但是我们发现 WebRTC 并没有对客户端建立点对点连接之前的过程定义规范，“空缺”的这部分，其实就是信令服务器在发挥作用的地方。 概括来说，WebRTC 信令是设备通信和交换点对点连接所需的信息的方式，包括交换应用程序之间的网络信息、协商媒体格式并处理通信会话的各...

如题，最近在折腾一个文件传输工具，用于在多个不同设备间方便快速地传输文件。我的要求也很直接，这个文件传输工具，最好不需要繁琐的安装和配置过程，能够做到开箱即用，同时它还需要兼容我的 PC 设备和多个移动设备，经过一番调研之后，我决定把技术方案定为了 WebRTC。 本篇文章是此系列文章的第一篇，详细介绍 WebRTC 技术。 WebRTC 概述WebRTC（Web Real-Time Communication）是一个开源项目，旨在通过简单的应用程序接口（API）实现浏览器和移动应用之间的实时通信（RTC）。它允许网页浏览器进行语音通话、视频聊天和点对点文件分享，而无需用户安装特殊的插件或第三方软件。 简单来说，WebRTC 项目主要思想是定义 WebRTC API，该 API 允许浏览器安全地访问设备上的输入外设，如麦克风和网络摄像头，以点对点的方式与远程设备共享或交换媒体数据以及实时数据。借助 WebRTC，多个不同设备可以在一个平台上流畅地、安全地共享语音、视频和实时数据。 WebRTC 是 Google 在 2011 开源的项目，并将其纳入 Chrome 浏览器的开发计划...

临近年末，最近陆陆续续看到不少人公开了自己的年终总结，我也跟个风，总结一下即将过去的我的 2023 年。 一开始我在总结过去的一年的时候，发现并没有太多值得总结的事情，出于博客网站的需要，我决定还是开个好头，写下了这篇文章。需要特别说明的是，这是一篇流水账式的文章，并没有特别的干货，写的真的很烂。 既然说到这里，先来说一下我的个人网站，2023 年是我正式开始写博客的第一年，正如我在这篇文章中所说，以前我总是记录的很杂、很随意，我希望通过写博客的方式让自己养成记录的好习惯，并且借此得以规范我的记录，希望这是一个好的开始。截止到现在，整个 2023 年我一共正式写了 12 篇文章，算很少的了，其中有不少时间还花在个人网站的建设上，一开始我使用的是 hugo 来构建我的网站，苦于我使用的主题文档缺少，加上 hugo 可自定义性不高，在 12 月份的时候我把个人网站改为了 hexo 构建，并且使用了全新的主题，这套主题文档很详细，可配置性很高，比较适合作为我构建个人网站的选择，最后也就是你现在看到的这个样子。 去年 12 月，我跟妹子摇中了一个不错的盘，也算正式上车，成为房奴大队的一员...

最近 GitHub 官方博客更新了一篇文章，讲述了将 GitHub 网站依赖的 1200+ 台 MySQL 主机升级到 8.0 版本的过程。 先前，Oracle 官方宣布，在 2023 年 10 月 21 日之后，MySQL 5.7 将达到其生命周期的终点，这意味着 Oracle 将不再为 MySQL 5.7 提供官方更新、错误修复或安全补丁，正是在这一背景下，才有了 GitHub 此次的升级。 根据 GitHub 官方介绍，GitHub 使用 MySQL 来存储大量关系数据，因此对于数据库这种底层的基础设施的升级绝非易事，为了升级到 MySQL 8.0，他们规划、测试和升级本身总共花费了一年多的时间，并且需要 GitHub 内部多个团队的协作。因此对于 GitHub 此次这种大规模的底层数据库的升级，我本身是抱有极大的兴趣，也想了解一下如此大规模的 MySQL 的集群采用了什么样的升级方案，所以我去阅读了 GitHub 官方博客，并且将原文翻译如下，以下是原文翻译全部内容。 15 年前，GitHub 开始于一个使用 Ruby on Rails（cczywyc 注：一个基于 R...