编辑 |郑丽媛出品 | CSDN（ID：CSDNnews）在 21 世纪的科技浪潮中，AI 无疑是最为耀眼的明星之一。随着技术的不断演进，如今 AI 已逐渐从实验室走向实际应用，其中 AI 编程工具的兴起以及大型语言模型（LLM）的广泛应用，更是将 AI 技术的发展推向了新的高潮。
为此，在 11 月 14-15 日于北京正式拉开帷幕的 2024 全球机器学习技术大会上，我们围绕“AI 编程与大模型应用创新”这一主题，邀请了来自阿里、 腾讯、百度、字节跳动、智谱、商汤科技、腾、小米和 360 等 12 位一线技术专家。他们从 AI 编码助手、大模型推理优化到 AI Agent 的应用探索，全面解析了技术变革中的核心趋势与实践路径，共同探讨 AI 技术在软件开发、生产力提升及应用创新上的无限可能。
陈鑫AI 研发产品进化论：从 AI 编码助手到 AI 程序员在 AI 技术的飞速发展下，AI 编程作为当前技术发展的热点领域，不仅展现出极大的应用潜力，也对开发者社区带来了深远影响。以通义灵码为例，其总下载量已突破 700 万次，为开发者编写了超过 10 亿行代码，并且还在快速增长。
然而，阿里云通义灵码技术负责人陈鑫指出，目前 AI 编程工具的发展还处于初期阶段，其功能和体验仍存在诸多不足，如代码生成质量不稳定、开发者不会写复杂的提示词、不知如何与 AI 高效对话，同时在代码补全之外，他们也希望 AI 工具能辅助完成更多复杂任务。
那么，要如何解决这些问题，让开发者真正感受到 AI Coding 带来的高效与便利？
对此，陈鑫提出了四个满足开发者诉求的关键技术方向：模型、数据、扩展和智能体。
（1）模型：模型是 AI 代码助手的核心，也是决定其能力上限的关键。要想在代码生成、补全以及问答任务中表现出色，可从两个方面入手：优化代码补全模型以及训练专用任务模型。
（2）数据：代码库的数据体量庞大且复杂，如何高效利用这些数据，是提升 AI 代码助手能力的又一关键。例如，可对代码库进行准确的分析和检索；使用企业上传的规范代码样例，指导开发者生成符合标准的代码；集成企业内部系统的上下文数据，进一步提升模型的准确性。
（3）扩展：通过引入自定义指令和上下文管理功能，我们可以解决提示词编写困难的问题。同时，智能体技术也将进一步扩展模型的能力边界，例如支持更复杂的代码任务、生成可用的测试代码或完成代码重构。
（4）智能体：目前 AI 代码助手还只是作为一种简单的辅助工具出现，开发者的工作方式并未因此彻底改革，而智能体将有望突破代码助手的能力上限。
陈鑫表示，代码智能体的发展大致可划分为三个阶段：简单辅助（人类完成绝大部分工作）→智能助手（人类和 AI 协作工作）→AI 主导（AI 完成绝大部分工作）。在这个过程中，开发者将感受到智能体带来全新体验。
首先，AI 编码能力从片段级到多文件级。代码助手的能力会从单文件简单的片段级别注释生成、单测生成、代码优化等，进化到多文件级别的编码任务，例如需求实现、批量测试用例生成、多文件代码评审、批量代码重构、三方依赖升级等。
其次，可端到端地完成一个完整编码任务。开发者只需要输入准确的需求和上下文，AI可自主完成从需求理解、任务规划、代码生成、DIFF生成全过程。开发者无需从零开始编码，而是基于AI生成结果完成任务。
再者，会有更多的复杂步骤实现自动化。例如，AI 可进一步实现上下文自动感知、编程工具自动使用、自动功能验证、自我反思迭代等自动化能力，进一步释放开发者的生产力。
最重要的是，智能体将成为可以信任的编程伙伴。随着模型能力、Agent 能力的成熟，开发者可以更加信任 AI，并倾向于尽可能多的编码任务交给 AI 完成，即所谓的“信任拐点“。
基于以上目标，陈鑫提到目前通义灵码也推出了一系列智能体级别的“AI 程序员”，例如可辅助需求实现的 Dev Agents，全自动修复缺陷的 Bugfix Agents 以及全自动生成单测的 UnitTest Agents。
张少博：基于 CodeGeex 的 AI Coding 实践与探索面对同一个 MVP（创建最小可行性产品）项目，码龄 19 年的资深工程师 Alex vs. 码龄仅 4 年的年轻工程师 Hamid，你认为谁的开发进度会更快？一周后的结果显示：利用现代 AI 编程工具的 Hamid，其项目进度为 95%，而完全依靠手动编程的 Alex 只完成了 7%“这个案例，直观展现了 AI 编程工具在开发效率上的巨大优势。”智谱 AI CodeGeex 高级算法工程师张少博表示。
在此背景下，智谱自 2022 年起坚持对基于 GLM 大模型基座的 CodeGeeX 不断迭代，并于 2024 年 7 月正式发布了最新一代 CodeGeeX 4 系列模型，大幅增强了代码领域各项能力：使用单一模型，即可支持代码补全、代码生成、代码解释、代码注释、工具调用；具备项目级问答、联网搜索、编写提交信息等全面能力，覆盖了编程开发的各种场景。
在模型研发之外，张少博指出将模型能力转化为实际应用是技术落地的重要一步。
功能的设计并非凭空想象，而是依赖于对用户需求的深入了解和分析。张少博表示，CodeGeeX 4 的更新方向很大程度上基于开发者生态调查报告，其结果揭示了开发者在实际工作中对 AI 工具的期待与需求。为此，智谱设计并实现了一系列功能，包括代码补全、代码解释、代码注释生成等基础功能，以及项目级问答、联网搜索等高级功能。
以项目级问答为例，目前这是一项开发者既需要又难以实现的高级功能。该功能如果开发成功，可为开发者节省大量时间、显著提升开发效率。本质上来说，项目级问答的核心是语义检索（Retrieval-Augmented Generation, RAG），然而在传统 RAG 流程中，张少博认为有几个可优化模块：
（1）文件切分
文件切分是代码解析的基础步骤，直接影响检索的上下文准确性。但是单纯基于长度的切分方式容易破坏代码逻辑，而基于关键词切分虽能保留更多逻辑，但仍可能丢失上下文信息。基于此，CodeGeeX 4 引入了抽象语法树（AST）提取代码结构节点，重新组织代码片段，确保切分后保留完整的上下文和结构信息。
（2）向量模型
向量模型的核心是将代码与自然语言转化为可比较的表征，进而实现高效检索。然而开源通用向量模型在代码场景能力有限，如 BGE-V3 的准确率仅为 50% 左右，准确率较高的闭源模型成本又太高。对于这个问题，张少博指出：可自研模型并针对代码语义特性进行微调。
（3）检索策略
单一的相似度检索策略无法满足复杂问题的需求。对此，可采用“摘要生成”和“重排序”进行优化：为每段代码片段生成文件信息及总结性摘要，提升问答相关性；将用户问题与代码片段一同输入模型，使模型能同时理解问题和片段，提高相关性判断精度。
（4）问答模型
如果问答模型能支持更长的上下文、处理更多片段，就能适应更复杂的问题。为了实现这个目标，可进行阶段式训练以激发其长文本能力，同时结合短文本和长文本数据训练，确保模型也保留短文本性能。
（5）用户提问
用户的提问质量对模型回答的质量有直接影响。但在真实场景中，开发者往往提问不够清晰，甚至可能带有歧义。在接收到用户查询后，首先要识别意图判断是否启动全面分析流程，其次根据问题分类进行优化处理：对于无关问题（如简单问候）快速响应，对抽象问题（如“这个项目做了什么”）进行任务拆解，对代词和模糊表达的问题（如“第一个文件”）进行消歧。
江波：豆包MarsCode，智能编程的探索实践正如字节跳动豆包MarsCode团队算法专家江波所说，智能编程这项技术在近 20 年间不断演进，近年来的爆发式发展却尤为瞩目，其中 GitHub Copilot 的成功更是在业界引起了很大关注：借助 OpenAI GPT-3 和 CodeX 模型，它显著提升了代码补全场景下的性能和准确度。
参考 GitHub Copilot 的成功经验，豆包MarsCode团队在 2022 年初开始探索代码补全领域的发展路径：从基于开源 LLM 模型构建 MVP，组建算法、工程和产品一体的智能编程助手团队，到构建代码 LLM 评测集和自动评测系统以及数据链路和线上 A/B 测试体系，到今年 6 月发布国内版豆包MarsCode Al编程助手，并最新引入了基于 Chat 的 Copilot 和代码补全 Pro 功能。
从开发者对 AI 编程的需求来看，大致可分为代码生成、代码理解、问题修复和知识问答这四种场景。其中，关于代码生成中的代码补全功能，江波基于豆包MarsCode的经验总结了三个核心要素：
（1）仓库级上下文感知引擎：自研 ContextModule 引擎，负责召回相似代码片段、符号定义、历史光标浏览片段、代码编辑历史等，实现仓库级上下文感知。
（2）自研代码补全模型：完全自主自研，包括预训练数据爬取、清洗以及 Fill-In-the-Middle 增强训练、Repo-Level 拼接等，针对特定语言、特定框架精调，实现极低的推理时延。
（3）前后处理策略：基于静态分析工具对补全代码进行语法正确性校验，提供必要的后处理，确保内容的连贯以及语法完整性。
同时，江波指出代码补全的测评指标不应只看采纳率：虽然采纳率能被直观感受，但无法带来优化指导意见为此，应使用更全面、合理的指标：CPO（Character per Opportunity）= (尝试率) x (反馈率) x (采纳率) x (每次采纳平均 token 数) x (token 平均字符长度)。
不过，一般的代码补全都专注于编写全新代码，无法胜任存量代码的修改和删除。基于此，豆包MarsCode引入了代码补全 Pro 功能：可根据前置编辑的内容，去预测下一次编辑的位置和内容，甚至可实现单文件多处、仓库内跨文件编辑点位预测与跳转。据江波介绍，该功能背后的实践思路为：基于豆包大模型，通过大量开源仓库历史 Commit 中建模从历史编辑生成当前编辑推荐。
在代码修复方面，江波建议可采取多 Agent 协作的方式进行优化：让不同的 Agent 担任特定任务（如定位问题、分析错误、生成修复代码），相互配合完成复杂任务；同时，结合外部工具进行代码结构分析、报错细化和逻辑验证。除此之外，要想在项目问答中实现“准、快、简”，在模型方面可加强长文理解和动态 Prompt 渲染，整体上也可以集成联网搜索功能以解决开发者的通用研发问答。
在演讲最后，江波对智能编程的未来进行了一番展望。在他看来，短期内可期待模型结构与效率提升、长文理解能力加强、实现多模态及推理与反思能力，但从长期来看，Scaling Law 的局限性和 Test-time Compute 还存在很大的不确定性不过整体而言，他认为 span style="background-color:rgb(255, 255, 255);font-size:15px;letter-spacing:1px">AI 辅助编程仍将逐渐演进为 AI 驱动编程，随着智能体不断发展，软件开发将被持续革命。
徐晓强：大模型到智能体，软件研发流程变化了什么？自上世纪六十年代「软件工程」这个概念被提出以来，这几十年来该领域已沉淀了一套全面且复杂的研发流程。从需求阶段，到开发测试，再到最后的产品发布，整个流程存在的核心哲学就是：保证研发活动快而有序近年来 AI 技术的演进，更是给传统研发注入了新动力。
百度文心快码架构师徐晓强指出，目前大量公司正在使用或探索 AI：40% 的公司已经在业务中应用 AI；42% 的公司正在内部探索 AI。但是，LLMs 的助力范围仍然有限：
●缺乏深入思考：只会将推理结果一股脑输出，不会考虑信息完整性、、没能和用户的意图深层结合起来。
●能力单一：只会在特定场景发挥作用，不会考虑环境等信息。
●需要人工介入：人工投入占比较高，不会自主去完成某个特定工作的整个流程。
面对这些问题，徐晓强提出了一个疑问：能否进一步挖掘大模型的能力，使其对研发流程有更深层次的改变？这个答案，或许就是智能体（Agent）。
根据维基百科上 Agent 的定义，“一个可以观察周围环境并作出行动以达到某个目标的自主实体，通常是指（但不一定是）一个软件程序”，徐晓强总结 Agent 的原理就是：以 LLM 为基础，通过思考 & 记忆，执行工具 & 行动，让开发者委能够托 Agent 自主完成任务。
基于此，徐晓强介绍了百度文心快码在这方面的具体实践，即它在六大场景推出的智能体应用。
（1）续写智能体：传统的代码续写方式往往局限于静态上下文中，仅依靠光标位置进行插入，且无法感知开发者的真实意图和环境变化。而续写智能体可思考动作与代码逻辑之间的关系，支持多点动作，记忆用户操作历史，多维理解意图，并联动多种工具，集成更多开发环境。
（2）问答智能体：传统代码问答依赖搜索引擎，但常因信息不足、匹配度低而效果不佳，大模型虽有帮助，对复杂问题仍难精确回答。而问答智能体可通过问题分析与意图识别能力，结合后台代码验证以提供更针对性的回答，并反思用户反馈提升服务质量、满足个性化需求。
（3）Debug 智能体：传统错误修复方法耗时费力易出错，且难以关联多次错误，改正还可能引入新错误，不符合业务需求。Debug 智能体通过全程模型自主思考、逐步排查 bug 根源，并加入验证环节，显著提升修复效果，最后执行命令、与 IDE 联动，保证修复结果正确。
（4）单测智能体：传统单元测试依赖手动编写脚本，效率低且成本高，自动生成脚本冗余且缺乏针对性。为解决此问题，单测智能体采用新策略：理解业务逻辑，多工具协同确保测试准确；反馈执行结果，感知覆盖率，识别冗余；提醒业务逻辑错误，指导修正。
（5）安全智能体：在传统的安全检查中，静态扫描存在局限，且手动修复要求开发者学习漏洞原理与解决方案，成本高昂。而在安全智能体的帮助下，可打通从扫描到修复的全链路，自动扫描并修复代码，最后通过思考来优化修复策略，提高了修复效率并确保系统的安全性。
（6）全栈编程智能体：为了整体提高开发效率和代码质量，全栈编程智能体需要满足更大的任务背景（从静态的文件代码到整个项目），实现更丰富的生成行为（从纯代码文本到文件级的增、删、改），提供更智能的人机交互（基于任务的多轮调整与优化）。
徐晓强表示在 Agent 的加持下， 目前 AI 正在重构软件研发流程和范式。在演讲最后，他还向开发者发出倡议：不要只是单纯地使用 AI，而要真正地去和 AI 协同工作。
张功贯：大数据研效场景的智能化探索围绕“大数据研效场景的智能化探索”这一主题，腾讯平台智能技术架构师张功贯带来了富有深刻洞见的精彩演讲。
在大数据场景中，随着智能化技术的逐步落地，各个角色的工作内容和分工协作需要进一步明确和分析。张功贯指出，大数据研效场景中的角色通常可划分为三类：负责业务逻辑的数据科学家/分析师（DA），负责数据逻辑的数据仓库工程师（DE），以及负责底层技术的引擎/运维工程师（SE）。
虽然这三类角色的关注点各不相同，但在研效场景中，所有业务点都离不开成本、效率、稳定性的考量基于此，张功贯强调 AI4Data（AI for Data）的能力模型，要围绕成本、效率和稳定性来打造智能化能力，具体可分为 AI4DataSystem 和 AI4DataWareHouse。
●AI4DataSystem 能力落地
在 AI4DataSystem 的构建过程中，以传统机器学习结合专家经验为基础打造一套完整的思路体系。
对于任何数据系统或智能化系统来说，可控性都是至关重要的。因此可在数据感知方面投入大量精力，将其细化到 JVM 粒度的数据采集，准确把握关键性能指标。同时，建立一个 360° 的指标评估体系，支撑到任务、进程粒度的数据上卷和下钻能力，量化那些背后看不见的内容。
而在大数据生态环境中，从业务系统到大数据引擎，组件链路复杂且调用路径冗长，问题排查效率较低。为解决这一痛点，张功贯提出：开发一个全链路诊断系统，使其能针对每个组件设置诊断点，结合已采集到的指标数据，快速定位问题所在。
除此之外，在智能调优方面，基于对实际进程运行数据（如 CPU、内存等）的感知，结合白盒+黑盒的优化机制，可节省超过 50% 的内存成本 + 30% 的 CPU 成本，实现对资源利用率的优化控制。
●AI4DataWareHouse 能力落地
AI4DataWareHouse 的核心目标是从业务视角出发，为数据分析师提供更高效、更直观的支持。通常情况下，如 SQL 生成、诊断、SQL 优化等数仓生产、数据分析工作，都是从既定的 SQL 逻辑往引擎下层推进，因此缺乏对业务逻辑算法重构的能力。但张功贯指出：LLM 的出现，突破了这层限制。
不同于只考虑算力、技术计算算法问题的基于系统引擎的优化改进，基于业务的 SQL 优化将更多考虑业务逻辑、业务算法上的合理性这也正是 SQL-Copilot 智能体的作用。然而，大模型业务在落地过程中，仍面临四大关键问题：大模型的幻觉问题、文本的长度问题、业务的可迭代性问题以及业务结果可评测性问题。
针对上述问题，张功贯分享了一些系统性的解决方案：
（1）对于幻觉问题和可迭代性问题，可引入 SQL 问题分类模型。先将问题细分为多个类别，再根据不同类别的特点进行更有针对性的优化与调整，逐步迭代解决方案，以此减少幻觉问题的发生。
（2）对于业务结果的可验证性问题，可建立一套“双跑机制”的验证方案，即每天对优化前后的 SQL 执行情况进行抽样对比，以此来监测系统在 SQL 智能优化方面带来的实际业务效果。
通过对数千个数据分析场景案例的观察，张功贯表示引入 SQL 智能体后，其业务评测数据得到了显著提升：结果一致率达到 71.05%，正向优化占比为 73.58%，正向优化提升时间均值高达 85.37s，正向优化提升比例均值也达到了 30.58%。
提及对于未来的下一步规划，张功贯指出目前 SQL 智能体在数仓场景中的落地还存在挑战：由于 SQL 语句变得很长，会导致严重的幻觉问题。基于此，他提供了一些思考：首先，可将复杂的 SQL 语句进行切分再提交给大模型处理，以降低单次处理的复杂度；其次，针对长文本场景对大语言模型进行微调，例如引入一些压缩机制，以提高模型处理长 SQL 语句的能力。
张涛有用到好用：AI 生产力工具如何放大 AI 能力近年来，生成式 AI 的发展在各类场景中表现出了强大的潜力，特别是在代码生成和编程辅助领域。而随着代码模型与解决方案的演进成熟，商汤科技 Copilot 应用技术负责人张涛指出目前 AI 在开发场景的需求已被验证：60% 以上开发者正在使用 AI 编程助手，独立任务对比实验中总体工作时间减少了 55%。
在张涛看来，代码大模型的核心竞争力在于如何发挥AI优势，助力代码开发。聚焦到程序员身上，就是为其解决痛点（扬长补短的使用能力）并减轻压力（新的解决问题的体验）。
从程序员视角出发，构建编程工具主要有四个阶段：LLM、Code LLM、Code Copilot 和 Code Agent。在开发场景中，目前大家常见的 AI 代码助手就类似于 Code Copilot，其工作流程主要包括三个方面：
●代码补全：不仅支持多种编程语言，还能抓取仓库级信息，确保补全建议既准确又上下文相关。
●对话问答：无论是解决特定的代码问题，还是基于知识库进行更广泛的技术咨询，都能迅速给出答案。此外还具备执行内置代码任务的能力，比如代码重构、代码翻译、代码纠错以及单元测试生成。
●开发协助：除了自动生成 Commit Message 外，还允许开发者使用预设的智能体/自定义智能体来辅助日常开发任务，为团队协作提供了极大便利。
“如果我们不仅想生成代码，还想把它的功能扩展得更多，应该再做一些什么优化？”张涛指出，这就是从 Code Copilot 迭代到 Code Agent 了。首先，可以通过如添加网络检索和 API 调用等工具调用，来满足仅需简单获取信息、基本只调用一个 API 的简单场景。其次，面对需串联很多 API 调用、组合多种功能接口的复杂场景，张涛建议引入代码运行沙盒，即：Agent 根据用户需求生成代码后直接在沙盒中运行，验证其功能是否符合预期；当需求表述模糊时，可通过代码迭代将任务逐步细化；此外，沙盒环境还能捕获运行中的错误并提供调试信息，让 Agent 可以自动修复问题。
基于此，Code Agent 的应用就不仅局限于代码场景，而是可以向数据分析等其他领域扩展其中，商汤科技推出的 AI 数据分析工具“小浣熊”就是典型案例之一。
紧接着，面对代码大模型是否能成为“银弹”的这个问题，张涛表示要先从第一步做起：让代码大模型在当前的开发场景基础上，进一步扩展其适用范围，帮助更多团队成员高效完成工作。虽然代码大模型的起点是开发工作，但还有许多与开发并列的重要岗位，例如完成需求分析与制定优先级的产品经理、规划迭代周期并跟踪进展的项目经理、负责内部版本验收的测试人员，以及完成部署上线及实时处理告警的运维工程师。
经过需求分析，张涛发现这些岗位的任务中约 80% 可以利用当前代码大模型的能力完成，另外如用户界面设计或图像处理等需求，也可以通过引入多模态组件，在未来的技术框架中得到支持。
最后关于生产力工具形态的选择，张涛也总结了他的两个观点：
（1）相较于 LUI（语言界面），GUI（图形界面）形态更能打造最佳场景体验。因为 LUI 在描述复杂需求时存在局限性，如表达不清和“幻觉”问题，导致效率不高，尤其是在编程等需要精确逻辑的任务中。
（2）以 AI+ 而非 +AI 形式来打造 AI Native 应用。纵观全局的产品定义和功能需求，他指出以数据为中心驱动产品设计，更易于形成 All In One 的综合工具形态，降低上下文切换成本。
张君：大模型推理加速的优化实践推理，作为大模型从训练到应用的关键环节，其速度和准确性直接关系到模型的实际效用。如何有效加速大模型的推理过程，也已然成为 AI 领域亟待解决的关键问题之一。基于这个话题，腾生态技术专家张君带来了“大模型推理加速的优化实践”的主题演讲。
现阶段而言，大模型推理主要面临三大技术挑战。首先是计算和内存需求高：超大模型参数、超长序列等是大模型的发展趋势，大计算和内存需求高。其次是延迟和吞吐量之间的平衡：自回归算力利用率低，低时延高吞吐难以兼顾。最后是推理成本逐渐增加：大模型应用场景走向多元化，从单模态到多模态，再到 OpenAI o1，使得计算量和显存进一步增加，推理的时间和成本也随之增长。
针对这些挑战，学术界和工业界提出了很多大模型推理加速技术。其中张君指出，在实际业务场景中，通过从算子层、算法层和框架层对推理的加速，可极大提升大模型的推理能力。
●算子层优化：利用算子加速库如 ONNX Runtime 或 TVM，或手工进行算子融合将多个基本算子融合成一个复杂算子，减少内存访问次数，加快计算速度。
●算法层优化：通过算法层面的修改或者创新，如模型分片策略优化，投机采样，量化压缩等手段，减少存储空间和计算资源的需求，提高推理速度。
●框架层优化：推理的部署形态，大部分都以框架（引擎）实现，在框架层实现数据、计算调度、内存分片等操作，如 Continous Batching，PageAttention，PD 分离部署等。
基于此，张君详细介绍了腾大模型推理框架 MindIE-LLM 及其进行的一系列加速实践。从框架架构来看，MindIE-LLM 主要分成五个部分：LLM Manager，Text Generator，Modeling，Distributed 和 Quantization。针对各种核心问题，MindIE-LLM 实行了 PD 分离部署、多机推理 & 通信计算融合以及并行解码等多种优化操作，以全方位提升模型推理效率和用户体验。
除此之外，为了显著提升 Transformer 模型的训练和推理速度，腾 Transformer 领域加速库 ATB（Ascend Transformer Boost）也应运而生：基于华为 Ascend AI 处理器，专门为 Transformer 模型的训练和推理而设计。具体来说，ATB 加速库功能体现在以下几个方面：
（1）提供原生的高性能基础 Operation，包括单算子，融合算子，通信算子，量化算子等。
（2）提供 Operation 接口原型和 Plugin 框架，用户可以自己开发 AscendC 算子。
（3）提供构图接口，用户可以使用原生的 Operation 和 Plugin Operation 组成复杂的算子图。
（4）提供维测 log 接口和 profiling 接口，使用问题定位和性能分析。
为此，ATB 也采用了一系列优化策略：内存优化中间张量、tilling data、scratch memory统一管理，执行之前提前规划内存地址，做到地址的最大复用；全局 tiling 缓存一次性全部加载所有 op tilling data；流水并行调度策略异步执行图计算，在 NPU 仍在计算时，提前准备下一个图的计算资源。
最后展望未来，张君提出了三种具有前瞻性的可能性。首先，他设想通过开发更为极致的压缩量化算法，甚至探索 Transformer 模块功能的替代方案，以实现计算量的进一步缩减。其次，针对 Prefill 和 Decode 两大环节，张君思考了是否有可能设计专门的硬件解决方案，分别针对 bound 和 IO bound 问题进行优化。最后，他还提出了异构加速的思路，即考虑将那些与当前硬件不亲和的计算任务转移到 CPU 上执行，充分利用CPU强大的多核并行处理能力来实现加速。
高鹏至：小米在 AI Agent 上的思考和探索在过去的两三年里，我们见证了大语言模型（LLMs）在参数规模和通用能力上的飞速发展，但人类与大语言模型的交互方式却较为单一：通常是以文本为输入，输出同样的文本结果。
这种简单的交互方式在处理复杂任务时，往往难以满足实际需求于是，Agent 的概念被提出并迅速引发关注。小米大模型团队高级算法工程师高鹏至指出，Agent 工作流更适合解决复杂问题：任务拆解，子任务分配以及多 Agent 合作。
目前，Agent 已在代码生成、工作流自动化、个人助理、机器人等多个领域广泛应用，并展现出强大的潜力。而从小米的角度来看，手机依然是未来十年的个人计算中心，同时智能家居场景又拥有丰富的感知设备和复杂场景，基于此高鹏至表示：Agent + 手机/智能家居是“天作之合”。
他认为，Agent 在手机上会有三种未来形态：
●工具学习：Agent 通过调用 APP 的服务或内容完成任务，即利用 API 或工具接口，与单个 APP 深度集成，从而精准完成任务。
● GUI Agent：大模型与多模态技术结合，可以直接理解手机屏幕内容，解析 GUI（图形用户界面）的布局与操作逻辑，即 Agent 能够模拟用户点击、滑动等交互动作，完成操作。
●中心化 Multi-Agent：当单个 APP 无法解决复杂任务时，需要借助多个 APP 的协同操作，即 Multi-Agent 通过任务分解和子任务调度，实现任务链路的高效运作。
自去年开始，小米大模型团队在 Agent 方面做了许多探索。其中，高鹏至重点介绍了 ToolPlanner，一种工具增强的 LLM，用于多粒度指令的路径规划和反馈。关于 ToolPlanner 的工作动机，高鹏至表示主要来源于两个核心问题：一是在真实场景中，用户通常不会使用带有API名称的指令，而是用更自然的语言来描述他们的意图；二是之前的工作关注大模型能否最终生成一个合理的答案，而忽略了它们的指令遵循能力。
在进入具体的工作讨论前，他强调了该项目的一些关键背景：
（1）与外部工具交互的方案原型。ToolPlanner 的核心思想源自于 ICLR 2023 中 ReAct 相关论文，其方案可简单总结为 Thought-Action-Observation 的循环操作，若模型认为任务已完成，则模型可以跳出循环并生成答案。
（2）数据原型。ToolPlanner 用到的数据集是 ToolBench，它是当前最大规模的 API 级别工具学习数据集之一，包含了 16K+ 个 API 和 12K+ 个用 ChatGPT 生成的数据示例。
（3）常见的工具增强 LLM 结构。工具增强大模型通常由外部工具池、检索器和主模型组成，在每一轮中，大模型可以进行思考、与外部工具交互、提出解决方案和重新开始（可选）这几项操作。
其中，由于 ToolBench 数据集在设计上具有一定局限性，缺乏对用户自然语言意图的全面覆盖，小米团队基于此构建了 MGToolBench。它通过引入多粒度用户指令，模拟了用户表达意图的不同层次，旨在更真实地反映实际场景中用户可能提出的问题。另外，ToolPlanner 的训练策略上共有两个阶段：阶段一，利用 Cross-Entropy Loss 的正常 SFT；阶段二，Rank Responses to align Human Feedback（RRHF）。
在演讲最后，高鹏至展示了部分实验结果，显示 ToolPlanner 在许多任务中都表现优异并超越了 GPT-4 等最先进的模型，验证了多粒度指令能更好地与用户的使用习惯对齐。
圆桌论坛：大模型应用创新与实践在 AI 技术快速发展的浪潮中，大模型的崛起正在重塑各行各业的应用场景和实践方式。如何将大模型的潜力转化为实际的生产力，成为学术界和产业界共同关注的焦点。
在本次以“大模型应用创新与实践”为主题的圆桌对话中，Athena Labs CTO 王兴明担任主持，与来自学术和工业界的三位重量级嘉宾深入探讨这一领域的机遇与挑战：中国石油大学（北京）人工智能学院计算机系系主任吕仲琪，通义实验室高级搜索算法专家丁瑞雪，以及 360 人工智能研究院知识图谱与文档理解算法负责人刘焕勇。他们结合各自的研究与实践经历，共同探索大模型在实际应用中的创新路径与未来前景，为我们揭示技术落地背后的思考与洞察。
在大模型的创新应用与实践之间，“POC 一分钟，上线一整年”这句话或许是许多企业做 RAG 的真实写照。对于中国石油大学（北京）副教授，人工智能学院计算机系系主任吕仲琪来说，学术界的研究往往停留在 POC 阶段，直接上线的机会较少。为了感受这个体验，他们试着将 RAG 技术应用到石油领域：围绕石油行业相关数据做了一个数据集，而该领域的数据多分布于边缘设备，难以汇聚到互联网，且高度专业化，当前开源的大语言模型难以理解。通过这次尝试，吕仲琪强调，并不存在哪个行业不适合做 RAG，反而是那些尚未被广泛开发的行业，往往更容易诞生创新应用。
而针对大模型实践过程中的多样化数据，尤其是包含文本、图片等多模态信息的数据，通义实验室高级搜索算法专家丁瑞雪指出，在实际操作中需要采用灵活而高效的技术方案。具体来说，在处理多模态数据时，通常会分别为文本和图片建立独立的向量索引，同时根据需求选择统一嵌入或分开处理的方式。尽管后者的架构更复杂，但能显著提升效果。到了数据召回阶段，可采用单路或多路召回策略，将文本和图片关联数据综合返回。而为了实现更高效的整合，她表示可以设计一个在线 Agent 来负责判断如何组织数据，例如是通过 OCR 将图片转化为文本，还是直接调用多模态大模型完成联合推理等。
最后，围绕 AI 如何变现这个行业难题，360 人工智能研究院知识图谱及文档理解算法方向负责人刘焕勇指出，想要通过 RAG（检索增强生成）技术赚钱，需要综合考虑市场定位、技术实现和实际应用。首先，关键是找到有支付能力的客户群体，资金充裕的大型机构可能是更理想的目标，因为中小企业通常预算有限。其次，在选择应用场景时，应避免进入已被大模型广泛覆盖且竞争激烈的领域，如通用客服，这类场景容易被大模型压制，难以形成优势。相反，应聚焦在特定领域的高门槛应用，例如石油行业的特殊需求，结合自身技术积累和行业壁垒，才能实现差异化竞争。
