本期主题
大模型如何快速赋能企业AI应用创新?
RAG、Prompt优化分别适用于哪些情形？
回答专家：
高金杨，阿里云百炼算法架构负责人
刘阳，阿里云百炼模型工程架构负责人
深度问答
Q1：阿里云百炼作为一个模型服务及应用开发平台服务20万家客户AI落地创新，有让人印象深刻的案例吗？
高金杨： 百炼是一个to B的平台，to B的客户大体分为两大类。一类就是to B他自己做提效，比如说从数据清洗到企业内部的一些应用、工具链，它自己内部的RPA，会有大量这种类型的场景。另外一类客户，做的是（to B）和to C，我们对他是to B的生意，但同时他又拿我们这个产品去做他自己to C的业务。这里会涉及到很多场景，比如客服类型的场景，还有游戏类型的客户会拿我们这个模型去做游戏里面的NPC。最后还有一类场景是广泛地涉及到多模态的输入输出，比较典型的就是物流类型的场景，我们可能会拿它去做质检。
Q2：当前市面上的大模型服务平台其实非常多。大模型落地仍存在一些痛点，比如说效果比较差，成本比较贵，落地也比较难。您觉得哪些因素还会影响企业用户在模型上的选择呢？
高金杨：从工具链的层面上，坦诚讲，确实市面上的产品很多，每个云厂商基本都有产品。同时，从国外的到国内的Dify，其实有非常多开源的选择。单纯就工具链的应用本身，从可用性的角度上，门槛并没有特别高。我们每一个人都可以拿Dify或者拿LlamaIndex去搭一套rag的基础方案。那百炼平台在哪些角度去影响客户的选择呢？
大体上会分为三部分。一部分是单纯的工具，单点的工具可能是一个没有门槛的事情。但是往往我们谈到工具链的时候，是一个工具绑着一个模型。也就是说比如rag，它其实是一个搜索链路绑着一个大模型的生成。涉及到多个工具的调用的时候，可能就会有多次大模型的调用。这就是一个很高的成本，像一个overhead。我们的这个应用，有时候我们去搭一个agent类型应用，可能十几秒二十几秒的延迟往往就是这么来的。那怎么样去做好工具链的整合，我觉得这是一个很高门槛的事情。在这个方面来讲，我跟技术团队一起去进行了很多配合的实践，就推出了Assistant API这个产品。
另外一个角度是什么呢？多数时候，当我们谈到工具链的时候，都只是拿工具链搭了一个pipeline。业界看来，就是一个POC类型的产品去做了一个对吧？我们只是把这个流程串起来。但是我们可能传统做AI的时候，会讲AI这个事情是有多少人工就有多少智能，对吧？当然可能这个背后不是人工，而是各种各样数据的努力。我们再一点点去解这个bad case。所以从这个角度上，我觉得就引入另外一个话题，我们做一个工具链平台，或者说做一个模型应用开发平台，不只是为了大家把这个架子搭出来。也就是说，希望我们能够去帮助客户真正实现一个成功的效果。那这个过程就涉及到怎么从一个POC做到交付，怎么从交付上线之后做好持续的效果提升，怎么样把大模型应用当中数据的价值充分发挥出来，转化成模型的效果，这是第二个方面。
第三个方面是什么呢？任何时候，当我们去采用一个工具链平台的时候，往往它都涉及到架构的选择，以及后续的可持续开发。从这个角度上来讲，可能大家都会觉得最安全的一个方案是用一个开源的方案。后续把所有的开发能力落在自己这边，会非常有自信说可以掌控这个项目。我们去用一个比如说云厂商的版本，比如百炼，可能每个客户都会有疑虑，百炼未来能不能把我的这些需求支撑好，我会去这么思考这个问题。这个问题是说我们提供的并不是能百分之百支持好客户的所有需求，而是平台需要有开放性，能够让客户把他的需求在这个平台当中有效地表达出来。从这个角度来看，百炼平台坚持了一个非常开放性的原则。在接口上，比如说接口，基本跟OpenAI保持完全的对齐跟匹配。
Q3：百炼作为一个模型服务平台,对于本身的数据中心，或者说数据集的建设有什么计划?
刘阳：数据和模型本身就是两者绑定的,不可能独立分开。我们在百炼平台上提供了数据中心,主要功能包括像给训练还有评测提供数据，以及像rag知识库，也有上传的渠道。那在从数据这个对象单独来说，我们会继续来扩展它的易用性，包括像后面数据导入的易用性。我们再换个角度来看，其实数据它不光只是静态的data在那里,后面百炼需要来提供包括数据的一个流程性的东西,包括数据如何导入，以及基于大模型以及其他智能方式生成一些数据等来方便B端客户更好地训练或者评测模型。
Q4：魔搭和百炼都提供了一站式模型服务工具，在实际使用过程当中，该如何选择?
刘阳：我恰好是一个魔搭平台的贡献者，所以这个问题挺好的。我们认为开源和闭源这两件事情是相辅相成的，它并没有冲突。开源平台有各种各样的小模型可以供你选择，有很多开源的框架可以用。在百炼上当然也有自己的优势，像我们推出的Qwen-max这样的model，它本身具有闭源的优势性，尤其在百炼平台可接入，它是面向客户更加易用的方式，在产品形态上会更简单一些。而开源的形式稍微需要开发门槛，需要操作的同学或者工程师懂一些相关的技术。
此外，这两者也是有融合的可能性的。比如有一家头部客户，他想要来使用AI或者做一个AI的产品。他完全可以使用百炼平台提供的（Qwen-max）或者plus这样的基模能力，再搭配魔搭上面提供的小模型，把这整体合成一个完善的项目，这都是一个很好的结合点。
Q5：检索增强RAG中有哪些好用的Chunk切分方法？
刘阳：在Chunk当中，主要把文本分成两类，结构化和非结构化的数据。结构化的数据会比较容易，因为有具体的表格等，按照行列以及标题等来处理会更好。非结构化的数据往往会让大家犯难，尤其B端数据如果没有清洗过的话，经常会遇到非结构化的数据。那通用的方式会按照版面，尤其像PDF，去提取其中的分页、分段的内容。除此之外，可能还会从语义方面去考虑，比如按照它语义的相关度进行分割。这些都是从方法角度来讨论，我们具体还要看这个客户他遇到的问题是什么，结合具体的问题来选择最合适的方法。
Q6：在大模型的项目当中，如何判断用rag还是用微调？
高金杨：这个问题其实可以涵盖另外一个概念一起看。一个是rag，另外一个是prompt提示词，还有一个是微调。他们三者之间的应用的边界确实非常模糊。甚至很多时候一个应用有很多种搭建的方法，在这三者里边，我觉得可以给大家一些推荐的选项。
比如说微调其实最适用的是哪几个类型的场景呢？第一点是对RT，即反馈路径的时长有特别高要求的时候，我们往往会选择微调一个小模型，这是事半功倍的一个事情。什么样的场景比较适合用微调呢？当我们对回答方式有特别高的要求的时候。也就是说我们会希望在微调阶段做的是一些RLHF或者DPO的事情。举例而言，我们希望让这个模型的回答更像人一点。这种拟人的事情是非常适合微调来做。那什么样的事情特别适合用rag来做？当我们对回答要求特别准确的时候用rag。Prompt可能是一种更宽泛的应用方式。当你发现这个事情rag不好做，或者微调不好做，或者希望交给模型更多的样本时，我会比较鼓励大家采用（In-Context-Learning）的方式，通过prompt方式喂进去。