V0.6 & V0.7研发计划

一、时间线与里程碑

V0.6：2025/09/01 - 2025/11/30
V0.7：2025/12/01 - 2026/02/28

二、功能模块

2.1 RAG

2.1.1 工程能力

1. 沉淀 LazyRAG 能力到 LazyLLM（V0.6）

背景与目标

LazyRAG 是 LazyLLM 在检索增强生成（RAG）方向的关键模块，已经在实验性项目中验证了可行性与性能提升效果，在集团内部的RAG横评中也取得了最佳成绩。

然而目前其能力分散在原型代码与实验脚本中，且一部分能力和LazyLLM的框架形成冲突。本次迁移的目标是将 LazyRAG 核心能力沉淀到 LazyLLM 主框架中，消除LazyRAG中的无用代码的同时，大幅度提高LazyLLM中用于支持RAG的组件丰富度，提供一些用户友好的RAG场景的辅助能力（如参考文献引用等）。

验收标准

迁入模块的单元测试
对LazyRAG进行Code Review

时间规划

[ ] 计划在8.31日完成迁移

2. 多知识库宏观问答（V0.6）

背景与目标

当前LazyLLM的宏观问答能力仅能支持单知识库场景，用户在跨项目或跨部门时需要切换不同知识库，既降低了查询效率，也容易导致信息遗漏或矛盾。在企业级应用中，往往需要对多个知识库进行统一查询与融合，例如"产品说明书 + 技术方案库 + FAQ" 的综合问答。本次目标是构建多知识库统一接入与管理机制，让用户可以面向全局提出问题，系统自动选择相关知识库并融合答案，同时保证架构具备良好的扩展性与一致性，支撑未来数十个甚至上百个知识库的并行使用。

技术方案设计

关系型数据库作为知识库索引：新增一套关系型数据库（如 PostgreSQL），用于存储多知识库的元数据与 SQL-Call 信息。
动态关键词机制：每个 Document 对象可以通过一个函数设置额外关键词，系统为每个 kb-id 维护独立的关键词集合。
分库分表：每个知识库对应数据库中的一张独立表，存储文档的 metadata 与额外关键词字段，避免跨库查询时的数据干扰。
关键词修改问题：当某个知识库的关键词被修改时，需要评估是否必须重新解析所有已入库文档。为此设计两种策略：
延迟更新：仅对新入库文档使用新关键词，旧文档保留历史版本
批量再处理：通过后台异步任务对旧文档重新提取信息并更新索引
融合与路由：在查询时，系统根据用户问题提取关键词，在关系型数据库中快速匹配相关 kb，再进入向量库或其他检索引擎完成深度查询，最后由融合模块统一结果。

验收标准

功能正确性：系统能够在多知识库环境下准确识别用户问题涉及的知识库范围，并调用对应的检索引擎返回结果。
性能与响应：在支持 10 个及以上知识库的并行查询场景下，系统查询延迟应保持在可接受范围（如 P95 < 2 秒）。
可维护性与可扩展性：系统支持动态新增、删除知识库以及调整关键词而不影响已有查询。关键词修改策略（延迟更新或批量再处理）需按预期生效，并在更新日志中清晰记录。单元测试覆盖率应达到 90% 以上，包括多知识库组合查询、关键词修改、异常处理等场景。
可靠性与一致性：系统在节点宕机、数据库重启或检索引擎异常的情况下，仍能保证查询请求正确路由与恢复，返回结果保持一致性。跨库融合模块需支持幂等操作，避免重复计算或信息冲突。

时间规划

[ ] 计划在10.15日完成开发

3. RAG 横向扩容（多机协同）（V0.6）

背景与目标

当前 LazyRAG 已经在单机环境下展现出较好的性能，但在企业级应用场景中，RAG 的服务需求往往呈现高并发、长任务、跨地域调用等特征，单机部署无法满足生产级要求。尽管 LazyLLM 的部分模块已具备一定的横向扩展能力，例如向量检索服务可以通过分片扩展，但在 RAG 模块中仍存在明显不足：其一，ServerModule 的自动启动机制尚未支持集群环境下的负载均衡与动态扩缩容，导致目前的多机部署需要人工干预；其二，RAG 中的 Processor 组件依赖进程内存保存状态，无法天然实现跨节点任务拆分与共享，限制了多机协同的能力。本次目标是通过重构 ServerModule 的服务管理逻辑与 Processor 的状态隔离与持久化方案，使得 RAG 模块能够在多机环境下自动扩缩容、弹性调度任务，从而实现"多机协同"的能力，满足集团内部与外部客户对大规模知识检索的需求。

技术方案设计

基于现有的 ServerModule，引入 Ray 集群作为基础执行框架。利用 Ray 的 Actor 与 Ray Serve 功能，将 RAG 模块封装为可水平扩展的服务实例，每个 Actor 可在集群中的任意节点上运行。Ray Serve 提供内置的路由与负载均衡能力，自动将请求分发至健康实例，同时支持版本控制与滚动更新。为了实现弹性扩缩容，可结合 Ray Autoscaler，根据系统负载指标（如 QPS、延迟、CPU/GPU 利用率）动态增加或减少 Actor 数量，实现无缝扩展。此外，Ray 内置的全局状态管理和任务调度机制，使得每个 Actor 无需显式依赖外部服务注册发现组件，集群管理与调度均由 Ray 控制，从而简化了多机协同逻辑，实现高可用、低延迟的分布式 RAG 服务。

而针对 RAG Processor 的内存依赖问题，引入共享存储与缓存方案。短时态数据通过分布式缓存（Redis/Memcached）存储，长时态与任务状态则落盘到分布式数据库（PostgreSQL 或 TiDB），通过唯一任务 ID 建立幂等机制，避免多节点重复计算。此外，检索结果缓存采用一致性哈希策略分布在多实例间，以减少热点与跨机数据传输。整体架构保证节点的无状态化，使得任何请求均可被分配至任意实例，进而支撑多机协同。

验收标准

功能层面：① ServerModule 能够在多机环境中部署任务，并能支持动态扩缩容；② 当节点宕机或下线时，系统能自动摘除并在路由层恢复服务；③ Processor 能够将状态信息正确存储在共享层，保证任务在不同节点间迁移时仍能被正确恢复。
性能层面：在三台及以上节点环境下进行压力测试，系统可线性扩展至单机 QPS 的 2.5 倍以上，并且 P95 延迟不超过单机时的 1.2 倍。
可靠性方面：在动态扩缩容过程中，用户请求不中断或出现错误响应；在节点随机故障注入测试中，系统整体可用性 ≥ 99.9%。

时间规划

[ ] 计划在9.19日完成开发

4. 知识图谱接入至少 1 个开源框架（V0.6）

背景与目标

当前 LazyLLM 内部是没有知识图谱的。考虑到知识图谱模块尚未形成统一体系，功能零散且易用性不足，无法有效支持企业级知识融合与智能检索，且自研知识图谱成本高、开发周期长且维护复杂，本次目标是接入一个已有的开源知识图谱框架（如 LightRAG 或类似框架），优先选择功能单一、依赖轻量的框架，以降低集成复杂度和运维成本。

接入后，知识图谱能够与现有 RAG 模块深度融合，实现检索增强生成（RAG）能力的提升，同时支持知识图谱的动态更新，包括新增实体、关系或修改属性，从而保证在快速变化的企业知识环境中仍能提供准确、可追溯的答案。该目标既提升知识图谱的实用性，又避免重复造轮子，加快研发效率。

技术方案设计

技术方案包括框架选型、接入集成、数据更新与融合检索四部分。

首先进行开源框架选型，优先考虑 LightRAG 等轻量知识图谱库，要求提供 API 接口，可支持 Python 调用和嵌入现有 RAG 流程。

接入集成时，将知识图谱一键部署为独立服务节点，通过 RPC 或 HTTP API 暴露知识查询与更新接口。对于动态更新，设计异步任务队列，实现对新文档的实体与关系抽取并同步更新到知识图谱，同时保留版本历史以支持回滚。

融合检索方面，用户查询先经过 RAG 检索模块提取候选文档，再结合知识图谱进行关系推理或路径扩展，最后将结果统一返回，确保检索结果的准确性和丰富性。

验收标准

功能上：知识图谱能够正确接入 RAG 模块，支持动态新增、修改和删除实体及关系，且对更新后的知识可立即被检索到。
融合效果上：RAG 查询结合知识图谱后，应比纯向量检索提高准确率或召回率，并能返回清晰可追溯的知识来源。

时间规划

[ ] 计划在11.15日完成开发

5. 数据切分策略 ≥20 种（V0.6）

背景与目标

当前 LazyLLM 的数据切分策略较为单一，主要包括基于句子的切分（sentence splitter）以及利用大模型提取关键词、生成摘要或构建 QA 对等策略。这些方法在简单文本场景下能够满足基本需求，但对于语义复杂的文档、结构化表格、代码文件、多模态内容或长篇报告等，现有策略的效果有限，容易导致信息丢失、检索不精准或生成上下文不连贯。因此，本次目标是扩充至少 20 种数据切分与转换策略，覆盖 RAG 高频使用场景，包括：基于语义的自然段切分、主题切分、代码按函数/类切分、表格按行列切分、多模态内容切分、摘要增强切分、QA 对生成切分等。同时确保新策略可灵活组合，支持不同文档类型的自适应切分，提高 RAG 检索的粒度和精度，增强系统在多场景下的适用性和稳定性。

验收标准

至少实现 20 种切分策略，并支持灵活组合应用于不同类型文档；策略执行应正确生成切分片段及对应元信息，保证信息完整性。覆盖度上，策略应覆盖文本、代码、表格、PDF、多模态内容等高频 RAG 场景。

时间规划

[ ] 计划在9.19日完成开发

6. RAG RootNode重构（V0.6）

背景与目标

当前LazyLLM的RootNode比较混乱，而且受Reader的影响比较大，导致不同文档的RootNode的粒度是不一样的。部分文档即使很长，RootNode也是1个，有的文档即使很短，也有很多RootNode。

目标是对RootNode做一个整理，使得每个文档都只有一个RootNode。

技术方案

对RootNode做处理，变成一个类似于"MixDocNode"的数据结构，可以存储文字，图片，表格等信息，顺序存储，并通过某种方式可以生成markdown并展示。

同时考虑root-node可以做一个分级，用一个top-root，top之下再设置block（即将block做成默认group），文本，图片，表格等，这样reader读取完之后，将结果分别存储到对应的node-group中。

验收标准

每个文档在解析完成后，都只生成一个RootNode，该RootNode包含全文信息。

时间规划

[ ] 9.20日开发完成

2.1.2 数据能力

1. 表格解析（V0.6 & V0.7）

背景与目标

目前 LazyLLM 的数据解析能力主要集中在文本与基本文档，缺乏对表格类数据的解析与结构化能力。实际业务场景中，大量知识以 Excel、CSV 或 Word/PDF 内嵌表格的形式存在。如果不能高效和正确的解析，知识会丢失或难以被检索。目标是提供统一的表格解析能力，将不同来源（Office 文档、PDF、图片识别）的表格内容抽取为结构化 JSON/数据库格式，便于后续索引、检索与生成任务。

技术方案设计

输入格式支持：
Excel/CSV → 直接读取（pandas/openpyxl）
Word 表格（docx） → python-docx 提取
PDF 表格 → MinerU读取
图片表格 → OCR（paddleocr、tesseract）+ 表格结构识别（TableMaster、DeepDeSRT）
表格结构化：
标准化输出为 JSON 或 DataFrame等结构化格式
支持单元格合并、多表头、多 sheet 的解析
保留行列坐标、原始格式信息（例如颜色、加粗用于强调）
语义增强：
基于大模型进行表格语义补全（如识别隐藏表头、对齐上下文）
表格与上下文正文的关联（表格标题、所在段落）
表结构的简要说明，及特征信息的提取

验收标准

支持 Excel、CSV、Word、PDF 至少 4 种表格来源的解析
支持合并单元格、多表头、多 sheet 的还原
支持表格与上下文语义绑定

时间规划

V0.6：实现 Excel/CSV/Word/PDF 解析，完成结构化抽取
V0.7：实现 OCR 表格解析，增强语义补全与 Text-to-SQL与Code Interpret

2. CAD 图片解析（V0.7）

背景与目标

工程、制造、建筑等行业大量使用 CAD 图纸作为主要知识载体，现有 LazyLLM 缺乏 CAD 图片（如 .dwg、.dxf、导出的 PDF/PNG）的解析能力，导致 RAG 在这些领域的应用受限。目标是提供 CAD 图纸的解析能力，包括文字识别、符号识别、结构关系抽取，并转化为可索引的知识片段，支持查询与问答。

技术方案设计

输入格式支持：
CAD 原始格式（DWG、DXF） → 通过 ezdxf 等库解析
CAD 导出 PDF/图片 → OCR + 结构识别
内容抽取：
图纸中的文本标注、尺寸信息 → OCR 提取
图元（线条、圆、块引用等） → CAD API 解析
符号库（如电气符号、建筑符号） → 规则 + 模型识别
语义增强：
基于大模型进行图纸语义总结（如提取"该图纸为某楼层平面图，包含 xx 房间，管道走向为 xx"）
建立图元之间的关系图（类似 mini-knowledge graph）
与 RAG 融合：
将 CAD 图纸内容转化为文本/知识图谱节点
支持基于自然语言的检索（如"找到地下二层所有风管直径"）
支持动态更新 CAD 知识库（增量导入）

验收标准

支持 DWG/DXF/PDF 至少三种 CAD 输入
支持抽取图纸中的文字标注、尺寸、符号
支持输出结构化结果（JSON/Graph）
支持在 RAG 中基于 CAD 内容进行问答

时间规划

计划在V0.7开始支持

2.1.3 算法能力

1. 结构化文本（CSV 等）的问答（V0.6）

背景与目标

目前 LazyLLM 支持非结构化文本（文档、PDF 等）的检索增强问答，但对于结构化数据（如 CSV、Excel、数据库表格），仅能按照RAG的流程进行分析和处理，而不能随心所欲地对我们的表格进行分析和问答。

在用户实际场景中（财务报表、用户行为日志、实验结果表、销售流水等），结构化数据问答需求极高。

目标：支持用户上传 CSV/Excel，能够进行自然语言问答，并返回结果（包括聚合计算、筛选、排序、可视化）。

技术方案设计

暂无设计

验收标准

用户能上传 CSV/Excel 并进行问答
系统能自动识别字段并根据用户问题生成正确答案（准确率 ≥ 70%）
支持多轮追问（如"上一问结果里取前 10 条"）
返回结果可选择表格/图表

时间规划

V0.6：实现 CSV 问答（Polars + NL2SQL）
V0.7：支持复杂聚合、跨表 join、可视化

2. 多跳检索（V0.6）

背景与目标

在现有 RAG 系统中，大多数检索过程是单跳的：用户问题 → 检索相似文档 → 生成回答。但在实际应用中，很多问题需要跨多段内容才能完整回答，例如：

从某个文段出发，找到其参考文献，再从参考文献中找到关联论据，最终拼接完整答案
技术文档中，API 的描述可能引用到另一个模块，再进一步指向实现细节，需要层层跳转
学术论文综述中，需要从原始结论追溯实验数据，再结合方法部分进行综合解释

目标是构建一个不依赖知识图谱的多跳检索机制，能自动沿着"引用/关联线索"逐步扩展检索范围，直至整合足够的上下文，支持复杂问答与推理。

技术方案设计

【本方案由大模型给出，最终以实际策略为准】

跳检索框架
基于已有向量检索（BM25 / dense retriever），在初始检索的文段中抽取可能的关联线索（如引用、上下文提示、关键词、外部链接）
结合 LLM，判断是否需要发起二次检索
支持递归检索，直到达到最大跳数或置信度收敛
线索提取机制
引用检测：检测"如图所示""见表 X""参考文献 [12]"等引用性语句
实体关联：利用命名实体识别（NER）或语义聚类，发现与原问题强相关但未覆盖的实体
因果/上下游提示：识别"基于""因此""进一步"等逻辑提示，扩展上下文
跳跃策略
前向扩展：从文段出发，跟随引用或链接跳到目标文段
反向追溯：根据引用编号或关键词，追溯原始出处
横向扩展：检索同类实体或同主题文档，补全知识
结果整合
使用链式总结（chain-of-thought summarization），将多跳检索结果合并为一个连贯答案
引入答案可追溯性：在回答中列出每一步检索的来源文段，增强可解释性

验收标准

在学术综述、技术文档、FAQ 知识库等场景中，能明显提升复杂问答的正确率
检索过程可配置最大跳数、置信度阈值，避免无界扩展
输出答案中包含多源内容整合，且具备可追溯性（指明关联链路）

3. 信息冲突处理（V0.7）

背景与目标

不同知识库或数据源可能存在冲突信息（如多个版本的合同，不同来源的统计数据，不同时间和行政级别的法律法规）。目前 RAG 系统通常直接拼接检索结果，可能导致模型"编造"答案。

目标：引入信息冲突检测与处理机制，使系统能明确提示冲突并给出可选答案。

验收标准

系统能识别并正确地冲突，而非默认合并。

时间规划

V0.7开发完成

4. AgenticRL & 代码解题工具链支持（V0.7）

背景与目标

在代码问答与算法题求解中，单次生成往往错误率较高。引入 AgenticRL（强化学习驱动的智能体），通过多次尝试与环境反馈优化解答。

目标：支持自动代码解题（如 LeetCode/Codeforces 子集），并在环境中执行与修复。

验收标准

支持LeetCode中的前100题的解决

时间规划

V0.7开发完成

2.2 功能模块

1. 记忆能力（V0.6）

背景和目标

当前大模型的长期记忆理应由后端独立系统负责，算法框架本身并不内置存储或检索能力。然而在实际应用中，算法框架可以提供一套辅助工具和策略，帮助算法模块在后端生成、更新和管理记忆。例如，提供可插拔的记忆接口、缓存策略、自动触发记忆更新的机制，以及跨会话的上下文回溯能力。

目标是在不改变架构核心理念的前提下，为开发者提供"轻量记忆增强"，使应用能够在对话中保持一致性、理解历史行为，并辅助用户长期任务的完成。

测试方案

构造多轮长对话场景，验证记忆回溯的一致性
压测高并发下的记忆生成和更新延迟
验证断电/进程重启后记忆的完整性与正确恢复
设置模拟任务链，观察模型是否能正确依赖历史记忆完成目标

时间规划

[ ] 11.15日之前完成

2. 分布式 Launcher（V0.7）

背景和目标

当前 LazyLLM 启动的进程信息仅存储在内存中，且父进程与子进程存在强绑定关系，一旦父进程退出，子进程也随之被杀死。这种模式限制了横向扩展能力，难以在分布式场景下稳定运行。

目标是将进程信息持久化到数据库，并实现父子进程解耦，使得父进程可以弹性扩容和横向调度。同时需要设计回收机制，确保在所有主进程退出时，子进程不会成为僵尸进程，维持系统整体稳定性。

测试方案

模拟在主进程分布式启动的情况下，启动子进程的父进程先退出，验证子进程是否能正确保留
模拟在分布式启动的情况下，启动子进程的父进程先退出后，所有主进程都退出，验证子进程是否能正确清理

时间规划

计划V0.7完成

3. 数据库 Globals 支持（V0.6）

背景和目标

现有的 Globals 模块完全依赖内存存储，无法满足分布式环境的扩展需求。随着应用复杂度提升，需要让 Globals 可灵活选择后端，包括内存、Redis、SQL 等不同存储。这样不仅可以适配不同规模和部署环境，还能增强系统容灾能力。

目标是实现一个统一的 Globals 抽象层，使开发者可以无感切换不同存储方案，同时保证数据一致性和高可用性。

测试方案

单机模式下验证内存、Redis、SQL 三种模式的正确性。

时间规划

[ ] 计划10.30日之前开发完成

4. ServerModule → MCP 服务（V0.7）

背景和目标

目前 ServerModule 依赖 FastAPI 启动服务，但在分布式场景下，缺乏容错和多实例负载均衡能力。目标是将其改造为 MCP（Model Context Protocol）服务，以统一协议、降低接入门槛，并提供天然的多实例调度与容灾能力。同时借助RAG 横向扩容（多机协同）的成果支持容错和负载均衡，能够显著提升框架在生产环境的稳定性与可维护性。

测试方案

测试能否将任意函数打包成一个MCP服务，并直接被智能体所调用

时间规划

V0.7版本开发

5. Mini沙箱 & 线上沙箱服务集成（V0.7）

背景和目标

在强化学习（RL）或任务执行过程中，常常需要动态执行用户或模型生成的代码。单纯依赖本地沙箱，难以满足安全性和扩展性需求。

目标是： 1. 添加Mini沙箱的能力，在用户本地可以部署一个小的沙箱服务 2. 集成线上沙箱服务，使得代码执行可以通过远程隔离环境完成

从而避免对主进程造成污染或安全风险。同时支持资源限额、超时控制和日志追踪，以便更好地监控和优化模型训练与推理过程。

测试方案

针对Mini沙箱和线上沙箱服务，验证： - 基础正确性：执行简单代码并比对输出一致性 - 安全性：模拟恶意代码，验证沙箱隔离效果 - 并发性：同时发起大规模执行请求，验证稳定性 - 监控性：检查日志与指标是否完整收集

时间规划

计划V0.7完成

2.3 模型训推

1. 支持 OpenAI 接口的部署和推理（V0.6）

背景和目标

LazyLLM 在设计之初，推理框架主要参考 vLLM 或 TGI（Text Generation Inference）的接口格式，这在早期满足了大多数开源大模型推理的需求。然而，随着行业的演进，OpenAI 接口已经逐渐成为事实上的标准，很多生态工具和应用都围绕着 OpenAI 的 API 格式构建。当前 LazyLLM 已具备使用 OpenAI 格式的能力。

目标：需要在部署阶段允许用户灵活选择 TGI 或 OpenAI 接口，并确保在使用 OpenAI 接口时能够无缝对接线上模型。这样既能保持对开源框架的兼容性，又能让用户轻松迁移已有应用。用户无论选择哪种推理接口，都能获得一致的调用体验。

测试方案

单元测试，验证Trainable选择OpenAI格式部署的服务，能够使用Trainable和OnlineChatModule连接

时间规划

[ ] 10.30日完成

2. 提示词仓库集成（2-3 个）（V0.6）

背景和目标

当前 LazyLLM 仅在少量核心模块内手工编写了部分提示词，这种方式虽然灵活，但缺乏系统性和可重用性，用户往往需要自行维护和设计提示词，增加了上手成本。随着提示工程逐渐走向专业化，社区中已经出现了多个开源提示词仓库，积累了大量经过验证的高质量模板。因此，LazyLLM 有必要在框架内集成 2-3 个主流提示词仓库，用户可通过便捷的接口直接调用常见场景下的提示词，大幅减少重复劳动。

目标是：在保证灵活度的同时，提供即开即用的提示词模块，降低用户设计成本，提升系统的"开箱即用"体验。

测试方案

单元测试，测试选到的提示词能正确的用于模型推理

时间规划

V0.6版本开发完成9月30日

3. 智能模型类型判断 + auto-finetune 重构（V0.6）

背景和目标

目前 LazyLLM 的模型类型判断机制依赖于模型名称的简单匹配，这种方式缺乏智能化，规则模糊且可扩展性不足。例如，有些模型名称相似但能力不同，系统容易误判。与此同时，auto-finetune 模块在框架选择逻辑上过于复杂：早期方案通过提前计算不同框架的性能来决定使用哪个框架，虽然准确但过于繁琐。

我们希望在新版本中进行重构：模型类型判断需要更智能化，例如基于模型权重信息或结构自动识别，用户也可以显式指定类别；auto-finetune 则应简化逻辑，改为优先级排序（框架优先级 + 卡数分配策略），从而保证更高的可用性和扩展性。

测试方案

使用多种模型（大模型、Embedding、Rerank，VL 等）验证智能判断是否准确
测试用户显式传入模型类别时，系统是否能正确覆盖默认逻辑
测试 auto-finetune 在不同硬件资源下是否能合理分配显存和卡数
验证finetune框架优先级机制是否能覆盖常见使用场景

时间规划

V0.6版本开发完成9月30日

4. 统一微调和推理提示词，并给出微调示例（V0.7）

背景和目标

在当前版本中，LazyLLM 的微调和推理环节分别使用了不同的提示词体系，这导致微调得到的模型无法直接应用于推理，需要额外做格式适配，增加了用户的工程负担。为了解决这一问题，我们需要将微调和推理提示词统一化，建立一套通用的提示词体系。这样一方面能够保证微调模型开箱即用，另一方面也能降低开发和维护的成本，提升整个框架的可扩展性与一致性。最终目标是：用户只需维护一套提示词，即可同时覆盖微调和推理两个环节，提升全流程的连贯性。

测试方案

单元测试，验证TrainableModule的微调和推理能否统一使用同一套提示词

时间规划

V0.7版本开发完成

5. GRPO 全链路支持（V0.7）

背景和目标

GRPO（Generalized Reinforcement with Policy Optimization）是一种新兴的强化学习训练范式，在大模型对齐和自适应优化中表现出色。为了让 LazyLLM 保持前沿能力，我们需要在框架中提供 GRPO 的全链路支持，覆盖 Reward、Policy、Value 等关键模块，并允许用户自定义函数。这样不仅能够让用户快速上手 GRPO 进行实验，还能在特定领域实现定制化优化。例如，科研用户可以自定义 Reward 函数来评估生成结果是否符合学术规范，工业用户可以通过自定义 Policy 来优化生成速度与成本。最终目标是：LazyLLM 能够为用户提供一个端到端的 GRPO 训练与推理解决方案，既具备灵活性，又保持工程化落地能力。

测试方案

在小规模模型上验证流程的正确性，训练收敛性和性能提升情况。

依赖

沙箱

时间规划

V0.7版本开发完成

2.4 文档

API 文档完善，所有非私有接口和类都有Google风格的API文档（V0.6）
CookBook 文档完善（50 个案例 + 对比主流开源框架）（V0.6）
Environment 文档完善（安装方式 + 包策略）（V0.6）
Learn 文档完善（学习LazyLLM的路径）（V0.6）

2.5 质量

CI 耗时优化（V0.6）

日常测试过程中，模型部署和输出Mock 化，使得CI的耗时降低至10 分钟
建设每日构建和每周构建机制，高耗时测试挪到每日构建中，全量测试挪到每周构建中

2.6 开发、部署与发布

环境隔离与自动建设（V0.6）
Debug 优化（V0.7）
过程监控（输出 + 性能）（V0.7）

2.7 生态

LazyCraft 开源（V0.6）
LazyRAG 开源（V0.6）