1、前言
在6.28/29的稀土掘金开发者大会RAG专场上，我们公司CEO员外代表TorchV分享了我们在《RAG在企业应用中落地的难点与创新》
其中最后分享了两个观点：
对于AI应用的三个特点，我们在落地的时候，其实碰到的问题蛮多的，但是用过大模型或者AI产品的人应该都知道，目前基于大模型应用开发的C端产品其实在整体给人的感觉都是相对较小的工具居多，在帮助人类提效这件事上，借助于AI工具，能很好的完成日常繁杂的工作和学习任务。比如AI翻译、网页总结插件等等。这类产品更多的是偏C端为主，借助于互联网的生态以及开源技术的发展，只要功能/交互满足用户的要求，很快就能打动C端用户进行尝鲜试用甚至付费。
但是做B端类的产品，整个交付的过程就明显和C端不一样，在B端我们除了产品本身需要功能足够强大之外，我们还需要做AI的落地交付，这里面包含私有化定制/客户培训/私有化部署/软硬件适配等等繁杂的工作，整个交付周期漫长的多。这明显是和上面第二个观点相呼应的，产品+服务才能综合服务好B端的客户。
本篇是结合我们公司在B端RAG/大模型应用产品的落地交付的场景考虑，以实际场景出发，谈谈我对知识库类产品的技术架构的思考总结。
图3-业务架构
在文章的标题中，我已经标注了范围: RAG、大模型、非结构化数据
我们从这三个方面出发，在软件层面，我们如何来考虑这些新型的技术名词，将他们从技术/产品功能的角度进行拆解，实现对应的功能交付给我们的客户。
从业务的功能诉求来看，主要有几个方面：
而从技术侧考虑，技术人员需要关注的是：
技术的角度拆分，其实技术人员关注的点非常的多，每一项工作其实都可以是独立的中间件产品，要把这些全部整合到一块，并非易事。
写过Java的估计对上面这三个名词都已经滚瓜乱熟了，我记得很早之前，说面试你如果不会微服务，那都找不到工作(PS:现在好像不管你会什么，也同样都找不到)😂。
对于AI应用，可能更多的软件生态是由Python带动起来的，包括一些工具库LangChain、LlamaIndex等都是Python，虽然Java中也不乏有一些，比如LangChain4j、Spring-AI等组件，都是后起之秀，在整个生态稳定性等方面确实是落后了一节。
但可能很多人都在用过LangChain等框架后有一个共识，那就是当作工具用没有问题，但是上生产？问题太多了。我觉得主要的几个点：
而我们今天讨论的是整个产品的技术架构的选择，其实在上面业务功能/技术组件抽象那一节，我们已经拆分了功能和技术点，从技术点去看，这已经是一个集众多服务于一体的综合技术解决方案了。在应用层面的功能，我们是否还需要像以前那样，整一套微服务架构出来来开发业务功能？
我的个人看法是：根据团队配置，微服务可用可不用。但是应用程序必须天然分布式，支持横向扩展集群，弹性伸缩。
目前这个环境，项目搞微服务，最后的困境可能就是所有服务都是你一个人负责，写完a服务写b服务，再来个rpc调用，还要考虑数据熔断、可用性等等，小团队我觉得完全没必要折腾！
主要考虑的点：
1、海量非结构化数据处理的提效
在处理RAG产品类中，非结构化数据的处理除了快速解析之外，还需要将文本进行向量化，而我们在技术架构中需要能够快速的处理这些文件，通过Pipeline的方式，将非结构化数据最终存储到向量数据库中，这里面传统的做法不得不用消息中间件MQ，而应用层面的程序则可以通过考虑弹性伸缩的方式，扩充消费节点，以提高整体的处理效率
2、海量向量数据的存储/计算召回效率
当我们对非结构化数据进行提取后，需要经过Embedding模型进行向量化，这里面还涉及到文本的Chunking分块，所以底层向量数据的存储和计算必然是一个需要更全面的考虑向量数据库中间件，这其中包括：向量召回的性能、数据的存储/备份、多租户Schema级别数据权限等等
3、数据最终一致性
数据的Embedding处理、大模型调度扣费、缓存等等，在目前已经众多服务组件拆分的情况下，整个数据的处理任务我觉得需要保证数据的最终一致性，在分布式场景下，多节点处理时需要特别注意。
4、应用功能原子性（云原生）
整个应用层的功能，我觉得需要保持独立，并且保障稳定性，这点其实我觉得在私有化部署/交付的环节比较奏效。如果你是一名运维或者主力开发者，在一个完全内网隔离的环境下部署时，你会体会到这种便捷。
总之，我觉得在应用层面服务，服务端应该做的是：减少配置、轻量化、稳定
我们团队目前的开发语言是Java+Python的组合，主要有职责分工：
这里面很多开发可能会有一些担忧，对于Java语言的选择，是否在目前的RAG/大模型领域合适？其实最困惑的就是非结构化数据的处理，可能很多开发者看到目前开源的众多组件或者平台，都是Python的主技术栈，认为Java处理不了，其实这是完全有误区的，对于最难处理的PDF文件提取，Apache PDFBox绝对是值得你深挖的一个组件，当然Python本来就擅长数据处理/分析，可以根据团队的配置进行执行选择，这里面我觉得主要考虑的几个点：
1、团队人员配置
根据团队当前的主流编程语言去做技术架构上的选型和决策，并没有绝对意义上的以哪个编程语言为主，Java、Python、Go、NodeJS、TypeScript等等都可以。
2、软件生态&技术成熟度
上层应用产品的开发，肯定首先要考虑有哪些成熟的中间件和组件，来开发完成这一众多的需求，总不能从0到1造轮子，造轮子固然能提升开发人员的水平技能，但是在AI日益发展的今天，为公司产品尽早的找到PMF才是首要任务。需要综合考虑。
其他的编程语言我不了解，就非结构化数据的解析这一块，其实Python和Java都相对更加丰富和稳 定。
Java语言中比较好用的包括：Apache PDFBox、POI、Tika
Python中包括：PyMuPDF、pdfplumber、pypdf、camelot、python-docx等等
3、稳定性/集群/高可用
嗯，这里没有高并发，因为大家都没卡😂
大模型的产品相比较传统的业务在这点上并没有 太多的区别，稳定性/集群等特点也是需要的，技术人员在选择中间件时，也应当考虑这一点。
例如MQ消息中间件、缓存Redis等等
4、部署实施/交付
没错，最后一步部署实施这个环节也需要考虑，Docker确实能带来极大的便利，但是成本也是需要考量的，目前的Python生态打包整个Docker，压缩包动辄2、3G起步，其实也是蛮头疼的，如果你是使用K8s调度来部署，k8s拉取一个10G的镜像也不是那么快的😂
AI应用是一个需要快速试错、功能强大的某一个点去突破，技术架构上，也应当考虑整体的开发效率、生态等等。
这让我想起来十几年前的jQuery，一经面世，得到众多开发者的喜爱，经典名言：
Write Less, Do More!!!
在大模型日益健壮发展的同时，我们的技术架构，是否也应该做一次瘦身呢？
如果你也在关注大模型、RAG检索增强生成技术，欢迎关注我，一起探索学习、成长～！
通过小demo的方式跟大家分享一下我对DDD中战术层级的理解，算是抛砖引玉，该理解仅代表我个人在现阶段的一个理解，也可能未来随着业务经验深入，还会有不同的理解。