前言

这次的定语比较多，又是 简易 又是 client 的

如果你去翻阅 langchain4j 有关 MCP 的文档（点击这里），你会发现有关它的内容比起 RAG 少的可怜

在我看来，应该是以下几个原因有关

• langchain4j 并没有实现完整的 MCP 协议。在目前版本（1.0.1）的 langchain4j 中是不存在 MCP Server 这个组件的
• langchain4j 对于 MCP Client 的理解和 Function Calling 异曲同工，有一些逻辑在其他模块已经实现了

我其实是有些纳闷的，因为我最初就是想用 langchain4j 把现有的服务构建成一个 MCP Server，至于 MCP Client 我想许多客户端都可以充当这个角色

以上推论主观性很强，如果有错误，可以联系我的邮箱

RAG 是什么

langchain4j 的官网给了一段通俗易懂的描述

简单来说，RAG 是一种在发送给 LLM 之前，从你的数据中找到并注入相关信息片段到提示中的方法

RAG 分为两个阶段，索引和检索

关于检索部分，下面的项目中将分别使用 langchain4j 的原生组件以及高级用法分别实现

简单说明一下我对这两个阶段的理解

前言

首先谈谈我对音乐，以及流媒体的理解

我对音乐的狭义理解是：由乐器弹奏，或者人哼唱出来的歌。对于流媒体，我认为在网络上传播的影像记录就是流媒体

简述

简单总结一个自从三月来深圳的大体消费支出情况

基本情况

1. 2024 年 3 月到 4 月中旬前，处于求职状态，这个时候暂无收入
2. 2024 年 4 月下旬至今，由于有了工作，每月的开销都相对固定

消费类别

个人的支出情况主要分为几大类

1. 住宿
2. 饮食
3. 交通
4. 零食
5. 生活用品
6. 其它购物

在求职阶段，主要消费类别集中在前三项

前言

之前写了一篇通过 GitHub Actions 的容器作为中转拉取 docker-hub 博客，不过使用的还是阿里云的镜像仓库

GitHub 上有推荐自建仓库的开源项目，比如 registry-mirror

网上虽然有不少活雷锋把自己的仓库开源出来，不过不少是限速的，拉取小镜像还好，一旦需要拉取像是 elasticsearch 这样大的镜像，又可能会因为拉取速度太慢导致多次重试，最后失败

这次，我也来试试自建仓库。自建的 docker 仓库，都是基于官方的一个镜像 registry