# 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 文档

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

### 2.5 质量

#### CI 耗时优化（V0.6）

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

### 2.6 开发、部署与发布

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

### 2.7 生态

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