如今，拥有强大的语言理解、推理、生成和知识能力，甚至涌现出类似人类的能力的大模型技术，为我们带来了新的机遇。黎洋指出，特别是 AI Agent 技术的发展，使得以自然语言交互方式高度自动化执行复杂任务成为可能。
基于这些维度，黎洋分享道，倘若把大模型技术带入数据研发全流程中，借助它的知识推理、知识压缩、信息理解等能力无疑可以有效解决传统数据研发中需求排期慢、开发效率低、取数流程长以及治理效果差等问题。
进而，也可以基于大模型相关的技术为处理数据研发的整个流程打造一个AI智能体，即大数据智能体，可以用它来接收用户的自然意图（文字，截图，语音等）作为输入、以大语言模型作为规划中枢大脑、整合现有大数据平台的数据知识与数据服务工具。同时，在数据工程、数据科学、数据分析环节提供自动化的智能决策和智能分析服务。
在演讲中，黎洋表示，智能数据研发也没有想象中那么简单，至少需要“过三关”：
第一，在数据接入和数据地图环节的“找数”问题。对于许多数据开发工程师来说，这个过程非常困难，因为他们可能不了解底层数据存储的详细信息。因此，当需要获取上层应用的数据时，他们往往不知道应该查找哪些数据库、哪些表以及哪些字段。此外，元数据质量参差不齐、知识整理标准不一、人力维护消耗、答案正确性评价难、指标加工的复杂 SQL 逻辑理解难度大都是难点。
第二，在数据地图和数据分析的使用环节中的“用数”问题。用户在用数据时，最大的难点之一就是口语化表达的不一致，导致大模型在理解这些名词时会出现偏差。其次，大模型对于深度业务知识理解、分析方言的兼容都有所不同。
第三，在数据可视化和数据洞察环节的“懂数”问题。包括类似于增长分析这样的业务的场景，它的难点在于它是完全业务导向的一个深度的分析，同时需求多变、需要定制化建设。
基于这些机遇与挑战，腾讯大数据团队在智能化方向进行了一系列能力建设，包括沉淀领域原子能力、理解业务私域知识、优化领域模型、集成专用工具等等。在此基础上，黎洋分享道，腾讯开发了三大智能体系统应用：Chat Data、Chat BI 和数据洞察。Chat Data 作为智能找数助手，实现了数据资产智能查找和 SQL 生成等功能，有效解决了海量数据和复杂字段指标带来的挑战；Chat BI 则通过对话式分析大幅降低了数据分析门槛，支持多轮对话、意图识别和问题联想等功能；数据洞察系统更是实现了从简单趋势分析到深度业务洞察的能力演进，能够支持增长分析等复杂分析任务。
在技术实现上，腾讯大数据团队综合运用了领域知识库建设、意图识别与优化、任务规划、工具调用、RAG 技术应用、数据增强与自动标注、模型微调和后处理策略等多项关键技术。黎洋表示，借助 AI Agent 加速研发只是一个起点，未来其也将在更多方面持续推进相关能力的建设，进一步提升大数据智能化的应用水平。
去哪儿旅行机票主流程 AIGC 探索实践
在本次论坛上，去哪儿旅行技术总监李佳奇坦言，带领一个业务研发团队，推进 AIGC 项目落地和探索也面临层层压力：一是公司高层对这一颠覆性技术的关注和焦虑，他们关心在 AIGC 时代如何保持技术团队的竞争力；二是团队的迷茫，担忧技术储备是否足够以及是否会被 AI 取代；三是市场用户对创新应用的期盼，期待着杀手级应用的问世。
李佳奇 去哪儿旅行技术总监
李佳奇认为压力往往是推动进步的动力。为此，去哪儿业务研发团队给出了三个应对策略，如开发 Langchain4J Qunar 框架、RAG/LlamaIndex4J 框架来打基建，结合既有的业务去找机会点，以及增强团队成员的 AIGC 技术储备，实现团队的整体升级。
针对初接触 AIGC 的团队该如何寻找落地点的问题，李佳奇分享了三个步骤：
标记阶段。尝试 AI 业务矩阵法，基于文本生成、图像生成、视频生成、逻辑推理分析等 AI 能力，探索搜索、预定、交易、出行、售后、用户体验和营销等业务场景的应用可能性，结合技术可行性和成本确认机会点。
探索阶段。这一阶段需要研发团队事先准备数据和测试集，因为数据质量直接决定项目最终的落地效果。再通过人工与代码结合的 Demo 验证结果，并提交给产品团队和业务团队进行确认，确保效果符合预期。
落地阶段。推出 MVP 版本并上线。内部上线验证和流程控制后，锁定技术资源进行封闭开发。整个过程通常周期较长（大约几个月），并进行自动化测试和小流量验证。
基于此，去哪儿在 AIGC 方面做了一些探索实践，其中之一是机票主流程的探索。李佳奇表示，这里的核心逻辑是：大模型在机票业务中被赋予业务专家、营销专家、售前导购、用户本身等角色，让大模型实时观察用户操作行为和看到的结果，通过大模型强大并且不断提升的思考、推理能力，来挖掘目前机票主流程在用户体验、产品力、营销等提升潜力并给出方案，再结合 Agent 的执行能力来执行有效动作。
如下图所示，用户行为和业务结果都会经过主流程网关。该网关具备一些能力，如挂载不同的代理（Agent）。利用这个功能，研发团队可以挂载推荐 Agent、营销 Agent、客服 Agent 等。这些代理不仅能接收到用户行为和数据，还能修改用户请求的响应结果，并将修改后的内容呈现给用户。
这些代理能够与大模型或多模态模型进行交互，并触发业务动作，如发放优惠券或弹窗通知用户。基于这套基础设施，去哪儿研发团队在主流程的探索就是通过不断扩展和更新代理的逻辑来实现的。每当其增加一个探索场景时，只需更新现有代理或添加新的代理，以插件式方式扩展即可，无需额外成本。
最后，对于正在带领业务研发团队且想要转型 AIGC 的负责人，李佳奇根据自己多年的经验，提供了三点建议，“作为团队负责人，提升自己的认知至关重要，并在团队内营造良好的技术氛围，确保团队对 AIGC 技术有深刻理解；打好基础设施，基础设施建设包括开发、测试和运行基建；团队建设需要一些技术领袖起到示范作用。配合机制和流程，确保团队有足够的 AIGC 技术储备。如果没有相关经验，项目周期会拉长，且可能无法成功落地。”
京东：大模型时代的算法服务体系演进
紧接着，京东物流神机妙算算法平台架构师檀江华带来了《大模型时代的算法服务体系演进》的主题演讲。
檀江华京东物流神机妙算算法平台架构师
檀江华为我们深度分享了京东物流神机妙算算法平台在大模型技术基础上的迭代历程。他介绍，神机妙算算法平台已经从 1.0 阶段过渡到 2.0 阶段，如今该平台的核心包括四个要素：数据服务、实验评估、模型部署和算法服务。
在数据方面，进入 2.0 阶段的神机妙算算法平台引入了更多文本数据、离线特征、实时特征、上下文特征和向量数据。檀江华提到，传统特征工程有一定的缺陷，因为特征按项目 case by case 开发，不仅效率低，且无法保证数据口径一致，很难沉淀、复用和维护。对此，神机妙算算法平台希望通过端到端的方式进行改进，于是，其使用动态 PB（Protocol Buffers）作为数据传输的“钥匙”，实现了数据的序列化和反序列化，支持版本管理和向前向后兼容。同时，平台采用一套代码生成同步引擎任务和特征服务代码，支持 Spark 和 Flink 平台，提供多维度批量查询接口。
此外，檀江华表示，检索增强生成，通过在大模型调用时引入现有知识库，或者即时数据，是一种 ROI 比较高提升大模型性能的方式。
其次，实验评估是确保算法价值的关键环节。为了解决传统 AB 实验中存在的设计不规范、报告不中立、技术重复造轮子等问题，京东物流开发了一个专门的 AB 实验平台。这个平台允许用户创建实验、进行版本管理和合规性检查。结合实验配置库会下发到算法在线服务或离线建模平台，最终产出实验报告。
在模型部署方面，檀江华指出，神机妙算算法平台实现了模型托管，用户可以一键部署和自动更新模型，解决了复杂的执行环境和依赖问题。同时，通过模型描述文件解决模型校验、预热等，支持模型自动预处理逻辑，保证线下线上一致性。
算法服务是将算法应用到实际业务中的最后一步。京东物流的算法服务平台分为两类：运筹优化算法服务和统计学习算法服务。
运筹优化算法服务针对网络规划、调度场景，平台开发了一个智能工具箱和应用包部署框架，支持 Python、Java 和常用求解器环境，并通过资源调度中心动态管理执行环境。平台还在开发一个基于多智能体的架构，用于重构网络规划算法业务，包括意图识别、洞察、规划和执行等多个智能体，以智能化处理复杂的规划任务。
统计学习算法服务平台开发了一个在线处理插件框架，将算法业务逻辑单独抽出为一个独立包。这个框架预置了特征、模型预测、数据源调用等能力，算法工程师只需要关注业务逻辑。平台支持热部署和算法灰度发布，还提供了在线 debug和测试能力。通过这种方式，实现了工程和算法工作的解耦，提高了开发效率。
在稳定性保障方面，该算法平台还提供了运维值班、故障演练、压测和扩缩容、应用健康度监控等工具和手段。檀江华透露，神机妙算平台赋能算法研发团队自主进行算法项目的开发、测试和上线。内部推行了类似自动驾驶的 L1-L4 等级，鼓励算法团队实现完全自助研发。
衍数科技：垂直行业大模型工程实践
从研发通用大模型到行业垂直大模型，这一转变中存在诸多难点。衍数科技的 CTO 吴岸城指出，在做垂直大模型时，企业在构建垂直数据往往主要面临三个问题：
高质量数据集的短缺：许多用户提供的数据集非常有限，通常只有单一的文章，且这些文档通常是未经处理的 Word 或 PDF 文件。这样的单一文档往往缺乏足够的质量和多样性，难以支撑高效的数据分析和建模工作。
数据预处理的瓶颈：在处理涉及企业私有数据的项目（如银行项目）时，企业无法将敏感数据上传到闭源平台（如 ChatGPT）进行数据增强。
数据多样化的挑战：面对更复杂的场景时，简单的数据集将使模型难以应对复杂问题。
吴岸城衍数科技的CTO
为了应对这些问题，企业需要在数据预处理和数据生成方面采取有效措施。吴岸城分享了在实践中使用的一些解决方案：
对于高质量数据集较少，可以使用大模型生成数据，然后进行脱敏处理。
对于生成的数据和目标数据存在很大差别问题，不妨试试给这些大模型一些 Prompt，如这段文字的主语是什么、这段文字主要在说什么、根据这段文本起10个不同问句。
在平衡通用数据与垂直领域数据时，可以选择一些训练方法，如 Fine tune、P-tuning、Lora、Q-Lora 等。
进而，确认大模型微调目标，如改变输出格式、学习新知识、提高精度、增强个性化推荐、优化决策支持、增强自然语言处理能力、提升数据安全与隐私保护，以及适应特定行业需求等。根据微调目标的不同，选择合适的技术方法。在选择微调方式时，吴岸城表示，可以考虑参数量与资源需求、客户需求与偏好等因素。
在垂直行业大模型工程实践中，做 RAG 也会涉及到数据的偏向性、及时性和准确性等问题。在吴岸城看来，普通 RAG 通过向量召回存在诸多局限性，如检索结果的质量参差不齐、精度不高，无法完全替代结构化信息提取的需求，也不能支持条件查询和统计功能。
对此，吴岸城表示，可以通过数据清洗和人工标注两种方法进行处理。在模型选择方面，用户可以根据 Hugging Face 趋势和评估结果来选择合适的模型。
至于如何提升产品的信息丰富度，针对未检索和难检索的问题，吴岸城提出了几种解决方案，如 Prompt 的追问、关键词检索和召回和重排序，混合检索。这些方法帮助企业从文本中提取关键信息，提升查询的精度和广度。
代理人工智能编程框架 AutoGen 的应用与实践
立足「未来的人工智能应用是什么样的，我们如何让每个开发者都有能力构建它们？」两个问题的思考，宾夕法尼亚州立大学助理教授、AutoGen 联合创始人吴清云及其团队联合微软共同研发并开源了 AutoGen（https://github.com/microsoft/autogen）这个 Agentic AI 通用编程框架。
吴清云表示，AutoGen 的核心概念之一是对话式智能体，这意味着任何一个 Agent 都可以通过对话的方式与满足框架下的其他 Agent 进行交流。这种设计赋予框架极高的灵活性、扩展性和易用性。有了对话式智能体，任何复杂的应用理论上都可以分解成两个步骤：第一步是定义一些智能体，第二步是让它们以某种方式进行交流，这些方式包括常见的顺序对话、嵌套对话、群组对话和层次对话等。
在论文中，吴清云及其团队实现并研究了以下六种应用场景。
以第一个数学问题的解决应用场景为例，吴清云表示，可以直接利用 AutoGen 提供的两个原生智能体来构建一个双智能体系统。这个系统类似于对话式智能体系统，可以根据人类输入模式的不同，选择自主解题或在人类参与下进行解题。值得注意的是，构建这个系统只需要几行代码，并且直接使用了 AutoGen 提供的两个智能体，没有针对特定应用进行任何优化，便能取得良好的效果。
其中，吴清云强调，AutoGen 的模块化设计使其支持的多智能体系统具有极高的扩展性。例如，在之前提到的双智能体系统基础上，我们可以轻松扩展，允许额外的智能体参与解题，只需要通过函数调用的方式实现扩展。举一个例子，如果用户是一名学生，他不仅希望有人工智能助手帮助解题，有时还希望能够与人类指导老师交流。在这种情况下，我们可以通过函数调用让 Assistant Agent 决定何时调用人类指导老师，从而实现更灵活和个性化的解题体验。
此外，吴清云还分享了一个供应链场景的示例。当用户提出一些假设性问题，例如“如果某个地区的咖啡烘焙成本上涨5%，会怎样？”时，单纯依靠一个大语言模型很难有效解决这些问题，因为这通常需要进行一系列复杂的计算和推理。如果由专家或人类来解决，通常会先将问题建模为一个优化问题，然后调用相关的优化算法进行求解，最后根据优化结果进行进一步的推理和解释，以回答终端用户的假设性问题。
使用 AutoGen 框架，可以轻松实现上述解决问题的流程。具体来说，在这个应用场景中，可以设计一个 Commander Agent，负责与终端用户直接对话。同时，引入一个 Coding Agent，负责将问题建模并编写相应的代码。由于这个问题需要进行建模和优化，Coding Agent 通过与 Commander Agent 的对话进行代码的运行和调试。
为了更贴近实际的工业场景，吴清云表示，这里还引入了一个 Safeguard Agent，负责安全检查，确保智能体编写的代码能够安全执行。通过 Autogen 框架，我们可以高效地解决供应链中的复杂优化问题。
展望未来，吴清云透露，AutoGen 正在深入研究和开发多项新功能，包括基于智能体的评估工具、降低编程门槛的低代码工具、智能代理的优化以及多模态模型的集成等。
eBay 风控实时特征平台
eBay 支付风控部门高级经理李杰在《eBay 风控实时特征平台》主题演讲分享了在线交易欺诈对特征平台的严苛要求以及 eBay 风控实时特征平台如何来应对这些要求。
他提到，在线交易欺诈涉及的风控检查会涉及 AI 模型和风控规则的实时推理和批量推理：实时推理大多用在用户在场的风控检查（比如同步阻止可疑的下单、绑卡或者提款操作），对模型和规则的响应速度要求高；批量推理则主要用在用户不在场的风控检查（比如审核用户已经上架的商品并下架可疑商品），对响应速度要求低。
李杰eBay 支付风控部门高级经理
国内支付体系的实名认证为在线交易风控带来了极大便利。eBay 交易风控场景由于缺乏这些实名信息支持，主要依靠 AI 模型和风控规则等技术手段来捕捉可疑的欺诈活动。为更好支持 AI 模型和风控规则的智能训练、仿真和低延迟的实时推理，eBay 开发了 eBay Risk Real-Time Feature Store 平台，它在风控系统中扮演着重要角色。
李杰表示，AI 模型对平台的要求分为离线和在线两个方面。离线阶段需要准备大规模特征瞬时值（Point-in-Time Value）供 AI 模型训练和仿真使用；在线阶段则需要实时生成准确的特征值并支持高效的特征批量获取以满足实时推理的低延迟要求。平台的关键目标之一是实现离线与在线数据的一致性。
此外，风控规则也对特征平台有几个关键要求。首先是自助服务功能使风控团队能够针对线上最新的欺诈活动作出快速响应。其次是 快速和自动化的特征冷启动。基于高效的大规模仿真回溯能力和在线离线数据一致性，该平台对新特征提供完善的冷启动机制，让需要回看一两年时间窗口的特征数据也能在数小时内完成冷启动并开始服务在线AI模型和规则。
在技术细节上，李杰分享了该平台的一些亮点：
高效的数据存储模型和DSL。针对Sliding Window 和 Lastk 这两种最为广泛使用的特征类型，该平台提供先进的存储模型达到高效的读写和存储效能。针对 Sliding Window 特征，通过将“天”、“小时”和“分钟”不同维度数据存入同一个数据存储单元，减少特征批量读取时的数据库 IO 开销；针对 Lastk 特征，相较于对特征对象整体进行编解码的传统方案，重新设计了一种基于索引块的数据模型来达成计算和存储模型统一，从而避免特征值更新时的反复编解码。除 Min、Max、Count、Sum、Distinct、Average、Standard Deviation、Time Decay、ZScore 等标准算子之外，借助于该平台提供的 DSL，算法团队可以按需定义任意计算逻辑。
该平台的在线计算引擎是基于Flink构建，通过在Flink Check Point中存储Kafka Offsets、Unique Delta ID list（业务层面去重）和Unapplied Delta List来确保数据至少被处理一次，以及在特征数据模型中存储已经处理过的Delta值的 Kafka 偏移量来确保特征值的幂等更新（最多处理一次）。最终确保数据业务层面的数据准确性。
该平台的离线瞬时值仿真引擎基于Spark构建。通过DSL构建的特征和数据字段的关联关系以及Driver set中的瞬时值范围来精确定位Event快照数据范围，极大提升大规模瞬时值的仿真效率。
基于离线瞬时值仿真引擎而构建的离线到在线的自动回填能力，可以帮助特征在几个小时内完成冷启动。
正如上文所提到的，李杰强调，设计平台的最终目标是确保在线和离线数据的一致性。至于如何保证一致性，他觉得可以从下面三方面保证：
使用 DSL 来定义特征，并能动态被Flink和Spark执行达成在线离线任务执行逻辑的一致性；
在线 Flink 任务消费的 Event 数据快照被存入离线 HDFS 文件作为离线 Spark 任务数据源，确保了在线离线计算引擎数据源的一致性；
在线 Flink 任务通过一种智能快照数据模型，结合先进的特征数据模型，来保证即使在基础组件如快照存储文件系统、数据库系统等不稳定情况下仍能保证所有 Event 数据处理的恰巧一次和业务层面的去重，离线 Spark 任务则通过去重机制结合 Event 快照落库任务的至少一次机制来确保离线数据处理的恰巧一次。离线批处理和在线流处理殊途同归，各自确保了数据的高度准确性。
美图在 AIGC 运维道路上的探索和挑战
前有工程师奋战在 AIGC 开发的一线，而在幕后，站点保障工程同样至关重要。在业务革新的浪潮中，如何有效地实施这些保障措施成为关键。美图资深 SRE 李彬在《美图：云原生架构构建AIGC业务坚实后盾》的主题演讲中，深入分享了这些关键技术和实践经验。
李彬美图资深 SRE
李彬透露，美图是为数不多通过 AI 规模化盈利的公司。在 AI 的驱动下，美图全球 VIP 会员数突破千万。
在将 AIGC 整合到业务流程中，他们也发现了在新模式下，业务传播速度快，留给工程师反应时间短；数据增长迅猛，容易产生爆款，所以对资源的需求也是巨大的、突发的；企业需要快速抢占市场，以获得竞争优势，因此需要快速交付资源。
在算力方面，李彬表示，美图将集群分为推理集群和训练集群。推理集群注重弹性伸缩、周边设施完善程度、业务稳定性、云原生成熟度以及资源供给；而训练集群专注于数据安全、计算能力、高性能存储、高性能网络以及故障自愈能力。
这些集群共同构成了美图的万卡集群，主要依赖 GPU 和 NPU 作为 AIGC 的算力支持。
起初，美图在 GPU 算力布局方面采用了单云架构，但后来发现资源竞争激烈、价格高昂、容灾能力不足等问题，因此转向多云架构。然而，多云架构也带来了新的挑战，如服务稳定性提升后，成本压力增大。因此，美图开始与 IDC 厂商合作，不过，IDC 厂商虽然价格便宜，但是周边设施不太完善，需要其投入更多的人力物力进行周边建设。
在这一过程中，美图围绕基准测试、厂商交付、内部交付和持续的协作等维度制定了一套交付标准。一旦资源交付完成，美图便开始优化资源的使用效率。尽管采用了多元算力和多元管理策略，仍面临诸多挑战，如复杂的管理与维护、资源调度与优化、兼容性问题、供应链问题、故障恢复与灾备以及稳定性与成本之间的权衡。
为此，李彬表示，美图在多云管理和稳定性运营方面做了大量工作：
在架构选型上充分利用云原生技术，以K8s作为底座，构建多云生态，并根据网络拓扑、资源类型、规格配比等标准进行优化。
多云纳管方面，美图内部研发了多云容器管理平台 Matrix，统一管理所有生产集群。
在基础设施层面，其建立了统一的模型库、镜像分发平台、监控数据汇总、日志查询和多云告警系统等。
美图还开发了稳定性运营平台，定期生成所有核心业务的运行状态和监控数据。
除此之外，在多运营流量调度和弹性伸缩方面，美图采用了两种典型的算法业务模型：同步算法和异步算法。在同步算法中，流量进入算法网关后，会根据比例分流至不同容器集群，确保资源高效利用。而异步算法则将任务写入消息队列，待其他云端任务启动后，消息队列中的任务进行本地处理和上传操作。
最后，为了实现更高效、智能和成本优化的多因管理，美图持续进行精细化运营，通过数据驱动业务决策，评估业务 ROI，并针对亏损业务提出转化或下线的建议，进而对资源供给、包月策略持续优化。
大模型应用落地实践
本次论坛的最后，在 Boolan 首席咨询师李沫南的主持下，衍数科技 CTO 吴岸城、去哪儿旅行技术总监李佳奇、eBay 支付风控部门高级经理李杰齐聚一堂，深度剖析了 AI 如何重塑业务形态，分享了各自在 AI 赋能业务方面的独到见解与实践经验，为与会者呈现了一场思维碰撞与智慧交融的盛宴。
大模型经过一年半的发展，从最初的高度期待到发现诸多问题，经历了过山车式的变化。李沫南指出，这引出了一个重要问题：在技术峰值时期，许多公司可能做出了一些承诺或启动了一些项目，但现在却面临在当前大语言模型能力下如何顺利完成这些项目、确保这些项目成功交付的挑战。
对此，吴岸城认为，关键在于项目管理，而不仅仅是技术问题。项目管理涉及多个方面：事前的客户预期管理、事中的需求沟通和调整、以及后期的复盘和问题解决。这些才是更为关键的部分。其次才是技术问题。技术问题本质上是对大模型认知的逐步深化和经验的逐渐积累。例如，在为金融保险领域的客户落地项目时，我们会进行 LoRa 微调或全参数微调。随着时间的推移，我们对大模型的理解不断变化和提升，这自然会带来一些技术上的挑战。
最后，如果在项目初期设定了过高的目标，现在却发现难以实现，那么最好的解决办法就是坦诚面对，承认目前的技术水平确实达不到预期。不论是数据还是算法层面，都有其局限性。在承认这一点的基础上，应尽最大努力贴近预期目标，这样的态度才是良好的乙方态度。
紧接着，李杰在对话中分享了他对企业更广泛地拥抱 AIGC 技术的看法和见解。他表示，在重新面向大语言模型设置业务，或者吸收新的革命性技术时，我们应尽量把宏大的目标和叙事拆分成可落地的小任务。这些小任务能够让相关方，尤其是那些出钱并有决策权的人，看到短期的成果，从而增强他们的信心并持续投入。
另一方面，在用大语言模型改进业务流程时，可能会触及业务部门的利益。例如，提高效率后，某些人工审核的工作可能会减少，从而导致裁员等问题。在这种情况下，我们该如何应对？我认为关键在于让这些相关方站在未来的角度思考问题。
随着技术的发展，对于未来是否可能出现「一家公司只有一个自然人，其余的全都是 AI 代理」的设想，李佳奇表示，在深入研究和学习 AI 技术的过程中，当第一次看到 GPT、ChatGPT，甚至最早的 AutoGPT 时，它们能自主完成如此复杂的任务，他的团队确实被震撼到了。因此，李佳奇坚信未来一定会有“一人公司”的出现，因为大模型的能力确实非常强大。
不过，李佳奇认为工程师不会因为 AI 而被替代。在实际业务落地过程中，仍然需要工程能力和技术手段来确保大模型按预期工作。工程师的角色可能会发生变化，从执行者转变为编排者。他们不再是简单的操作人员，而是从更高层面来设计和管理整个流程。工程师们也需要撰写合理的剧本，安排角色的分工与协作方式，制定故事的主线和核心矛盾，并确保整个过程朝着解决核心问题的方向推进。
至于何时能实现“一个人公司”，“老实说，这目前有点超出我的认知范围。我认为我们需要持续关注 AI 的发展，才能更好地回答这个问题”，李佳奇说。
以上，便是本场论坛的精彩内容。
| 欢迎光临 链载Ai (https://www.lianzai.com/) | Powered by Discuz! X3.5 |