开源！十人搞定上百项目？揭秘商汤“会自己改算法代码”的智能知识底座
不是 RAG 过时了，是你用的 RAG 还停在 2024 年。当别人的知识库能自己改代码、自己跑 A/B 测试、自己进化的时候，你的团队还在手工造问答对和调 topK —— 这差距，只会越来越大。
不是 RAG 过时了，是你用的 RAG 还停在 2024 年。
当别人的知识库能自己改代码、自己跑 A/B 测试、自己进化的时候，你的团队还在手工造问答对和调 topK 。
两者看起来都叫“知识库”。但中间隔着的，已经不是一点优化，而是一代系统的差距；这差距，只会越来越大。
RAG 死了？别被哗众取宠的人给忽悠了
这两年，"RAG 已死"的声音越来越多。
有人说 Agent 才是未来，有人说上下文窗口越来越长，直接把文档塞进模型就够了。但你看一眼这些所谓"抛弃 RAG"的方案——底层依然在做知识检索、上下文组织和信息筛选，本质上还是 RAG，只是穿上了皇帝的新装。
事实上，死的并不是 RAG，而是"接一个向量库、连一个大模型"式的玩具级 RAG，以及依然还活在2024年的那些开发者。
Agent 越强，反而越依赖高质量的上下文工程。所以，RAG 作为上下文工程的重要技术选型之一，它并不是 Agent 的替代品，而是 Agent 的地基。地基不牢，上面盖什么都是危楼。
但今天我们不聊"RAG 该不该死"，因为不用聊，聪明的你一定能理解，Agent要和RAG一起用，才能在你的场景下发挥更大的价值。我们聊点更刺激的——
同样是 RAG，你的和别人的，差在哪里？为什么别人借着新时代的Agentic-RAG挣得盆满钵满，你却曾被营销RAG已死的言论搞得无比焦虑？
长话短说，我们开源了LazyMind，这是在近百个真实企业项目（其中不乏百万级）里反复打磨后，沉淀出来的知识管理底座。跟市面上大多数 RAG 系统比起来，它多了四样东西：
🧠 智积阅累：越用越懂你，而不是越用越蠢。 技能团队复用、记忆有审阅、词表自动沉淀、有边界地持续成长。不再每轮对话都像换了个人，不再把经验锁在某个同事脑子里。
🔧 算法跃迁：不是改 Prompt，是改代码。 不同于其他软件改改提示词或调调参数，我们的流程是受控的软件工程迭代：发现效果变差 → 自动生成评测集 → 多 Agent 协同诊断根因 → 在隔离沙箱里改 Python 代码 → 跑 A/B 测试算 p-value → 通过守护指标才允许上线。
🎯 千人千面：让每个知识库长出自己的大脑。 研发部关心版本和接口，客服部关心流程和话术，法务部关心条款和例外——凭什么用同一套切块、同一套召回、同一套排序？LazyMind 让每个知识库拥有独立的检索策略、术语体系、评测标准和优化路径。从"千库一算法"到"一库一策略"。
🔍 洞若观火：答错了，一眼就知道错在哪。 每次回答的完整过程被自动记录下来：AI 查了哪些资料、哪些被跳过了、哪一步花了多长时间、最终用了什么上下文来生成答案。出了 badcase，不用一群人围着日志猜，直接点到具体环节——是检索没命中，还是排序把关键文档挤下去了，还是模型自己没用上给它的上下文。
最关键的是——它已经开源了。apache 2.0协议，免费商用！又一次，我们把工业级的项目，交到了大家的手中。
一、为什么你的知识库，上线之后就开始"降智"
很多团队做 AI 知识库，都走过同一条路：
Day 1：拿几份文档做 Demo，问几个提前准备好的问题，大模型回答流畅、引用清晰、效果惊艳。所有人觉得："AI 终于能用了。"
Day 30：用户开始用真实方式提问。扫描件、表格、飞书 Wiki、历史资料混在一起。badcase 越来越多。有时候能答对，有时候完全答偏。没人知道问题出在文档解析、检索召回、Prompt，还是模型本身。
Day 90：团队陷入地狱循环——人工分析 badcase → 调参数 → 改 Prompt → 重新上线 → 继续看效果。更绝望的是，只要换一批文档、换一个业务场景，这个过程就得重新来一遍。
这不一定是你的团队不行，更有可能是你用的工具不行。
市面上大多数 RAG 产品，本质上是在把研发责任转嫁给用户。chunk size 设多少？topK 调多大？rerank 阈值怎么配？——这些都是产品的默认行为该解决的问题，不是你作为使用者应该研究的事。
更致命的是：企业本身一直在变化。 新业务术语、新流程、新员工问法，都在持续改变组织的知识结构。系统如果不能持续理解这些变化，再强的模型也会慢慢"听不懂你们公司"。
大多数知识库项目不是死于模型不够强，而是死于：它只能"搜索"，不会"积累"；只能读文档，无法持续理解你的业务。
二、我们先不聊What、How和Why，看数据
在聊细致的聊LazyMind之前，先看一组我们和 RAGFlow 的实测对比。
我们拿了 42 份真实的文档——复杂 PDF、企业规划文件、行业研究报告、多栏排版、表格、图片混排——做了一次完整测试。
准确率方面，在我们自建的企业级评测集上（覆盖文档结构还原、表格识别、跨页内容关联、长文本知识召回、多段推理问答等多个维度），LazyMind 整体准确率达到 88.4%；相比之下，RAGFlow 在同等指标上的表现为 80.1%。附评测文档和题目链接（https://huggingface.co/datasets/LazyAGI/lazymind_demo_data/）
- 评测展示
我们分析了结果，发现在以下企业高频场景中，我们的优势会更加明显：
-
*评测说明：本次采用大模型自动化并行评测方案，以事实匹配度为核心评价维度开展答题质量量化打分。评测设定统一固化评分准则，仅校验答案核心事实信息契合程度，剔除行文风格、语句流畅度等无关因素影响，划分六档标准化分值梯度。通过固定推理参数、锁定随机种子、异常重试机制抑制评分漂移，完成单样本分值判定后，汇总计算整体准确率均值，最终输出结构化评测结果数据。
-
示例1
-
问题：2026 年 6 月员工想要申请事假，按照现行生效的公司管理制度，每月事假最多可以请几天？
-
答案：按照2026 年 5 月起执行的新版公司制度规定，员工每月事假不得超过2 天。
-
挑战分析：旧版流程文档和新版制度同时存在，系统需要判断哪个更权威、更新。
-
LazyMind
-
回答：根据检索上下文[1]中第五条考勤管理第3点规定：“事假每月不得超过2天”。因此，2026年6月员工申请事假，每月最多可以请2天。
-
评价：回答正确且严谨，精确的条款级溯源，展现了优秀的时间逻辑推理能力。
-
-
RAGFlow:
-
回答：根据知识库中的《公司假期管理制度》（v5.1版本）规定：
-
**每月事假最多可以请3天（含）。
-
** 相关规定：
-
- 事假每月不超过3天（含）
-
- 超出3天的，需提供证明材料或经上级领导审批
-
如有具体疑问，建议咨询人力资源部门确认最新的制度规定。
-
评价：回答错误，新版制度自2026年5月起已调整为每月事假最多2天，而不是3天。
-
-
-
示例2
-
问题：总结本次Q3规划的原始方案、执行问题以及最终调整内容
-
答案：以产品迭代、用户增长、商业变现为核心主线，公司核定季度总预算850万元，其中研发预算400万元；要求8月30日前完成APP V3.0版本上线，市场新增合作渠道15家、付费用户12000人，计划补充10名技术人员。从部门周报反馈的执行情况来看，当前Q3规划落地进度滞后，研发整体完成率仅58%，存在后端人力缺口2人、第三方支付接口审批卡顿的问题，预判无法按照原定时间完成版本上线。针对Q3规划执行卡点，会议纪要明确调整方案：将APP上线时间延后至9月10日，合作渠道指标下调为12家，研发预算追加25万元；要求7月5日前补齐后端人员，可启用外包人员辅助开发，同时建立每周三Q3规划进度同步会议，规范后续管控流程。
-
挑战分析：当"Q3规划"同时出现在战略文档、部门周报和会议纪要中，系统需要区分不同上下文、合并相关信息。
-
LazyMind
-
-
回答：
-
根据检索上下文，Q3规划的原始方案、执行问题及最终调整内容如下：
-
- **原始方案**：Q3规划以“产品迭代+用户增长+商业化变现”为核心，要求APP V3.0在8月30日前全量上线，新增合作渠道不少于15家，线下沙龙3场，研发预算400万元，补充10名技术开发人员。
-
- **执行问题**：研发人力缺口2人，现有人员兼顾旧版本维护导致迭代延期；第三方支付接口审批卡顿，延迟3-5个工作日；整体研发进度慢于原定节点（原计划完成70%，实际完成58%）。
-
- **最终调整内容**：人力资源部需在7月5日前完成2名后端开发招聘，允许临时启用3名外包人员，研发预算上调25万元；V3.0上线时间延后至9月10日；新增渠道目标从15家调整为12家；华南区域拓展周期延后半个月；因客观因素导致的版本延期不做扣分处理，但9月10日仍未上线则扣除部门季度绩效10%。
-
评价：回答正确，核心数据都已覆盖，总结凝练。
-
-
RAGFlow:
回答：根据知识库中的文档，我为您总结Q3规划的原始方案、执行问题及最终调整内容：
-
## 一、原始方案（ID:1）
-
### 1. 产品研发
-
- **V3.0版本**：需在8月30日前完成全量上线 -
-
**优化模块**：支付链路、会员体系、智能推荐三大核心模块
-
- **营销插件**：新增2个营销活动插件，为四季度大促做好技术铺垫
-
### 2. 市场运营 - **渠道目标**：新增合作渠道不少于15家
-
- **用户目标**：季度新增付费用户12000人，留存率提升至45%以上
-
- **品牌活动**：配合线下行业沙龙3场，重点开拓华南区域中小企业客户
-
### 3. 人力与预算
-
- **总预算**：850万元（研发400万、市场300万、行政150万）
-
- **人员配置**：补充10名技术开发人员，优先保障后端研发团队
-
- **扩招策略**：本季度不再大规模扩招
-
### 4. 风险监控
-
- 重点监控竞品低价冲击、服务器稳定性、渠道签约延期三类风险
-
## 二、执行问题（ID:2）
-
### 1. 研发进度滞后
-
- 支付链路模块开发完成65%，会员体系功能开发完成50%，智能推荐算法调试尚未启动 - 整体研发进度略慢于原定时间节点，原计划本周完成70%开发量，实际仅完成58%
-
### 2. 人力严重不足
-
- 后端研发人力缺口2人
-
- 现有开发人员兼顾旧版本维护，导致新版本迭代延期
-
### 3. 第三方接口卡顿
-
- 第三方支付接口审批流程卡顿，预计延迟3-5个工作日
-
### 4. 风险预警
-
- 若人力问题无法在7月上旬解决，V3.0版本上线时间将延后至9月上旬，无法达成8月30日上线要求，存在季度考核扣分风险
-
## 三、最终调整（ID:0）
-
### 1. 研发事项调整
-
| 项目 | 原始方案 | 调整后 |
-
|------|----------|--------|
-
| V3.0上线时间 | 8月30日 | 延后至**9月10日** |
-
| 人员补充 | 10名技术开发人员 | **2名后端开发人员**（7月5日前到岗）+ **3名外包人员** |
-
| 研发预算 | 400万元 | **上调25万元**（追加外包费用） |
-
### 2. 市场事项调整
-
| 项目 | 原始方案 | 调整后 |
-
|------|----------|--------|
-
| 新增渠道目标 | 不少于15家 | 调整为**12家** |
-
| 线下沙龙 | 3场 | 维持**3场**不变 |
-
| 华南区域拓展 | 按原计划 | **延后半个月**，降低上半年签约压力 |
-
### 3. 考核调整 - 因客观因素导致的版本延期，**不做扣分处理**
-
- 若9月10日仍未完成上线，扣除部门季度绩效**10%**
-
- 所有资料统一归档至企业知识库
-
### 4. 协同要求
-
- 每周三下午召开Q3规划进度同步会
-
- 产品部同步研发进度，市场部同步渠道签约数据
-
- 风控部汇总风险报表
-
## 总结
-
本次Q3规划调整主要针对**执行层面的人力缺口和进度滞后问题**进行纠偏，通过**延迟上线节点、调整渠道目标、增配外包人员**等方式，在保证核心目标（V3.0上线、新增12家渠道、3场沙龙）的基础上，合理释放执行压力，确保季度规划能够落地执行 [ID:0][ID:1][ID:2]。
-
评价：回答正确，核心数据都已覆盖，但过于冗长。且缺失了原方案的核心。
-
-
-
示例3
-
问题：樺欣控股與雅天妮集團，誰的最大股東持股比例更高？各自比例為多少？
-
答案：樺欣控股最大股東JC International持股 71.88%；雅天妮集團最大實益擁有人持股 64.19%。樺欣控股更高。
-
挑战分析：跨文档比较
-
LazyMind
回答：根据知识库中的信息，以下是樺欣控股和雅天妮集团截至2024年9月30日的最大股东持股比例：
-
### 樺欣控股
-
- **公司名称**：樺欣控股
-
- **最大股东**：JC International
-
- **持股比例**：71.88%[14](#source-14.1 "樺欣控股.pdf")
-
### 雅天妮集团
-
- **公司名称**：雅天妮集团
-
- **最大股东**：迅速发展有限公司（由陈龙先生和林晨洁女士分别最终拥有70%和29%的股份）
-
- **持股比例**：64.19%[12](#source-12.2 "雅天妮集團.pdf")[12](#source-12.4 "雅天妮集團.pdf")
-
### 比较
-
- **樺欣控股**的最大股东持股比例为71.88%。
-
- **雅天妮集团**的最大股东持股比例为64.19%。
-
### 结论 - **樺欣控股**的最大股东持股比例更高，高出7.69个百分点（71.88% - 64.19%）。
-
### 参考来源
-
- 《樺欣控股.pdf》[14](#source-14.1 "樺欣控股.pdf")
-
- 《雅天妮集团.pdf》[12](#source-12.2 "雅天妮集團.pdf")[12](#source-12.4 "雅天妮集團.pdf")
-
如果您需要更详细的信息或有其他问题，请告诉我。
-
评价：准确回答，且精炼无冗长
-
RAGFlow:
回答：The user is asking about the largest shareholders of two companies - 樺欣控股 (Huaxin Holdings) and 雅天妮集團 (Artini Group) - specifically about who has the higher ownership percentage.
-
Let me search through the provided documents:
-
For 雅天妮集團:
-
From ID:0 - The largest shareholder structure shows:
-
- 迅速發展有限公司 holds 708,591,525 shares, representing 64.19% of issued shares
-
- 迅發投資發展（深圳）有限公司 holds the same 708,591,525 shares (as controlled corporate interest)
-
- 賦興投資發展（深圳）有限公司 holds the same 708,591,525 shares (as controlled corporate interest)
-
- 林晨潔 holds the same 708,591,525 shares as spouse interest
-
For 樺欣控股:
-
From ID:5 - The company states that JC Fashion International Group Limited is considered the direct and ultimate controlling shareholder, with 蔡敬庭先生 as the ultimate controlling party, though the specific percentage isn't disclosed in the provided documents.
-
So comparing the two: 雅天妮集團's largest shareholder (迅速發展有限公司) holds 64.19%, while 樺欣控股's largest shareholder percentage isn't available from the documents provided, only that JC Fashion International Group Limited controls it. I can confirm that 64.19% is the largest shareholder percentage for 雅天妮集團 based on the document data.
-
## 比較最大股東持股比例
-
### 雅天妮集團（Artini Holdings Limited）
-
根據文檔，迅速發展有限公司為最大股東，持股比例為 **64.19%**，共持有 708,591,525 股 [ID:0]。
-
該控股架構如下：
-
- 迅速發展有限公司由迅發投資發展（深圳）有限公司全資擁有
-
- 迅發投資發展（深圳）有限公司由賦興投資發展（深圳）有限公司全資擁有
-
- 賦興投資發展的最終持有人為陳龍先生（70%）、林晨潔女士（29%）及陳乃恩先生（1%）[ID:2]
-
---
-
### 樺欣控股
-
根據文檔，董事認為直接及最終控股公司為 **JC Fashion International Group Limited**，其最終控制方為蔡敬庭先生 [ID:5]。
-
> **遺憾的是，文件中並未披露JC Fashion International Group Limited的具體持股比例。**
-
---
-
### 結論
-
**雅天妮集團的最大股東持股比例更高**，為 **64.19%**。
-
然而，樺欣控股的最大股東持股比例在所提供之文檔中未見明確數字，無法進行完整比較。<think>The user is asking about the largest shareholders of two companies - 樺欣控股 (Huaxin Holdings) and 雅天妮集團 (Artini Group) - specifically about who has the higher ownership percentage.
-
Let me search through the provided documents:
-
For 雅天妮集團:
-
From ID:0 - The largest shareholder structure shows:
-
- 迅速發展有限公司 holds 708,591,525 shares, representing 64.19% of issued shares
-
- 迅發投資發展（深圳）有限公司 holds the same 708,591,525 shares (as controlled corporate interest)
-
- 賦興投資發展（深圳）有限公司 holds the same 708,591,525 shares (as controlled corporate interest)
-
- 林晨潔 holds the same 708,591,525 shares as spouse interest
-
For 樺欣控股:
-
From ID:5 - The company states that JC Fashion International Group Limited is considered the direct and ultimate controlling shareholder, with 蔡敬庭先生 as the ultimate controlling party, though the specific percentage isn't disclosed in the provided documents.
-
So comparing the two: 雅天妮集團's largest shareholder (迅速發展有限公司) holds 64.19%, while 樺欣控股's largest shareholder percentage isn't available from the documents provided, only that JC Fashion International Group Limited controls it. I can confirm that 64.19% is the largest shareholder percentage for 雅天妮集團 based on the document data.</think>
-
## 比較最大股東持股比例
-
### 雅天妮集團（Artini Holdings Limited）
-
根據文檔，迅速發展有限公司為最大股東，持股比例為 **64.19%**，共持有 708,591,525 股 [ID:0]。
-
該控股架構如下：
-
- 迅速發展有限公司由迅發投資發展（深圳）有限公司全資擁有
-
- 迅發投資發展（深圳）有限公司由賦興投資發展（深圳）有限公司全資擁有
-
- 賦興投資發展的最終持有人為陳龍先生（70%）、林晨潔女士（29%）及陳乃恩先生（1%）[ID:2]
-
--- ### 樺欣控股 根據文檔，董事認為直接及最終控股公司為 **JC Fashion International Group Limited**，其最終控制方為蔡敬庭先生 [ID:5]。
-
> **遺憾的是，文件中並未披露JC Fashion International Group Limited的具體持股比例。**
-
---
-
### 結論
-
**雅天妮集團的最大股東持股比例更高**，為 **64.19%**。
-
然而，樺欣控股的最大股東持股比例在所提供之文檔中未見明確數字，無法進行完整比較。
-
评价：回答错误，未能完全召回
-
-
-
示例4
-
问题：母公司2024年所得税费用相比上一年如何变化？
-
答案：增加：19.2
-
挑战分析：表格跨页
-
LazyMind
回答：根据知识库中的信息，我找到了**母公司2024年所得税费用的数据**。
-
## 母公司所得税费用变化情况
-
从知识库中检索到的数据显示 [1](#source-1.22 "财达证券 2024 年度年报（金融券商）.pdf")(file://doc_2c5ad9038ba534a2722a8bac8a14f780)：
-
| 项目 | 2024年 | 2023年 | 增减(%) |
-
|------|--------|--------|---------|
-
| 所得税费用 | 185,441,113.64 | 155,577,186.39 | **19.20%** |
-
## 分析
-
**母公司2024年所得税费用为185,441,113.64元，相比上一年（2023年）的155,577,186.39元，增加了约2,986万元，增幅为19.20%。
-
** 这一增长主要与母公司利润总额的增长相关： - 2024年利润总额：859,104,702.99元 - 2023年利润总额：739,022,561.25元 - 增幅：16.25%
-
所得税费用的增幅（19.20%）略高于利润总额的增幅（16.25%），这可能与递延所得税费用等其他因素有关。
-
评价：回答正确
-
-
RAGFlow:
回答：根据知识库数据，**母公司2024年所得税费用相比2023年有所增加**。
-
## 所得税费用变化情况
-
| 项目 | 2024年 | 2023年 | 变动金额 | 变动幅度 |
-
|------|--------|--------|----------|----------|
-
| **所得税费用合计** | 192,519,365.58元 | 163,876,155.54元 | +28,643,210.04元 | **+17.48%** |
-
## 详细构成分析 所得税费用由两部分组成 [ID:5]：
-
| 组成部分 | 2024年 | 2023年 | |----------|--------|--------|
-
| **当期所得税费用** | 181,716,637.40元 | 130,705,680.46元 |
-
| **递延所得税费用** | 10,802,728.18元 | 33,170,475.08元 |
-
## 变化原因分析
-
根据ID:4中的所得税费用调节表，主要影响因素包括：
-
- 按法定税率计算应缴纳的所得税：219,802,457.73元
-
- 非应税收入的影响：-39,392,321.36元
-
- 不可抵扣的成本、费用和损失的影响：+13,476,122.60元
-
- 调整以前期间所得税的影响：-621,539.98元 ## 总结 2024年度所得税费用较2023年度**增加了约2,864万元，增长17.48%** [ID:2][ID:5]。这一增长主要与公司利润总额增加（从76,987.85万元增至87,920.98万元，增长14.20%）相关 [ID:2]。
-
评价：回答错误
-
-
-
示例5
-
问题：根据财达证券 2024 年度合并财务报表主要项目会计数据，计算：（交易性金融资产 ÷ 资产总额）× 营业收入
-
答案：1042039224.76
-
挑战分析：表格跨页+数值计算
-
LazyMind
回答：## 计算结果\n\n根据**财达证券 2024 年度合并财务报表**，三个关键数据如下：\n\n| 项目 | 金额（元） | 数据来源 |\n|------|-----------|---------|\n| **交易性金融资产** | 22,277,987,004.50 | 合并资产负债表（期末余额）[1](#source-1.1 \"财达证券 2024 年度年报（金融券商）.pdf\")[1](#source-1.3 \"财达证券 2024 年度年报（金融券商）.pdf\") |\n| **资产总额** | 52,248,695,387.28 | 合并资产负债表（主要会计数据）[1](#source-1.13 \"财达证券 2024 年度年报（金融券商）.pdf\") |\n| **营业收入** | 2,443,900,789.83 | 合并利润表（主要会计数据）[1](#source-1.13 \"财达证券 2024 年度年报（金融券商）.pdf\") |\n\n### 计算公式及结果\n\n$$\\left(\\frac{交易性金融资产}{资产总额}\\right) \\times 营业收入 = \\left(\\frac{22{,}277{,}987{,}004.50}{52{,}248{,}695{,}387.28}\\right) \\times 2{,}443{,}900{,}789.83$$\n\n$$\\approx 0.4265 \\times 2{,}443{,}900{,}789.83$$\n\n### ✅ 最终结果：约 **10.42 亿元（1,042,039,224.76 元）**\n\n该指标反映了交易性金融资产占总资产的比值与营业收入的乘积，财达证券 2024 年度该指标的数值约为 **10.42 亿元**。
-
评价：回答正确
-
-
RAGFlow:
回答：我来帮您查找相关数据并进行计算。
-
## 数据检索
-
根据财达证券2024年度财务数据，我需要查找以下三项数据：
-
**从知识库中查找到的数据：**
-
| 项目 | 数据 | 来源 |
-
|------|------|------|
-
| 交易性金融资产 | 22,277,987,004.50 元 | [ID:0] |
-
| 资产总额 | 52,248,695,387.28 元 | [ID:0] |
-
| 手续费及佣金净收入 | 1,328,784,512.85 元 | [ID:0] |
-
---
-
## 调用计算器工具进行计算 现在我将使用 calculator 工具计算：
-
**公式 = (交易性金融资产 ÷ 资产总额) × 手续费及佣金净收入**
-
```json
-
{
-
"cmd": "calculator",
-
"input": "(22277987004.50 / 52248695387.28) * 1328784512.85"
-
}
-
```
-
---
-
## 计算结果
-
计算结果约为：**566.03 亿元**
-
**计算过程：**
-
- 交易性金融资产 ÷ 资产总额 = 22,277,987,004.50 ÷ 52,248,695,387.28 ≈ 42.64% - 42.64% × 1,328,784,512.85 ≈ **566,028,594.31 元**
-
> ⚠️ **说明**：上述计算使用的是知识库中的**合并报表数据**。如需严格使用**母公司财务报表**数据，请参考ID:3中的母公司资产负债表（交易性金融资产：21,745,881,971.80元，资产总计：50,638,690,356.67元），但该表中未单独披露母公司的手续费及佣金净收入。
-
评价：回答错误
-
-
而速度方面，在完全本地环境下，基于线上MinerU和硅基流动的线上模型API， 我们对 42 份文档进行了完整处理。LazyMind 端到端耗时为 14m28s，RAGFlow 在相同文档上的处理耗时为 3h18m55s。
|
LazyMind + 线上MinerU |
LlamaIndex + 线上MinerU |
RAGFlow |
||
|
配置 |
Apple M4 Pro 12核 24 GB |
Intel Xeon Processor (Icelake) 32核 128GB内存 Ubuntu 22.04.4 LTS |
||
|
PDF解析 |
9m20s |
9m34s |
19m |
3h2min11s |
|
向量化入库 |
5m08s |
8m2s |
15m52s |
16m44s |
|
总耗时 |
14m28s |
20m05s |
34m52s |
3h18m55s |
|
app版本 |
lazymind 0.1.0 lazyllm 1.0 |
llama-index: 0.14.21 |
ragflow v0.25.2 |
|
* RAGFlow的PDF解析无法接入线上MinerU，接入本地部署的MinerU也遇到了问题，目前主要依赖CPU版的DeepDOC。
* RAGFlow在Mac上更慢，因此我们选择它更具速度优势的Intel Xeon + Ubuntu进行测试
* RAGFlow和LazyMind都支持图文问答，但评测时候都未开启，都未配置图文embedding。
更重要的是——这不是实验室调参跑出来的 Demo，而是我们在几十个真实企业项目里反复打磨后的结果。
三、效果差距，从文档进门那一刻就开始了
很多人以为 RAG 效果取决于大模型。但实际上，效果好不好，从文档进入系统的那一刻就已经决定了一半。
一份企业文档，往往不是干净的 Markdown。它是几十层标题嵌套的规划文件、跨页大表格、图文混排的财报、扫描版 PDF、飞书 Wiki、云盘里的历史资料。很多系统所谓的"解析"，其实只是把文字抠出来，然后粗暴切 chunk。
结构丢了，上下文断了，后面的模型再强，也是在垃圾堆里找答案。
LazyMind 做了一些很重、但我们认为必须做的事情：
- 解析阶段重建完整标题树，每一段内容都知道自己属于哪一章、哪一节。
- 自动识别并合并跨页表格，对超长表格做带标题与脚注的智能分页，任何一个分片都不会丢失语义。
- 检索阶段自动处理企业专有名词——缩写、历史叫法、业务黑话，不用你手工维护词典。
- 多路召回 + 动态截断 + 上下文扩展 + Agentic 检索——不是"搜一下就回答"，而是自主决定要不要继续找证据。
-
这里有一句话我们越来越想直接说：
市面上很多 RAG 产品把 chunk size、topK、rerank 阈值做成复杂配置界面，让用户自己研究、自己调优——这不是产品化，是把研发责任转嫁给用户。
真正的企业用户，从来不应该研究"chunk 切 512 还是 1024"。他们只需要关心一件事：这个系统到底能不能把我的问题解决。
四、"智积阅累"：让系统越用越懂你，而不是越用越蠢
这是 LazyMind 和市面上绝大多数产品拉开差距的地方。
传统知识库的困境是：刚上线很好用，越用越难用。 因为企业本身在持续变化——业务术语在变、流程在变、组织在变、员工在变。模型如果不能持续理解这些变化，再强也会慢慢"失聪"。
更糟糕的是，大量企业关键知识根本不在正式文档里。它藏在：
-
团队内部的缩写和黑话（"铁三角"在不同部门含义完全不同）
-
操作习惯和 SOP（先判断状态，再匹配流程，而不是直接给概念解释）
-
一次次对话和修正中积累的经验
-
某个"特别会用 AI"的同事脑子里
LazyMind 的"智积阅累"体系，让你的智慧和阅历，在我们的系统中实现极尽的升华。
它包含四大核心模块：
- 技能：把"某个场景下怎么做"沉淀为可复用的 SOP 模板。不是一段 Prompt，而是可创建、可修改建议、可审阅、可预览、可确认发布、可在组织内共享的方法资产。以前只有某个人会用 AI，现在新人拿来就能复用。
- 记忆与偏好：不是把历史对话越堆越长（那样只会噪声累积），而是选择性保留高价值信息，区分 Agent 工作记忆和用户偏好。有完整的 draft / review / confirm 审阅流程，而不是偷偷改写。
- 词表：不是摆设，而是深度参与检索流程的术语层。用户说"X"，文档里写的是"Y"——系统自动做术语映射，检索前做查询增强，支持热更新。从真实对话中持续提炼稳定术语映射，回流进系统。
- 工具：kb_search、web_search、url_fetch 等原子能力开箱即用，Agent 需要什么直接调用。
关键是，这一切不需要人工触发。如果你足够信任AI，给它授权后，我们的系统就会帮你在后台自动完成知识整理与合并，不打断当前对话，不需要运营团队天天维护规则。如果你不愿意完全信任它，你也有途径对它的建议进行审批和应用。
五、evo 自进化：系统自己改代码、跑 A/B、验证上线
这是 LazyMind 最独特、也最硬核的部分。
很多系统号称"自进化"，实际做的只是：效果下降 → AI 调一下 Prompt → 象征性放几个技能 → 直接上线。
这不叫进化，叫随机漂移。 没有真正的诊断，没有严格验证，你根本不知道系统是在变好还是在变差——也许某几个问题回答好了，但整体召回率下降了；短问题变准了，复杂推理退化了。
LazyMind 的 evo 自进化闭环，做了一套完全不同的事：
第一步：发现问题。 系统持续监控真实使用效果，一旦某类问题开始变差，它不会立刻改参数，而是先结合用户实际问答范式，自动生成一套评测集（包括单跳、多跳、跨文档推理等不同难度），先搞清楚"问题到底出在哪"。
第二步：多 Agent 协同诊断。 Indexer 提出可验证假设（比如"Reranker 在跨文档多跳问题中系统性丢弃了关键段落"）；Researcher 调用工具链读源码、查日志、分析 badcase 逐一验证；Critic 专门挑刺，质疑所有结论是否有数据支撑；Synthesizer 把确认的问题整理成带优先级的优化方案。
第三步：不是改 Prompt，是改代码。 系统在隔离的 Git worktree 中自动修改 Python 代码，有严格文件白名单保护，越界修改自动回滚，修改完成后自动运行测试套件。这本质上已经不是"AI 调参数"，而是一次受控的软件工程迭代。
第四步：统计验证，不是感觉验证。 代码改完不能直接上线。LazyMind 先执行单元测试，然后跑 A/B 测试，通过符号检验计算 p-value，确认提升不是随机波动。同时设置守护指标：准确率提升但召回率下降？拒绝。复杂问题变强但稳定性变差？拒绝。
第五步：全自动或人工介入，任你选。 成熟场景自主完成全流程；高风险场景在关键节点暂停，等待人工审核后再继续。
整个复杂过程，可以被压缩成一句自然语言："从知识库生成评测集，分析报告后修改代码，做 A/B 测试验证效果。"
这五步的价值，我们有一组直观的对比数据——
过去没有 evo 的时候，一个传统企业的业务场景要做到"能用"，需要 5~10 个技术专家，跟领域的业务专家反复对齐、手工调参、分析 badcase、一轮轮打磨，平均耗时半年，才能在一个场景上收敛到可接受的效果。
有了 evo 之后，1 个售前协助业务专家梳理场景，系统自己生成评测集、自己诊断问题、自己改代码验证，就能把效果推到业务方预期的水位。
半年 → 几天。10 个人 → 1 个人。
企业知识库落地最难的那一环——"让算法真正适配业务"——被 evo 干掉了。
这不是"能回答问题的知识库"。这是一个能持续优化自己的智能系统。
六、从"千库一算法"到"一库一策略"
很多 RAG 产品的"个性化"，只做到了一件事：你有你的知识库，我有我的知识库，团队 A 看不到团队 B 的文档。
这叫数据个性化，不叫算法个性化。
换个知识库，用的还是同一套切块策略、同一套召回参数、同一套排序模型、同一套 Prompt 模板。但现实是什么？
- 研发部门问的是版本、接口、依赖和历史决策
- 客服部门问的是流程、状态、下一步动作和话术
- 法务部门问的是条款、例外、时间范围和责任边界
- 个人笔记里是缩写、半句话、灵感记录和只有自己懂的上下文
不同的知识结构，怎么能用同一套策略？
LazyMind 的核心判断是：每个知识库，都应该被当成一个可以持续观测、评测和优化的独立对象。 它应该长出自己的检索策略、自己的术语体系、自己的技能库、自己的评测标准、自己的优化路径。
|
传统 RAG |
LazyMind |
|
|
策略 |
千库一算法 |
一库一策略 |
|
个性化 |
停留在文档层 |
进入算法层 |
|
生命周期 |
上线即完成 |
上线后持续治理 |
|
优化方式 |
靠人工调参 |
靠评测和 badcase 驱动 |
|
核心追问 |
能不能答 |
能不能长期答好 |
|
知识库是什么 |
文档集合 |
可优化对象 |
RAG 的上半场，比的是谁能更快把文档"问起来"。下半场，比的是谁能让每个知识库拥有自己的策略。
七、可观测：从黑盒到透明，每一轮对话都"有据可查"
企业场景里最怕的不是答错，而是答错了不知道错在哪。
LazyMind 的观测系统，把 Agentic RAG 的每一次执行完整记录下来：Agent 调用了哪些工具？检索返回了哪些文档？Reranker 把哪些关键段落排到了前面？模型基于什么上下文生成了最终答案？每一步耗时多少、token 消耗多少？
*注：当前界面还在开发，即将上线，可以先借助langfuse进行观测
这些信息被组织成结构化 Trace Tree，关联到每一次问答、每一个评测样本、每一轮 A/B 测试。
当一个 badcase 出现时，你可以这样下钻：
低分 case
├─ 看评分：答案不完整 / 召回不足 / 生成偏差
├─ 看 Trace：Agent 调用了哪些工具
├─ 看检索：Retriever 返回了哪些文档
├─ 看重排：Reranker 是否把关键文档排到了前面
└─ 看生成：LLM 是否基于有效上下文给出答案
在 A/B 测试中，Baseline 和 Candidate 可以对同一个 case 分别提供完整 Trace，让你精准定位版本差异到底来自哪里——是多检索到了关键文档，还是 rerank 策略更好，还是 token 成本增加换来了效果提升。
观测系统的价值不是"好看"，而是让优化从"凭经验"变成"凭证据"。 这也是 evo 自进化能够自动诊断问题的底层基础——AI 需要先"看见"执行过程，才能分析问题出在哪个环节。
八、企业级，不是说说而已
很多 AI Demo 不是效果不行，是根本进不了生产环境。演示时回答很好，一接入企业系统就暴露：权限怎么隔离？不同团队怎么协作？能不能私有化部署？能不能接入现有基础设施？
LazyMind 从一开始就不是按 Demo 思路设计的。
权限：四层鉴权链——Kong API Gateway → JWT → RBAC → 资源级 ACL，每一层独立校验。不同用户、不同团队、不同知识库之间细粒度隔离。API Key 全程加密存储，前端永不回显完整密钥。
数据源治理：不是"上传文件"，而是把飞书 Wiki、本地目录、对象存储变成可接入、可同步、可追踪、可管理的知识入口。支持定时自动同步，知识变了，系统自动跟上。
模型供应商：对话、图文、Rerank、ASR、TTS、文生图——全部在同一个界面独立配置，支持 SenseNova、Qwen、Doubao、DeepSeek、GLM、Kimi、MiniMax、OpenAI、Claude 等主流平台。一次鉴权，全平台共享。秒级无感平替，告别胶水代码。
部署：私有化（Docker Compose 一键部署，已开源）、桌面版（Electron + SQLite + milvus-lite，即将开源）、公有云（Helm + Kubernetes，无开源计划）三种形态。同一套代码适配不同环境。如果你只是个人开发者或小团队，未来可以像安装普通桌面软件一样直接使用完整的企业级知识系统。
多模态：上传复杂工业图表让 qvq-72b 做深度图文理解，长文本多轮推理，知识库和常用战术一键挂载到对话中——所有复杂能力被压缩进清爽的对话流。
结尾：开源，一起来搞
LazyMind 已经开源。
如果你是一个工程师，被各种 RAG 调参折磨过，想看看一个能在自己的场景上进化算法的系统是怎么工作的——Clone 它，跑起来。
如果你是产品经理或技术 Leader，正在评估下一个企业知识库方案，想知道"一库一策略"、"自进化闭环"、"智积阅累"到底是不是真东西——跑个 Demo，看数据说话。
如果你也在做 RAG 或企业知识库，有不同的想法、更好的方案、或者想吐槽的——来提 Issue，来聊。
当别人还在手工调 topK 的时候，你已经可以让系统自己进化了。这个差距，你是想追上去，还是想被拉开？
GitHub: https://github.com/LazyAGI/LazyMind ，Star & Fork，Happy Work
LazyMind 正在从"能问答的知识库"，走向"会持续进化的知识系统"。点个关注，不再迷路~
Agent 垂直技术社区，欢迎活跃、内容共建。
更多推荐
3
0- 0
已为社区贡献1条内容
所有评论(0)