夫RAG之竞品析，徒列功能已不足矣。此文深析，何以藉DDD子域分野与Kano模型，重定RAG析之纲。以百度千帆AppBuilder与Lyzr AI为鉴，显RAG功能之产品逻辑与战略思量，助产品司于资源投入与功能分层，决之更精。

一、何故RAG产品不可仅作“功能清单式”竞品析？

析RAG产品时，吾辈易陷惯性：

• 此平台有知识库乎？
• 有文档解析乎？
• 支混合检索乎？
• 有重排乎？
• 能作效果评测乎？

此似周全，然本仍作功能清单对比。

彼能应“孰具此能”，然难应：

此能何缘而生？

何者为此物之必备基能？何能当为重研之的？

何故有物重研知识解析，有物重心在检索策略，又有物强化效果评测？

遂致观竞品甚众，然终成雾里看花。今文即解此惑。

下当以：

华夏：百度千帆 AppBuilder

域外：Lyzr AI

二者非独为技术之人设之底层数据引擎，实乃为 AI 应用 / Agent 构建之产品平台。其知识库之能，各彰 RAG 在国中大模型应用平台与海外 Agent 构建平台之产品化法。

RAG 架构常与 Agent 智能体产品之知识库功能密合无间，今多 Agent 产品皆采此数据架构，助用户将私有数据，速化为 Agent 处理用户问题之知识源泉。

产品中 RAG 之处理流程，可总为：循“知识入系统—知识被处理—知识被检索—知识被组织为应答上下文—答案被生成—效果被评估与优化”之流程，渐次产品化之果。

为明此事，本文尝引二法：

• DDD 子域划分：自业务价值角度判，RAG 产品中何者能力为真正值得投入之核心域。
• Kano 模型：自用户之价值观之，此等功能，或属行业之门槛，或增体验之强，或为异彩之点。

终成分析之框架：

• RAG 处理流程，释功能所自；
• DDD，明资源所投；
• Kano，示功能之分层。

自了解RAG架构中数据处理之环节始，复以DDD子域划分与Kano模型相合，以析现有产品之具体运用。DDD之子域划分，可助吾等识：RAG产品中，何能力最宜为资源投入之重，成吾产品之异彩。Kano模型，则助吾等辨：此等能力中，具体功能何者属行业之门槛，何者增满意之竞争点，何者为异化创新之机。

二、析法：以 DDD 观业之价，以 Kano 观用之值

1. DDD：以业之价视角察产之能投

DDD，即域驱动设，初用于繁业系之模。于产析而言，吾辈不须尽展 DDD 中诸技之念，若实体、聚合、仓、域服之属。

是文即借 DDD 之略设视角：

• 一语：产、业、研当于核业之念成一致之解；
• 界上下文：于何业之限，一念一规乃为成立；
• 子域分之：辨何者为核心域、支撑域、通用域。

微软 Azure 架构之文亦将领域分析、限界上下文等列作 DDD 建模微服务之要务。吾辈作产品分析，尤重此二者：先明业务领域，次辨业务边界与子域。

于本文，可简言之：

一言以蔽之，自产品之眼观之，DDD 之要，在助吾辈答：资源当重点投于何处？

其中本文所析之子域，分为三类：核心域、通用域、支撑域。

微软与 AWS 之架构资料皆强调，DDD 之战略价值，在于使系统设计围绕真实业务能力，而非围绕技术模块机械拆分。(Microsoft Learn)

2. Kano：辨功能于用户满意之影响

Kano之模型，常将需求分五类：

Kano之价值，在非惟告吾“用户欲何”，乃助吾辨：

一功能于用户满意之影响若何。(asq.org)

ASQ于Kano模型之释，亦用以明产品或服务功能之成度与用户满意之关系。

置于知识库产品功能中：

• 文件上传、创建知识库，大概率是必备属性。
• 混合检索、切片配置、重排，更似之期望属性；
• 自动调优、图谱增强、多模态 RAG，或为之魅力属性或高阶期望属性。

具体而言，此等功能属何类属性，须依Kano之执行，察用户之反馈，以明其功能属性之特征。

Kano之助，在于答：功能当如何分层设计，以助正确之决断。

3. DDD与Kano之关系：一者观资源战略，一者察需求认知

多产品分析止于Kano，常现一弊：

用户之欢欣所系，未必为企业所当优先投力之能。

譬如，炫目之“AI自动生成问答助手”，或为魅力所在；

然若其下知识解析与检索之质不高，此功能徒具“似智”之表，而用户之体验不良，则其难成稳定之竞争力，反损用户对产品之满意。

反之，独作DDD之域分亦不足。

盖因汝或能辨检索之能甚要，然若不解用户于不同检索之能感知之异，亦难断：

• 何者仅为行业之阈？
• 何者可升满意之度？
• 何者能成差异之别？

是故：

DDD 为业务价值之观，Kano 为用户价值之观。

二者相合，即以“业务价值加用户价值”决功能之设与优先。

三、RAG 产品功能之真源：万般皆从处理流程出。

RAG 之核心，在于：

大模型生成答案之前，先于外部知识源中检索信息，再依此生成应答。

此实乃一完整之处理链路：（插入图示）

相应每一环节，皆自然生一类产品功能。

此功能映射表可见，实RAG 产品功能非菜单式堆叠，乃 RAG 处理链路于产品层面之逐步显化，为求流程处理之完整。

四、依 RAG 之序，重析 DDD 之域

若将 RAG 之品置于“面向非技士之 AI 应用 / 工作流构筑之台”而析之，吾以为可析出以下能域。

1. 核心域一：知识构建域

RAG 之序中所涉环节：

知识接入 –> 文档解析 –> 切片 –> 知识增强 –>索引准备

此流程所对应的典型功能有：

• 创制知库
• 上傳文件
• 網址輸入
• 文牍析解
• 切分之术
• 向量之模

此段当为知识库之要，与RAG流程密不可分。若前段知识处理未善，则后之检索与生成皆受其累。譬如切片之误、解析之不全、知识组织之乱，皆可直致召回之失或应答之谬。

二、核心域二：检索增强域

于 RAG 之序中：

咨诘洞悉 → 检索回溯 → 结果排序 → 上下文筛选

此环节所解者，乃用户发问，能否速而确地索得相关之文也。此模块之内容，映射于具体之产品功能者，乃：

• 探求洞悉
• 回溯索检
• 策择之道
• 重排
• 上下文增广

此亦为核域之由，与RAG架构之“增”理相关，其本在索。若索不得，纵大模甚强，终依误境生答，犹不能解大模之弊。

在实际之器物中，常对应此数功能之模块。

• 意旨探求
• 全文检索
• 杂糅索检
• 广征知识库之检索
• 多召回之量
• 匹配分之阈

3. 支撑域：智能体之编序域

于Agent智能体之筑台，可谓知识库之能，乃将RAG之才，裨为可应事之用之件或工流之节。其当于Agent平台中，典型之用有：

• 工流之布
• 知识库（知识）之节
• 大模型之节
• 输出之节

此间有至要之辨：

• 若究者乃整体AI应用之筑台，工作流之编排，或为要域。
• 然若究RAG 能力如何产品化，则工作流更似承载 RAG 能力之基域。

4. 通用域：企业基础能力域

例如：

• 权限管理
• 团队协作
• 安全审计
• 连接管理
• 部署与发布
• 统计分析

此等能力，甚为紧要，影响用户体验，然非 RAG 本体能力之源。故于本文，不作重点详述。

五、何故择千帆与 Lyzr AI？

是文择此二器，盖非“纯技型 RAG 引擎”，乃：面向异能之辈，构 AI 之用/工流之台。

1、千帆 AppBuilder

百度千帆 AppBuilder 之智库，直应 RAG 之境。其智库小传云，智库乃 RAG 之基，兼具智增、混索、全文索、义索与重序之能。

千帆尤宜察：

华夏大模应用台，如何将 RAG 化为较备之智库工化之能。

2、Lyzr AI

Lyzr AI 之官方典籍明载，其能创制 无码 RAG 管道 ，以自文件、URL、素文等源，构可索之文意通晓之能。

Lyzr 更适吾辈察之：

海外 Agent 搭台，如何将 RAG 封为非技者可设、可验、可联之 Agent 知库之能。

是故，并论此二物，非欲辨孰优，乃欲观：

同此 RAG 之程，于异 AI 之用 / Agent 搭台，化为何种知库之能。

六、循 RAG 之程察竞品：功能之长，若何而得？

千帆之AppBuilder，使知识之加工，更可配置也

千帆之知识库创建之页，非徒“上传文档”而已

其更进之（上图可明见），千帆此创建知识库之功能表单，其字段命名甚为精妙，与RAG流程中之处理步骤及细节名称，甚相关，乃至相同。今吾撮其操作之名，并与之RAG中之模块映射对齐。

此等能力，本皆答一问：

何以将原始资料，化易为知识结构，俾后续检索易得之？

且上图千帆之“知识增强”按钮开启时，可择知识增强之法（可选增切门片内容摘要与三元组知识抽取二法），此辅助功能，将调用大模型以生额外知识点，用以提升切片召回率。是故，非以知识库为静态文件之仓，乃主动优化知识之可召回性也。

复次，千帆于多模态RAG与图谱增援RAG之事，亦尝探之于产品化，其应图文联索、多实多系知识之组织等繁境，然本文不欲详述，若其有志，可往千帆平台试之。

要之，百度千帆之知识库，实若一企业级RAG知识工程之体系。其在知识之纳、切、增、索、工流调用、效验诸端，皆具较备之产品化表。

2、Lyzr AI：Agent知识库中no-code RAG产品化之径

Lyzr AI亦支持知识库，然其产品之略异。于Lyzr AI中，建知识库之能，首即分为三类（知识库、知识图谱、语义数据模型）。其中应RAG之程者，乃知识库之建，故今当聚焦于此功能之径，探其能与RAG之程间之映。

上图乃Lyzr AI创制“知识库”之页，向量化模型与向量库乃必填之项，入次页则可自择数据导入之法。与本文所述RAG流程相关者，惟“导入文件”之法。择“add file”之项，询文件即可（此平台今仅支持上传PDF、DOCX、TXT之文），则文件将显于页左之列。

继而界面乃现用户可设之知识库检索之项（上图红框所示），Lyzr于此设计，私以为胜百度千帆。百度千帆中，知识库分段配置、检索之法、配置策略等项颇为繁复，非初学者所宜，而Lyzr AI之设，减非技术之徒之理解之艰，但示最要之配置项，既令用户有参与之趣，亦不令其感操作之难。

用户不必先通复杂之知识增强之理，但知：

吾将组织之资料置于知识库，复于工作流中接一知识库节点，则使智能体得依此资料而应答。

Lyzr AI 之智囊，更似面向 Agent 的无代码 RAG 流程其将知识接入、切片、向量索引、检索策略、Prompt组装、引用输出及模拟测试，悉数封装于Knowledge Base与Agent之连接，使知识库配置更为轻灵，尤宜初学者构架。

简述之

于知识构建之域：

千帆尤重之知识工化之理

Lyzr AI更重也知识库之用渐易

二者所治者，仍为同此 RAG 之题：知识何以自原始之材化而为可检之资。

七、以 Kano 重新审 RAG 之能级

于此尤须明言：

严格之 Kano 分类，当以用户问卷得之。

下表非正式调研之结，乃据个人于今产品之成熟度与功能之普度，所为之产品分析式初判，供诸君参酌。

此表之义在：

非所有功能皆宜同等投入。且吾等犹存疑于此 Kano 之判，故须更审功能属性之判，以证其信。

若此与 DDD 子域之划分相合，则优先级之判，愈显明晰。

八、DDD 与 Kano 相融，其于产品功能之设计，当如何导之？

可成如下之矩阵：

施诸 RAG 产品，可得数处直判。

一、知识构建域，不可徒满足“能上传”。

若产品惟止于“创建知识库 + 上传文件”，则不过门槛而已。

真正值得投入者，乃：

• 复杂文档之解析
• 切片之策略
• 知识之增强
• 多模态内容之组织

盖此诸能，实决其后检索之质也。

检索增强域者，核心之争也

未来 RAG 之异，非惟“有知识库与否”，实乃：

• 能否更精准确引
• 能否因应不同境遇择更宜之策
• 能否减绝无关之语入乎上下文
• 能否将检索之能配置化、产品化

此点，千帆与 Lyzr AI 已以异途彰之。

3. 效果之评，自“高阶之能”渐为众需

当 RAG 自 Demo 走于正业，产品必应：

• 此问答之系果否良善？
• 孰版本更优？
• 优化果真有效乎？

故评鉴与修饰，当非恒为“后台之器”，宜渐成核心之能。千帆今于效验之务，成其产品化，即此势之显也。

四、非技术之徒，非谓尽隐其程也。

此点甚要。

众品一提“面向非技术用户”，便欲尽藏其繁难。

然 RAG 之产品，不可尽然也。

至善之设，非使民无知也。

而是：

必解之要旨显于外，不须之底繁隐于内。

自兹观之：

• 千帆似在授人以渔，教调 RAG 之术；
• Lyzr AI 似在助人点石，导 RAG 之能入业务之流。

此二途皆有其理，千帆之众偏于技士，Lyzr AI 则对初学者尤善。

九、终论：RAG 之功能，实乃流程之化现。

吾文欲明一事：

RAG 之功能，非孤立之点，乃知识流程自然生发之模块。

而 DDD 与 Kano 相合，为吾等提供更全之产品分析法：

• DDD 使吾等明业务之要；
• Kano 使吾等辨用户之值。
• RAG 流程助吾明功能所自。

倘后续欲设计一款面向非技术用户的 RAG 产品，当先问：

• 此功能所解者，乃 RAG 之流程中何弊也？
• 其属核心域耶？支撑域耶？抑或通用域耶？
• 于用户而言，此乃必备、所盼，抑或魅力之能乎？

DDD之领域划分，助速定产品之核心业务。

• 千帆重申学识增益、考课之事
• Lyzr 言简知识库之序，必检索之配置也
• 有平台重自动切片优化、可视化调试之术。

此乃示此等能力，极或为今之赛道所系。核心竞争地。

故RAG之功能，非产品者凭空构之，实乃因其通晓RAG之数据处理之理、明其价值所在，乃依RAG处理之序，渐次产品化而成。