专栏名称: 字节跳动技术团队
字节跳动的技术实践分享
目录
相关文章推荐
字节跳动技术团队  ·  掘金 AI 编程社区- 人人都是 AI 编程家竞赛 ·  8 小时前  
字节跳动技术团队  ·  ByteBrain团队EuroSys25 ... ·  昨天  
InfoQ Pro  ·  充电计划 | 反卷“大”模型 ·  昨天  
InfoQ Pro  ·  Redis 之父:哪怕被喷我也得说,AI ... ·  昨天  
字节跳动技术团队  ·  基于LLM的AI应急:多模态信息智能化分析整 ... ·  2 天前  
51好读  ›  专栏  ›  字节跳动技术团队

AI 与星辰大海:2025,从新手到开挂勇士的奇幻旅程

字节跳动技术团队  · 公众号  · 架构  · 2025-02-11 18:00

正文

请到「今天看啥」查看全文


「实际上MQM这种多维度评估体系也可以应用在翻译之外的领域,如润色、故事生成等。甚至可以被用在图片打分。他们背后的原理都是类似的,都是通过发挥 LLM 出色的自然语言理解能力 + 通过自然语言描述框架来实现一些复杂的打分工作。」

功能落地

上边我们只是利用了 LLM 的自然语言处理能力。如果我们想让模型帮我们回答一些不是通识性知识点的问题时该怎么办呢?

模型也可以像人一样,碰到不会的东西时可以先去 「查询」 然后再 「基于查询结果进行判断和回答」

比如说我们想为审核员提供一个问答机器人回答一些审核领域相关的问题,或者基于以往的审核结果进行回答。

又或者我们想基于某一个数据库中的结果对审核员的问题进行回答

但是对于不同类型的内容,知识库在生产过程中采用的分割策略,结构等会大大影响最终问答质量的表现。如:

  • 「Chunking」 : 如当对于大段内容进行拆分时要拆分的多细,拆分后的信息是否应该保留整体上下文方便后续参考时使用等。
  • 「Embedding」 「Model」 : 需要针对需要支持的语言来选择向量化模型,不同的模型在召回准确度上也有不小的区别。

当我们检索到的相关知识后可以通过将这些信息连同原始问题一并作为输入给模型并让模型基于相关知识点尝试回答。

「当我们积累了一系列能力后,如果快速的向其他方向上推广和扩展?」

随着越来越多基于 LLM 能力的需求落地,我们发现其实所有的 LLM 能力都可以被总结为: 「一个带顺序的分步流程」 。其中模型调用只是工作流中的一个步骤/节点。如果我们能快速的复用这个 「分步流程」 就可以快速的对取得成功的能力进行推广。

                             (分步流程可视化示意图)

随着我们对现有的一些优秀 LLM 编排能力库/平台的深入了解,我们发现现有的方案都无法很好的对我们的业务场景提供100%的支持。甚至大多数都无法通过 「合规」 这一环节。更不用说可能 「业务有自己的模型、数据库、基础能力」 等等。我们需要在业务下实现一套 「定制的」 「流程引擎」

流程引擎本质上可以被拆解为一下两种图的类型:

  • 「DAG」 「有向无环图」 。一般用作承载」 经典 Workflow 场景」 。需要注意的是这种图不能包含循环所以一般被用作实现单一 Agent 能力。
  • 「FSM」 「有限」 「状态机」 。用作实现如 「Multi-Agent 场景或有环的场景」 。是 DAG 的一个补充。但是需要注意的是因为状态机同时之后有一个激活状态所以并发分支等能力无法通过 FSM 实现。

当我们实现了上述两种流程引擎后可以进行组合实现更复杂的能力如:FSM 中嵌套 DAG,DAG 中嵌套 FSM 等等。

当我们有了上述流程引擎和对应的 DSL 之后。我们就可以在业务间快速复用能力(只要复制一下 DSL 或基于现有的 DSL 做二次开发就好了)。

可能你会问,为什么不根据需求直接把这些逻辑写在代码里呢?实际上在日常开发过程中我们发现大部分功能都是通过对有限能力的组合来实现的。如果不做流程引擎的建设会带来很大效率上的降低以及多余的开发量。

其他实践

Hornbill 是内部用于多个平台的 「Oncall 工单管理工具」 ,拥有三种升级策略。我们处理工单的团队包括用户运营团队和研发工程师,并在创建工单时自动拉入相关人员进行协作。由于审核员需要快速处理大量审核任务,Hornbill 通过 24 小时的用户运营团队快速解决问题,技术问题会被升级至研发解决。

Hornbill SDK 可整合到平台中,帮助用户在提交工单前通过 FAQ 寻找解决方案,从而减少不必要的工单。 「每周约有 几百个由用户运营团队处理的工单,因此减少工单数量可以让团队将时间用于更高价值的任务。」

「为了提高工单解决的效率并减少工单数量,我们引入了」 「AI」 「功能。」

首先, 「相似工单检测能够有效识别并链接具有相同问题的工单」 ,通过创建问题描述的嵌入向量,并使用向量相似性计算如余弦相似度,系统在用户提交新工单时可提示已有相似工单,推荐用户加入现有工单而非新建,或在工单提交后提醒用户操作团队进行链接,从而减少重复工单处理的工作量。

其次, 「AI」 「摘要生成功能则通过自动生成问题的总结」 ,在群聊中梳理出问题描述、原因和结论,提供给不同班次的用户操作团队以保持问题处理的一致性。这一功能通过将所有的群聊内容传递给大型语言模型生成总结,从而避免因班次交接导致的上下文丢失,提高工单解决的连续性和效率。这些先进的 AI 功能减少了用户操作团队在票务处理上的重复性工作,让他们能够将更多时间投入到更具价值的任务中,不仅提升了团队的工作效率,也提高了用户问题解决的速度和质量,为用户提供了更优质的体验。

另外,Hornbill SDK FAQ 搜索功能旨在 「解决用户自行反馈且可通过非技术知识解决问题的工单。」 通过将常见问题生成 FAQ,用户可以搜索相关知识库,并根据输入查询定制 FAQ 内容,使其更易理解。方法是为常见的可自解决问题创建 FAQ,并对 FAQ 问题进行向量嵌入,将其存储在向量数据库中。当用户输入问题时,我们利用余弦相似度比对向量嵌入,以找到匹配的 FAQ,并通过大型语言模型总结 FAQ 内容,展示给用户。这一功能减少了不必要的工单,提升了用户的自助解决效率。

总结

当我们完成了对流程引擎的落地,同时在流程中有技巧性的使用 LLM。基本上 「领域下的产品/业务诉求」 都可以基于这一套框架来实现。LLM 除了可以为我们做分类,识别等功能以外也可以帮助我们做离线验证/数据评估等工作。与可视化编排界面配合可以大幅降低使用门槛。 「对于一个想要使用 LLM 能力来实现业务诉求的业务方,不论是」 「PM」 「同学还是运营同学都可以进行尝试可以大大解决研发的人力缺口。」

提升开发体验

AI 编程在今年有了比较大的发展,因为出现了 Cursor、Windsurf、v0、bolt.new 这些,在不同场景下,成为了能指数级提升生产力的工具。这不仅仅得益于越来越强的模型能力,也得益于许多在应用/交互上的创新与探索。

工具形态

传统工具的替代品

搜索、文档工具、设计稿代码生成工具等

信息搜索(以前用 Google )

文档查阅(之前文档站)

D2C

多智能体自然语言编程

代表工具:gpt-pilot、gpt-engineer、MetaGPT

这类工具直接通过自然语言与一个多智能体系统进行交互,多智能体系统会在内部划分多个角色/任务,如:程序员/开发/调试、架构师/设计、产品经理/拆解、项目经理/任务管理等。

但这类工具要将整个工程从新建到功能推进完全交给智能体维护,用户只能通过指令和自然语言对话对工程进行控制,并且受限于上下文窗口,也无法构建复杂的平台系统。使得这些工具都没有办法用于程序员日常的生产和实际的项目里。只能作为非专业人士的玩具,或者 AI 研究的尝试。

  • https://blog.pythagora.ai/2023/09/04/gpt-pilot-coding-workflow-part-2-3/

  • https://github.com/geekan/MetaGPT/blob/main/docs/resources/software_company_cd.jpeg

代码辅助工具







请到「今天看啥」查看全文