本文由 莫潇羽@无忆研习社（www.wuyi.wiki） 原创撰写，转载请注明出处。文章首发于无忆研习社，未经授权禁止任何形式的复制与转载。
写在前面
最近在GitHub上逛的时候，注意到一个项目的热度蹿升得非常快。短短几天时间，Star数从几百飙升到了4600多，而且还登上了GitHub开源热榜的TOP 3。这个项目就是由清华大学THUNLP实验室联合多家机构发布的UltraRAG 3.0。
作为一个在AI领域摸爬滚打多年的老兵，我对RAG（检索增强生成）这个技术方向一直保持着高度关注。说实话，市面上的RAG框架和工具已经非常多了，从LangChain到LlamaIndex，从Haystack到各种云厂商的解决方案，选择确实不少。但当我深入研究了UltraRAG 3.0之后，发现它确实解决了一些让开发者头疼已久的痛点问题。
这篇文章，我会从技术原理讲起，带大家完整了解UltraRAG 3.0究竟是什么、它为什么值得关注、以及如何从零开始使用它来构建自己的RAG应用。文章会尽量讲得详细一些，让没有相关背景的朋友也能看懂。
第一部分：理解RAG技术——大模型应用的核心基础设施
在正式介绍UltraRAG之前，我们需要先把RAG这个概念彻底搞明白。如果你已经对RAG非常熟悉了，可以直接跳到下一部分。
什么是RAG？为什么它如此重要？
RAG的全称是Retrieval-Augmented Generation，翻译过来就是"检索增强生成"。这个技术最早由Facebook AI Research（现在的Meta AI）团队在2020年提出，核心思想其实非常朴素：让大语言模型在回答问题之前，先从外部知识库中检索相关信息，然后把这些信息作为上下文一起喂给模型，这样模型就能给出更准确、更有依据的回答。
你可能会问，大语言模型不是已经在海量数据上训练过了吗？为什么还需要额外的检索？这就要说到大模型目前面临的几个核心问题了。
第一个问题是知识的时效性。 大模型的知识完全来自于训练数据，而训练数据是有截止日期的。比如某个模型的训练数据截止到2024年1月，那么2024年1月之后发生的事情它就完全不知道。这对于需要处理最新信息的应用场景来说是致命的。
第二个问题是私有知识的缺失。 企业内部的文档、数据库、业务规则等信息，大模型在训练时根本接触不到。如果你想让大模型回答关于公司内部流程、产品手册或者客户数据的问题，它只能靠猜。
第三个问题是幻觉现象。 这是大模型最让人头疼的问题之一。由于大模型的底层原理是基于概率预测的，它有时候会非常自信地给出完全错误的答案，而且看起来说得头头是道。在一些对准确性要求很高的场景下，比如医疗、法律、金融等领域，这种幻觉可能造成严重后果。
RAG技术正是为了解决这些问题而生的。通过引入外部知识库，RAG可以让大模型的回答有据可查、与时俱进，同时大幅降低幻觉的发生概率。
RAG的工作流程详解
为了让大家更好地理解RAG，我来详细拆解一下它的工作流程。整个过程可以分为两个大的阶段：离线索引阶段和在线检索生成阶段。
离线索引阶段是准备工作，主要包括以下几个步骤：
首先是数据收集与预处理。把你想让大模型"学习"的知识整理出来，可能是PDF文档、Word文件、网页内容、数据库记录等等。然后对这些数据进行清洗和预处理，去掉无关的噪音信息。
接下来是文档切分（Chunking）。由于大模型的上下文窗口是有限制的，不可能把整个知识库一股脑塞进去，所以需要把长文档切成合适大小的片段。切分的策略有很多讲究，比如按段落切、按句子切、按固定字数切，或者使用更智能的语义切分方法。切分得太细会丢失上下文信息，切分得太粗又可能包含太多无关内容，这里面的平衡需要根据具体场景调试。
然后是向量化（Embedding）。这一步是RAG的核心。使用专门的Embedding模型（比如OpenAI的text-embedding-ada-002、BGE、M3E等）把每个文本片段转换成一个高维向量。这个向量可以理解为文本内容的"数学指纹"，语义相近的文本，它们的向量在数学空间中的距离也会比较近。
最后是存入向量数据库。把这些向量和对应的原始文本存储到专门的向量数据库中，比如Milvus、Pinecone、Weaviate、Chroma等。向量数据库和传统数据库不同，它专门针对向量的相似度检索做了优化，可以在毫秒级别内从数亿条记录中找出最相似的几条。
在线检索生成阶段是用户实际使用时的流程：
用户提出一个问题后，系统首先会用同样的Embedding模型把问题转换成向量。然后在向量数据库中进行相似度检索，找出和问题最相关的若干个文本片段。接着把这些检索到的内容和用户的原始问题一起组装成一个Prompt，发送给大语言模型。最后，大模型基于提供的上下文信息生成回答。
这个流程看起来不复杂，但实际工程实现中有非常多的细节和优化空间，这也是为什么会有这么多RAG框架和工具出现的原因。
传统RAG面临的挑战
随着RAG技术的广泛应用，大家也逐渐发现了一些问题和瓶颈。
第一个挑战是检索的准确性问题。 基于向量相似度的检索并不总是能找到真正相关的内容。有时候语义相似的文本实际上说的不是一回事，有时候真正相关的信息因为表述方式不同而被漏掉。
第二个挑战是复杂问题的处理。 简单的单轮问答用基础RAG就能搞定，但如果是需要多步推理、多轮交互、动态决策的复杂任务，传统RAG就显得力不从心了。比如深度研究类的场景，用户可能需要系统自动进行多次检索、整合信息、验证结论，这需要更复杂的流程编排能力。
第三个挑战是开发调试的困难。 现有的很多RAG框架要么过于简单，无法支撑复杂场景；要么过于复杂，学习成本很高。而且更要命的是，很多框架的内部执行过程像个"黑盒"，出了问题很难定位是检索环节的问题还是生成环节的问题。
第四个挑战是从算法到应用的鸿沟。 很多算法工程师设计了很好的RAG流程，但要把它包装成一个可交互的应用，还需要额外开发前端界面、处理参数配置、对接各种服务。这些工程化的工作消耗了大量时间和精力。
正是这些痛点，催生了UltraRAG 3.0这样的新一代RAG开发框架。
第二部分：UltraRAG 3.0全面剖析
项目背景与定位
UltraRAG是由清华大学THUNLP实验室、东北大学NEUIR实验室、OpenBMB、面壁智能与AI9Stars等多家机构联合推出的开源项目。值得注意的是，THUNLP（清华大学自然语言处理实验室）在NLP领域有着深厚的学术积淀，他们之前推出的很多工作都在业界产生了广泛影响。
UltraRAG的定位是首个基于MCP（Model Context Protocol）架构设计的轻量级RAG开发框架。这里有两个关键词需要特别注意：一个是"MCP架构"，一个是"轻量级"。后面我会详细解释MCP是什么，以及为什么它对RAG开发如此重要。
从功能定位来看，UltraRAG 3.0试图打通从"算法逻辑设计"到"可交互应用"的最后一公里。用官方的话说，就是"拒绝盲盒开发，让每一行推理逻辑都清晰可见"。这个定位非常准确地击中了当前RAG开发的痛点。
MCP协议：理解UltraRAG的关键
要理解UltraRAG的技术架构，首先要理解MCP协议。MCP（Model Context Protocol，模型上下文协议） 是由Anthropic公司在2024年11月推出的一个开放协议。你可以把MCP理解为AI应用领域的"USB-C接口"。
在MCP出现之前，如果想让大模型连接各种外部工具和数据源，开发者需要为每一种工具单独编写对接代码。这就像早期的手机充电器，每个品牌都有自己的接口标准，极其麻烦。MCP的出现就是为了解决这个问题——它定义了一套统一的协议标准，让AI应用可以用同样的方式连接不同的数据源和工具。
MCP采用的是客户端-服务器架构，主要包含三个核心组件：
MCP Host（主机） 是发起连接的AI应用程序，比如Claude Desktop、各种IDE或AI工具。它负责协调整个交互流程。
MCP Client（客户端） 存在于Host应用内部，负责与Server建立和维护连接。每个Client和Server之间是一对一的关系。
MCP Server（服务器） 是提供具体功能的轻量级程序，通过标准化的接口暴露特定的能力，比如检索服务、生成服务、评估服务等。
这种架构设计的好处是显而易见的。开发者只需要按照MCP标准开发Server，就可以被任何支持MCP的应用调用；反过来，开发应用时也可以方便地接入任何符合MCP标准的服务，实现即插即用。
UltraRAG 3.0的核心架构
了解了MCP之后，再来看UltraRAG的架构就清晰多了。UltraRAG把RAG系统中的各个核心组件（Retriever检索器、Generator生成器、Evaluator评估器等）都封装成了独立的MCP Server。这些Server可以独立运行、独立扩展，通过标准化的接口进行交互。
在此基础上，UltraRAG提供了一个强大的MCP Client作为流程调度引擎。开发者只需要通过YAML配置文件来声明Pipeline的执行逻辑，Client就会自动按照配置调度各个Server完成任务。这种声明式的开发方式大大降低了复杂RAG系统的实现难度。
用一个类比来说明：如果把传统的RAG开发比作手工组装一台电脑，需要你自己焊接电路板、连接各个硬件，那么UltraRAG就像是提供了标准化的主板插槽和配件，你只需要把需要的组件插上去，配置好参数就能运行。
三大核心特性深度解读
UltraRAG 3.0主打三个核心特性，每一个都针对性地解决了前面提到的痛点问题。
第一个特性：逻辑即应用（Configuration as Application）
这是我认为UltraRAG最具创新性的设计。在传统的开发模式下，设计一个RAG流程需要经历：构思算法→编写Pipeline代码→调试通过→开发前端界面→对接参数配置→调整交互细节这一长串步骤。其中后面几步完全是重复性的工程工作，但却往往占用了大量时间。
UltraRAG 3.0彻底改变了这个模式。它提供了一个"所见即所得"的Pipeline构建器，支持两种编辑模式：
画布模式让你可以在可视化界面上通过拖拽、连线的方式来组装流程，就像搭积木一样直观。你可以添加循环（Loop）、分支（Branch）等复杂的控制结构，完全不需要写代码。
代码模式则是直接编辑YAML配置文件。对于熟悉代码的开发者来说，这种方式更加高效灵活。而且画布视图会实时同步更新，你在代码模式下的修改会立即反映到可视化界面上。
最关键的是，当你定义好Pipeline之后，点击"Build"按钮，框架会自动执行语法校验和逻辑检查，并自动生成一套可交互的Web界面。不需要写任何前端代码，你的算法逻辑就变成了一个可以演示、可以使用的产品原型。
这对于算法工程师来说简直是福音。以前验证一个新想法可能需要一周时间来搭建demo，现在可能一个小时就能看到效果。
第二个特性：全链路白盒化（Full-Chain Transparency）
这个特性主要解决的是调试和优化的问题。UltraRAG 3.0提供了一个叫做"Show Thinking"的面板，可以实时展示整个推理过程的每一个细节。
具体来说，你可以看到：
- 每一次检索请求调用了哪个检索器
- 检索返回了哪些文档片段（Chunk）
- 每个工具（Tool）被调用了几次
- 在循环执行中，当前是第几轮
- 条件分支的判断结果是什么，走向了哪个分支
- 每一步的输入输出是什么
所有这些信息都以结构化的形式、按时间顺序清晰地展示出来。
这个功能的价值在实际开发中体现得淋漓尽致。以前遇到回答不准确的Bad Case，你需要一层层打日志、加断点来排查，到底是检索的问题（召回的内容不相关）还是生成的问题（模型产生了幻觉）。现在直接在界面上就能看到检索返回了什么、模型是基于什么内容生成的答案，问题定位效率提升了一个数量级。
特别是对于DeepResearch这类复杂的长流程任务，可能涉及几十甚至上百步的执行过程，如果没有这种可视化的追踪能力，调试简直是噩梦。
第三个特性：内置智能开发助手
UltraRAG 3.0在框架内嵌入了一个专门针对UltraRAG优化的AI助手。这个助手不是通用的ChatGPT，而是深度学习了UltraRAG的全部文档和最佳实践的专家助手。
这个助手能帮你做几件事：
配置生成：你只需要用自然语言描述需求，比如"我需要一个支持多路召回和重排序的检索流程"，助手就能自动生成标准的Pipeline YAML配置，你只需要稍作调整就能使用。
Prompt调优：助手能根据你当前的任务上下文，给出针对性的Prompt优化建议，帮你快速适配特定的业务场景。
答疑解惑：看不懂某个参数是什么意思？不确定某个逻辑该怎么写？直接问助手就行，不用跳出开发环境去翻文档。
这个设计的思路和Cursor等AI辅助编程工具类似，都是把"阅读文档→理解概念→编写代码"这个高心智负担的过程用AI来简化。虽然助手不能帮你写完整个项目，但作为一个懂UltraRAG的"导师"，它确实能大幅降低学习曲线。
第三部分：向量数据库与检索原理
在深入UltraRAG的使用之前，我想先花些篇幅讲讲向量数据库和检索原理。这部分知识对于理解和优化RAG系统至关重要，很多朋友在这里存在知识盲区。
什么是向量数据库？
传统的关系型数据库（如MySQL、PostgreSQL）是按照结构化的方式存储数据的，数据以表格的形式组织，支持SQL语言进行精确查询。但对于图片、视频、音频、自然语言这类非结构化数据，传统数据库就不太擅长处理了。
向量数据库的出现就是为了解决这个问题。它存储的不是原始数据本身，而是数据的向量表示（Vector Embedding）。这个向量可以理解为数据在高维空间中的"坐标"，语义相近的数据，其向量坐标也会比较接近。
举个例子，"苹果公司股价大涨"和"Apple Inc. stock price surged"这两句话虽然一个是中文一个是英文，用词完全不同，但它们表达的语义非常相似。如果用好的Embedding模型把它们转成向量，这两个向量之间的距离会很近。
向量数据库的核心能力是相似度检索：给定一个查询向量，快速找出数据库中与之最相似的K个向量。这种检索方式和传统的关键词匹配完全不同，它是基于语义的、模糊的、近似的。
向量相似度的计算方式
计算两个向量之间的相似度有多种方法，最常用的包括：
欧几里得距离（Euclidean Distance） 是最直观的距离度量，就是高中数学学过的两点之间的直线距离在高维空间的推广。距离越小，表示两个向量越相似。
余弦相似度（Cosine Similarity） 计算的是两个向量夹角的余弦值。不管两个向量的长度如何，只要方向接近，余弦相似度就高。值域是-1到1，1表示完全相同方向，-1表示完全相反方向。
内积（Dot Product） 是两个向量对应元素相乘再求和。如果向量经过了归一化处理（长度为1），内积就等于余弦相似度。
不同的应用场景可能适合不同的相似度度量方式，UltraRAG支持配置使用哪种方式。
向量索引加速检索
如果数据库里只有几千条记录，暴力计算每条记录与查询向量的距离也能接受。但当数据量达到数百万、数亿级别时，暴力检索的耗时就完全无法接受了。
这就需要向量索引（Vector Index） 来加速检索。常用的索引算法包括：
IVF（Inverted File Index，倒排索引） 的思路是先用聚类算法把所有向量分成若干个簇，检索时先找到查询向量最可能属于的几个簇，然后只在这些簇内进行精确搜索，大大缩小了搜索范围。
HNSW（Hierarchical Navigable Small World，分层可导航小世界图） 是一种基于图的索引结构。它把向量组织成一个多层的图结构，检索时从顶层开始，逐层向下导航，最终在底层找到最近的邻居。HNSW的检索速度和精度都非常优秀，是目前最流行的向量索引算法之一。
LSH（Locality Sensitive Hashing，局部敏感哈希） 的思路是设计一种特殊的哈希函数，使得相似的向量大概率被哈希到同一个桶里。检索时只需要在同一个桶内搜索，复杂度大大降低。
UltraRAG默认使用的Milvus向量数据库支持上述所有索引类型，开发者可以根据自己的场景选择最合适的。
Milvus向量数据库简介
UltraRAG选择Milvus作为默认的向量数据库，这是一个非常明智的选择。Milvus是Zilliz公司开源的云原生向量数据库，在GitHub上有超过2万颗Star，是目前最成熟、应用最广泛的开源向量数据库之一。
Milvus的几个核心优势值得一提：
第一是性能强悍。 官方数据显示，单节点的Milvus可以在几秒内完成十亿级别向量的检索。对于大多数应用场景来说，这个性能绰绰有余。
第二是功能丰富。 Milvus不仅支持向量检索，还支持标量过滤（比如在检索时加上时间范围、类别等条件）、混合查询、分区分片等高级功能。这些功能在实际业务中经常用到。
第三是云原生架构。 Milvus采用存储计算分离的设计，计算节点可以独立扩展。它原生支持Kubernetes部署，可以很方便地进行弹性伸缩。
第四是生态完善。 Milvus提供了Python、Java、Go、Node.js等多种语言的SDK，还有图形化管理工具Attu，以及托管云服务Zilliz Cloud。
在UltraRAG中，Milvus被封装成了一个标准的MCP Server，你不需要直接操作Milvus的API，框架会帮你处理好所有细节。但了解Milvus的基本概念，对于优化你的RAG应用还是很有帮助的。
第四部分：UltraRAG 3.0安装与环境配置
讲了这么多原理和背景，接下来进入实操环节。我会一步步带大家把UltraRAG 3.0跑起来。
环境要求
在开始安装之前，先确认一下你的环境满足以下要求：
操作系统：Linux（推荐Ubuntu 22.04/24.04）、macOS或Windows（通过WSL2）都可以。官方推荐使用Linux环境，因为后续涉及到的一些依赖和部署在Linux上最稳定。
Python版本：需要3.10或以上版本。可以用python --version命令确认。
CUDA版本（如果使用GPU）：12.2或以上。如果你有NVIDIA显卡并想用GPU加速，需要确保CUDA驱动已正确安装。没有GPU的话使用CPU版本也可以，只是推理速度会慢一些。
Docker（可选但推荐）：如果想快速体验，使用Docker是最省事的方式。确保Docker和Docker Compose已安装。
硬件资源：建议至少8GB内存。如果要运行完整的模型和向量数据库，16GB以上会更流畅。磁盘空间至少预留20GB。
方式一：使用Docker快速体验（推荐新手）
如果你只是想快速体验一下UltraRAG的功能，Docker是最快的方式。打开终端，执行以下命令：
# 克隆仓库
git clone https://github.com/OpenBMB/UltraRAG.git --depth 1
cd UltraRAG
# 拉取官方镜像（选择适合你环境的版本）
# CPU版本（没有GPU或者只想简单体验）
docker pull hdxin2002/ultrarag:v0.3.0-base-cpu
# GPU版本（有NVIDIA显卡，推荐）
docker pull hdxin2002/ultrarag:v0.3.0-base-gpu
# 完整版本（包含所有模型和依赖，体积较大）
docker pull hdxin2002/ultrarag:v0.3.0
# 启动容器（GPU版本）
docker run -it --gpus all -p 5050:5050 hdxin2002/ultrarag:v0.3.0
# 如果是CPU版本，去掉--gpus参数
docker run -it -p 5050:5050 hdxin2002/ultrarag:v0.3.0-base-cpu容器启动后，UltraRAG的Web界面会自动运行。打开浏览器访问 http://localhost:5050 就能看到界面了。
如果你想自己构建镜像（比如需要添加一些自定义依赖），可以这样做：
cd UltraRAG
docker build -t ultrarag:v0.3.0 .
docker run -it --gpus all -p 5050:5050 ultrarag:v0.3.0方式二：本地安装（推荐开发者）
如果你打算深度使用UltraRAG，或者需要进行二次开发，建议采用本地安装的方式。官方推荐使用uv这个Python包管理工具，它比pip更快更可靠。
第一步，安装uv（如果还没有的话）：
# macOS/Linux
curl -LsSf https://astral.sh/uv/install.sh | sh
# 或者用pip安装
pip install uv第二步，克隆仓库并安装依赖：
# 克隆代码
git clone https://github.com/OpenBMB/UltraRAG.git --depth 1
cd UltraRAG
# 使用uv同步所有依赖
uv sync --all-extras
# 激活虚拟环境
# macOS/Linux
source .venv/bin/activate
# Windows
.venv\Scripts\activate第三步，验证安装是否成功：
# 运行一个最简单的示例
ultrarag run examples/sayhello.yaml如果看到输出 Hello, UltraRAG v3!，说明安装成功了。
第四步，启动Web界面：
# 启动UI服务
ultrarag ui
# 或者指定端口
ultrarag ui --port 8080然后在浏览器中访问对应地址即可。
配置模型和服务
UltraRAG运行需要配置大语言模型（用于生成）和Embedding模型（用于向量化）。框架支持多种模型接入方式：
使用OpenAI API（最简单）：
如果你有OpenAI的API Key，只需要在环境变量中配置：
export OPENAI_API_KEY=your-api-key-here然后在Pipeline配置中指定使用OpenAI的模型即可。
使用本地模型：
UltraRAG支持接入本地部署的模型。你可以使用Ollama、vLLM、llama.cpp等工具在本地运行开源模型（如Qwen、LLaMA、ChatGLM等），然后配置UltraRAG连接本地的模型服务。
# 示例：配置使用本地模型
servers:
- name: generation
type: generation
params:
model: qwen3-7b
base_url: http://localhost:8000/v1 # 本地模型服务地址配置Milvus向量数据库：
如果你需要持久化存储向量数据，需要部署Milvus服务。最简单的方式是使用Docker Compose：
# 在UltraRAG目录下
docker-compose -f docker/milvus-docker-compose.yml up -d这会启动一个Milvus Standalone实例。然后在Pipeline配置中指定Milvus的连接信息。
莫潇羽@无忆研习社 提示：对于初学者，建议先用OpenAI API把流程跑通，等熟悉了再考虑切换到本地模型。本地部署虽然省钱但配置比较繁琐，一步步来比较稳妥。
第五部分：YAML Pipeline配置详解
YAML Pipeline是UltraRAG的核心概念，所有的RAG流程都是通过YAML配置文件来定义的。掌握了YAML Pipeline的写法，基本上就掌握了UltraRAG的精髓。
Pipeline的基本结构
一个UltraRAG的Pipeline配置文件主要包含两个部分：servers（服务声明）和pipeline（流程定义）。
# 这是一个最基本的Pipeline结构
servers:
- name: generation
type: generation
params:
model: gpt-4o
- name: retriever
type: retriever
params:
index: milvus
pipeline:
- name: step1
server: retriever
input: user_question
- name: step2
server: generation
input: retrieved_context让我逐一解释这些配置项的含义。
servers部分详解
servers部分声明了Pipeline会用到的所有MCP Server。每个Server都需要指定：
name：服务的名称，在后面的pipeline部分会用这个名称来引用。名称可以自定义，但建议起一个有意义的名字。
type：服务的类型。UltraRAG内置了多种类型：
generation：生成服务，用于调用LLM生成文本retriever：检索服务，用于从向量数据库检索相关内容evaluation：评估服务，用于评估生成结果的质量reranker：重排序服务，用于对检索结果进行重新排序- 还有更多类型，可以查阅官方文档
params：服务的参数配置，不同类型的服务有不同的参数。比如生成服务需要指定使用哪个模型，检索服务需要指定连接哪个向量数据库。
pipeline部分详解
pipeline部分定义了具体的执行流程。它是一个步骤列表，每个步骤包含：
name：步骤的名称，用于标识和调试。
server：这个步骤调用哪个Server，对应servers部分定义的name。
input：这个步骤的输入是什么。可以是：
- 用户的原始输入（如
user_question） - 前面某个步骤的输出（通过
{{step_name.output}}引用） - 固定的字符串或模板
output（可选）：指定这个步骤的输出变量名，供后续步骤引用。
循环与分支控制
UltraRAG支持复杂的流程控制结构，这是它区别于简单RAG框架的重要特性。
循环（Loop） 用于重复执行某些步骤：
pipeline:
- name: search_loop
loop:
times: 5 # 循环5次
condition: "{{need_more_search}}" # 或者基于条件判断是否继续
steps:
- name: search
server: retriever
input: "{{current_query}}"
- name: analyze
server: generation
input: "{{search.output}}"
- name: update_query
server: generation
input: "Based on the results, generate next query"分支（Branch） 用于条件判断：
pipeline:
- name: quality_check
server: evaluation
input: "{{generation.output}}"
- name: decide
branch:
condition: "{{quality_check.score > 0.8}}"
true: # 如果条件为真，执行这些步骤
- name: return_result
output: "{{generation.output}}"
false: # 如果条件为假，执行这些步骤
- name: retry_generation
server: generation
input: "Please improve the answer..."一个完整的实战示例
下面是一个相对完整的Pipeline示例，实现了多轮迭代检索和生成的逻辑：
# 多轮迭代RAG Pipeline
# 作者：莫潇羽@无忆研习社
servers:
# 大语言模型服务
- name: llm
type: generation
params:
model: gpt-4o
temperature: 0.7
max_tokens: 2000
# 向量检索服务
- name: retriever
type: retriever
params:
index: milvus
top_k: 5
# 重排序服务
- name: reranker
type: rerank
