RAG在企业应用中落地的难点与创新

1、前言

在6月底稀土掘金开发者大会的RAG专场上，我们团队分享了一个关于企业落地的实战心得，标题是《RAG在企业应用中落地的难点与创新》。

当时分享最后，我们抛出了两个关键判断：

• AI在应用场景落地时有三个特点：功能小、质量高、价值大

• 如果说做产品是把一横做好的话，那么去做企业落地服务就是一竖，从需求和方案，再到 POC，和最后交付。

先说第一个特点。在实际落地过程中，遇到的麻烦事确实不少。用过AI产品的朋友应该都有体会，目前基于大模型的应用，C端产品普遍是偏小工具型的。它们确实能帮人提效，比如

、这类插件，借助互联网生态和开源技术，只要功能设计到位、交互顺手，很快就能圈到一波用户。

但B端完全是另一回事。除了产品自身要足够强大，还牵扯到

、、、这一大堆琐碎又关键的环节，交付周期比C端长得多。这正好印证了第二个观点：只有两条腿走路，才能真正服务好B端客户。

这篇文章，正是基于我们公司在B端RAG和大模型应用落地交付中的实际场景，从实战出发，聊聊知识库类产品的技术架构该如何思考。

2、业务功能与技术组件拆解

标题里已经圈定了范围：

、、。从这三个维度出发，在软件层面，我们要考虑如何把这些新名词拆解成可落地的技术和产品功能。

先看业务层面的核心诉求：

• 知识库
  ：客户需要把业务数据统一收集处理，形成让LLM能直接使用的知识库。

• 应用中心
  ：B端客户要的是开箱即用的产品，能解决他们实际工作里最疼的问题。

• 用户权限
  ：企业级权限管理要灵活可控，方便统一管理和授权。

• 多租户
  ：多租户架构是必须的，确保数据在Schema级别隔离，既安全又能灵活支撑上层应用。

如果从技术人员的视角看，他们关心的是：

• 非结构化数据处理
  ：平台得支持各种文档格式的提取和加工，包括chunking、embedding，最后喂给向量库。

• 文件类型广度
  ：能处理PDF、PPT、Word这些主流格式，是打动B端客户的重要卖点。

• 文件解析精度
  ：PDF和PPT的解析难度最大，如何精耕细作，从源头减少模型对已知数据的幻觉？

• 任务调度
  ：数据处理靠稳定的调度平台来保证最终一致性。

• 模型服务
  ：从LLM、Reranker、embedding到OCR和视觉模型，

  保证模型的幂等输出
  ，给上层应用提供稳定支撑。

• LLM模型
  ：提供一系列

  Agent服务
  ，让上层业务灵活调用大模型拿到满意结果。

• ReRanker模型
  ：问答二阶段召回中提高准确率的关键手段，不能忽视。

• Embedding模型
  ：向量化嵌入，为知识文本提供特征表征。

• OCR/视觉模型
  ：在规则提取失效时启动，辅助非结构化数据提取。

• 向量数据库(VectorDB)
  ：要根据实际业务，从性能、空间、生态等多角度权衡选型。

技术侧拆解下来，关注点确实多，每一项都能独立成为一个中间件。要把它们全整合到一起，难度不小。

3、微服务、分布式还是云原生？

写过Ja va的朋友对这三个词肯定不陌生。早些年面试没提微服务，工作都找不到。但AI应用这块，软件生态更多是Python带动的，像LangChain、LlamaIndex这些都是Python出身。Ja va里虽然也有LangChain4j、Spring-AI，但生态和稳定性上确实差了一截。

用过LangChain的人应该都有个共识：当工具用没问题，一旦上生产，问题就冒出来了。主要原因有几个：

• LangChain封装得太深，Agent和RAG本身调用大模型API就行了，但看源码，调用链路极其复杂，想改都无从下手。
• 上层业务需求变化太快，得结合自家公司的实际情况来。这种情况下，自己写反而更快，因为调用逻辑并不复杂。
• 从稳定性、事务、数据一致性角度看，Python作为企业服务主接口，到底合不合适？

其实回到产品技术架构本身，我们在前面已经拆分了业务功能和技术组件。从技术点看，这已经是个集众多服务于一体的综合方案。那么在应用层，是否还需要像以前那样整一套微服务架构来开发？

一个相对务实的看法是：

在当前环境下，把项目搞成微服务，很可能最后所有服务都压在你一个人身上。写完a服务写b服务，再来个rpc调用，还要考虑熔断、可用性……对小团队来说，完全没必要折腾。

具体要考虑的几个点：

在RAG产品中，非结构化数据不仅要快速解析，还要做向量化。架构上得能快速处理这些文件，通过Pipeline方式存到向量库。传统做法离不开MQ，而应用层程序则可以通过弹性伸缩扩充消费节点，提升整体处理效率。

数据提取后，经过Embedding模型向量化，还涉及文本分块。底层向量存储和计算必须选一个更全面的向量数据库中间件，包括召回性能、数据存储/备份、多租户Schema权限等。

Embedding处理、大模型调度扣费、缓存……在组件拆解复杂的情况下，整个数据处理任务必须保证最终一致性。分布式多节点处理时要格外注意。

应用层的功能，

。这在私有化部署和交付环节尤其重要。比如，在一个完全内网隔离的环境里部署时，你就会体会到这种设计的便捷性。

总结一下：在应用层面，服务端应该

。

4、编程语言与中间件选择

我们团队目前是Ja va+Python的组合，分工很明确：

• Ja va：负责上层业务API接口、任务调度、数据处理。
• Python：负责模型、数据处理、NLP等任务，以无状态接口形式开放，数据状态流转全在Ja va端处理。

很多开发者会担心：Ja va在RAG/大模型领域到底合不合适？最让人困惑的可能是非结构化数据处理。仔细观察就会发现，目前开源平台和组件大多以Python为主，有人就认为Ja va处理不了。其实这是个误区。对于最难啃的PDF文件提取，

绝对值得深挖。当然Python在数据处理和分析上确实有天然优势，关键还是要根据团队配置来做选择。

基于团队当前的主流语言做技术选型和决策，没有绝对意义上的“应该用哪个语言”。Ja va、Python、Go、NodeJS、TypeScript，都可以。

开发上层应用，首先要看有哪些成熟的中间件和组件能拿来用，总不能从0到1造轮子。造轮子能提升个人技能，但在AI飞速发展的今天，帮产品尽早找到PMF才是首要任务。

至于非结构化数据的解析，其实Ja va和Python都足够丰富和稳定。

Ja va这边有：Apache PDFBox、POI、Tika。

Python这边有：PyMuPDF、pdfplumber、pypdf、camelot、python-docx等。

嗯，这里没有高并发，因为大家都没卡。

大模型产品在这点上与传统业务没太大区别。稳定性、集群这些要求依然存在，技术人员在选择中间件时也得考虑进去。比如MQ、Redis这些。

最后一步，部署实施也要考虑进去。Docker确实方便，但成本不低。Python生态打包Docker镜像，动辄2、3个G，如果再用K8s调度，拉一个10G的镜像可不是那么快的事。

5、最后

AI应用需要快速试错，在一个点上做到极致。技术架构也要兼顾开发效率和生态。

这让我想起十几年前的jQuery，一经问世就备受喜爱，那句经典名言至今记忆犹新：

Write Less, Do More!!!

在大模型越来越成熟的今天，我们的技术架构，是不是也该考虑做一次瘦身呢？