RAG（Retrieval-Augmented Generation）现在已经成了大模型落地最重要的方式之一；那我们该如何 衡量一个 RAG 系统做得好不好 呢？

这时候，就该请出今天的主角—Ragas。

一、开卷考试的灵魂拷问

大模型的能力是通用的，而 RAG 系统往往用于解决某些具体领域问题，比如：

• 企业内部知识库问答
• 产品使用文档查询
• 结构化文档问答（PDF、Word、网页）

在这类场景中，光靠模型本身能力还不够，需要通过 “检索” 拿到参考资料，再交给模型进行“生成”。

这就像一次开卷考试：

• 你是大语言模型；
• 开卷材料是知识库或检索内容；
• 最后你的回答，要尽可能基于材料，内容准确、有用。

问题来了：我们怎么知道你这份答案答得好不好？

在开始前 咱们先来做个调研~

有哪些朋友们自己亲自换过（或者安装过）电脑上的内存条，无论 台式机、笔记本 亦或是 刀片机 都行

一、为什么有这么一个话题

这两年一直有个很热的话题，就是 芯片这个被卡脖子的领域，所以年初在筹备课程话题的时候就想着跟大家一起聊聊这方面的东西；

那么大家可能想着芯片不应该说 CPU 吗，为啥聊内存啊？？？ 额，主要是我手头没有多的 CPU，储藏室倒是有几个当年去科技市场买零件 “攒（cuan)” 电脑时候淘换的古董内存条，索性咱们就一起聊聊内存条吧，毕竟内存条也是芯片的重要应用场景。

MD5 是一个特别古老的知识：

• 老到我们都认为它的一切都是理所当然的；
• 老到我们看到这个名称仿佛看到的就是老掉牙的代名词。

直到前段时间我遇到了一些案例，才想起来，也许可以跟大家聊聊这个特别 “平常” 的小玩意儿～

一、为什么有这么一个话题

前几个月在处理小朋友日常视频的时候，发现视频工具提供了一个 MD5 更改的工具，下意识心说这么简单的一个功能咋还搞了个工具出来，不过转念一想，这也许就是个思维陷阱，其实听说过 MD5 的人本来就不多（只是我们身处这个行业才觉得很平常）

好奇看了一下搜索结果（是不是发现也许一个小东西也是商机）：

众所周知， Jemalloc 作为很多对内存敏感的系统/中间件的主要内存分配工具，以优良的性能从一开始取代了 malloc，比如 Redis 从 4.0 开始引用 Jemalloc；前两年在调试 Redis 代码的时候发现一个问题，同样是 malloc(1024); 这样一个普通的语句，引入了 Jemalloc 的时候，分配的内存空间地址类似 0x7f5c1d923010，从样子上看非常像是属于栈地址的高位空间 0x7fffbc500084，而 标准库里的 malloc 分配的内存地址为明显的低位地址 0xf94330，一看就属于堆地址空间，当时就疑惑了，Jemalloc 到底用了啥技术可以让 栈地址空间在方法间传来传去，完全不科学嘛…

当时一直认为是 Jemalloc 方面的手脚，花了一两天翻了 Jemalloc 源码，二话不说就 gdb 起来，相信无论是哪个地方的问题，在我单步调试下一定能无所遁形，当时调试到最后还是返回的高位地址（劳资信了你的鞋 ~~~!!!），奈何产品经理上门催任务了，暂时搁置，最近刚好有空，心痒痒，再来瞅瞅，这一瞅，还真发现问题了…

『敲黑板』，这次我们就来分析一下具体原因，顺便说说 malloc 和 Jemalloc 的实现方式

就在 2019 年 12 月 20 号这天，众所期待的 Redis 新版 6.0 rc1 发布了（Redis 6 RC1 is out today）肯定很多关注的同学都进行了试用，虽然因为引入了 c11 的 _Atomic 导致相当多的环境都无法直接编译成功，但是对于想一探究竟的粉丝们来说，这是完全阻挡不了的热情，当然我也不例外~<狗头>~~

新版除了增加 ACLS 权限控制模块、支持更为广泛的新协议 RESP3、客户端缓存、无磁盘同步、Cluster Proxy 等十来个相当实用的新特性外，还对 长久以来 社区筒子们 呼声比较高的 多线程 进行了支持，当然也带来 性能提升了一倍 的好处

这次我们的任务有两个：

• 剖析 Redis6 多线程的实现方式
• 与 Memcached 的多线程模型（个人认为这是一个极其经典的多线程网络编程案例）进行对比

Nginx 作为 多进程网络编程的 巅峰之作（那么请问 多线程巅峰、单进程巅峰是？），也是当前最流行的 HTTP Server，其优秀之处毋容置疑；一直到 2011 年左右，Nginx 还仅仅是 反向代理的 首选，后来随着 HTTP 核心的成熟 慢慢用来 替代 Apache 单独作为 HTTP Server；当然这中间也离不开 第三方扩展模块 的日益丰富；从最初的 nginx_lua_module 支持 lua 嵌入，到后来 春来大神 的 OpenResty，集成 LuaJIT，使得 Nginx 生态再次丰富起来

说到第三方扩展，就不得不说一下 Nginx 的 高扩展特性，它从设计上完全就由多个不同功能、不同层次、不同类型且耦合度极低的模块构成，因此，当对某一个模块修复 Bug 或 进行升级的时候，可以专注于模块本身，无需在意其他。而且在 HTTP 模块中，还设计了 HTTP 过滤器模块，也就是说一个正常的 HTTP 模块在处理完成 request 后，会有一串 HTTP 过滤器模块对请求结果进行再处理，这样，当我们开发一个新的 HTTP 模块时，当然也可以复用诸如 HTTP 核心模块、events 模块、log 模块 等不同层次不同类型的模块，这种低耦合度的优秀设计，也给我们 定制模块开发 提供了很大便利

Kong 是一款基于 OpenResty（Nginx + Lua模块）编写的高可用、易扩展的，由 Mashape 公司开源的 API Gateway 项目。Kong 是基于 Nginx 和 Apache Cassandra 或 PostgreSQL 构建的，能提供易于使用的 RESTful API 来操作和配置 API 管理系统，所以它可以水平扩展多个 Kong 服务器，通过前置的负载均衡配置把请求均匀地分发到各个 Server，来应对大批量的网络请求

Kong 采用插件机制进行功能定制，插件集（可以是0或N个）在 API 请求响应循环的生命周期中被执行。插件使用 Lua 编写，目前已有一些基础功能：HTTP基本认证、密钥认证、CORS（Cross-Origin Resource Sharing，跨域资源共享）、TCP、UDP、文件日志、API请求限流、请求转发以及Nginx监控。

推荐查看 官网文档，详细了解，这里不再赘述，我们这次还是以 Kong 网关插件开发为主题，定制一个 Signature验签 插件

复制 作为现代数据服务基本必备的功能，保证 数据的冗余备份，从而保障服务高可用和高可靠性，当然 Redis 这么伟大的服务也不例外

本章可能有点儿绕，做好心理准备… _￣ω￣=

Redis 复制( replicate ) 流程的核心在于 状态机 中状态的流转，连接各个逻辑运算，我根据 Redis ver4.0.11 的源码逻辑画了一个简单的 master-slave 状态机流转示意图，由于一般 从库的挂载都是由 slave 发起的，所以 slave 放在左边，大家可以先看一眼，我们后续进行每个步骤的详细讲解