NarrateAI: production-ready LLM quality assurance on Amazon Bedrock

NarrateAI：在 Amazon Bedrock 上实现生产就绪的大型语言模型质量保障 | 人工智能

NarrateAI：在 Amazon Bedrock 上实现生产就绪的大型语言模型质量保障

高管在实时业务审查中需要基于数据做出决策，此时准确性和响应速度至关重要。对话式智能体AI助手可以通过即时回答数据问题来满足这一需求。但风险也很高：在领导层面前出现错误数据或延迟响应会立即带来职业后果，而仅依靠功能强大的大型语言模型（LLM）无法保证这两点。在生产环境中，这种差距会表现为幻觉指标、API限流、验证延迟和主观性语言。要弥补这一差距，需要在每个环节（从数据检索到响应交付）都内置生产就绪的质量保障机制。本文将详细介绍在 Amazon Bedrock 上实现的五项技术，它们协同工作以实现这一目标：自适应流水线编排、跨账户多模型故障转移、实时流式评估、复合评估框架和数据准确性验证。每种技术都针对不同的故障模式，同时作为协调系统运行。

本文是我们的 NarrateAI 系列的第二篇。NarrateAI 通过基于 Amazon Bedrock AgentCore 构建的双层架构，为超过 4,000 名 AWS 高管提供业务智能转型。该平台支持使用任何框架或模型大规模构建、连接和优化智能体。架构包含用于批量处理的自动化叙事生成层和用于实时交互的对话式AI接口层。上一篇文章介绍了业务挑战、整体架构、用户体验和企业部署。本文将深入探讨工程实现，展示这五项技术如何在实时流式传输响应的同时实现约 99% 的数值准确性。本文面向熟悉 LLM API 和流式响应的工程师和架构师，他们正在构建 LLM 应用程序。

从商业愿景到技术实现

本文专注于实时层中的高级质量保障机制。设想一位高管询问：“哪些地区未达成目标以及原因？”这五项技术协同工作，确保响应在数值上准确且实时到达。同时，系统在并发全球使用下仍能保持吞吐量，并以专业格式直接用于业务审查。

图1展示了这五种技术如何形成分层依赖链，每一层都会将处理结果传递给下一层，从而从原始查询中生成经过验证的实时响应。自适应流水线编排根据数据量对查询进行路由，使大多数简单查询能在一次快速处理中完成，而复杂查询则获得完整的并行处理。跨账户多模型故障转移通过在独立模型-账户配额空间中扩展推理能力，减少用户可见的限流现象。实时流式评估在段落生成的瞬间即进行验证，将质量检查与生成过程重叠进行。复合评估框架针对每个段落并行运行多个独立评估器。数据准确性验证通过两阶段级联检测数值幻觉，首先进行低成本的精确匹配，仅在必要时升级到语义验证。以下章节将按照流水线中出现的顺序，依次介绍每种技术，从数据检索到生成再到质量保障。

图1：五种质量保障技术如何分层协作，将原始查询转化为经过验证的实时响应

自适应流水线编排

企业知识文档包含大量信息，查询对信息的需求差异巨大。像“我的团队季度业绩如何？”这样聚焦的问题可能只需引用少数几个文档片段（从企业知识文档中检索到的离散块）。而“请提供完整的区域绩效分析”这类综合性请求则需要整合数百个文档内容。用户无论面对哪种查询都期待相同的响应速度。这种异构性要求采用一种路由策略，既能快速处理常见场景，又不牺牲对复杂场景的处理深度。

没有一种统一的处理策略能适用于所有查询，因为最佳方案取决于查询实际需要的数据量。单次拼接处理虽然快速廉价，但当聚合文档片段超出模型上下文窗口（通常为200K token）时会导致截断和质量损失。固定多轮批处理虽然避免了截断，但需要对每个查询都进行多次大模型调用，包括约90%实际上不需要的查询。我们的方案根据查询的总聚合文档量|D|（D为检索到的文档片段集合）进行路由：数据量适配时采用单次处理，必要时才启动批处理。最终形成一个三阶段流水线，对每个查询进行一次分类后，沿最经济且能保障质量的路径进行处理。

三阶段自适应处理

流水线最多分为三个阶段处理每个查询：模式感知整合阶段将检索到的文档片段打包并选择处理路径，分叉分析阶段根据选择的路径执行单次快速处理或并行常规处理，条件整合阶段在需要时合并并行处理结果。下表总结了两条路径如何通过这三个阶段，随后我们将详细解析每个阶段的处理流程。

| 快速路径（约90%的查询） | 常规路径（约10%的查询） | |------------------------|------------------------| | 触发条件 | 触发条件 | | 检索量|D| ≤ θ | 检索量|D| > θ | | 阶段1：模式感知整合 | 阶段1：模式感知整合 | | 所有片段拼接为单个块 | 片段按文档边界打包为N个批次 | | 阶段2：分叉分析 | 阶段2：分叉分析 | | 单次大模型调用，直接流式传输至评估 | N次并行大模型调用，每个批次一次 |

阶段三：条件整合

完全跳过

合并N项分析，解决冲突，流式传输最终答案

第一阶段是模式感知整合，它对检索到的文档部分进行操作。该阶段采用贪婪的首次适配打包策略，在不超过令牌限制的前提下填充上下文窗口，同时保留部分优先级顺序和部分边界。对于较小的文档量（|D|≤θ，其中θ是经验校准的字符计数阈值），所有部分会被拼接成一个单独的块，称为“快速路径”。对于较大的文档量（|D|>θ），部分会被打包成符合文档边界的最佳批次，称为“常规路径”。阈值θ相对于模型的上下文窗口限制进行设置，并校准以捕获70-90%的快速路径查询（实际上，约90%的查询采用此路径，如结果部分所示）。由于此阶段的执行模式是固定的，后续阶段可以针对各自的路径进行优化，而无需同时处理两种路径。

第二阶段是分叉分析，它执行选定的路径。快速路径通过完整上下文进行一次LLM调用，直接将结果流式传输到评估管道。常规路径将批次分布在N个并行LLM调用中（N是第一阶段生成的批次数量），这些调用独立分析块以实现接近线性的加速。

第三阶段是条件整合，它仅在常规路径上运行，通过将N个独立分析综合为统一响应。整合LLM接收包含原始问题的局部分析，同时应用冲突解决启发式方法并流式传输最终答案。快速路径完全跳过此阶段，因为最终响应仅使用一个分析。图2展示了完整的流程，两条路径最终汇聚到流式响应。

图2：三阶段流水线的端到端流程，显示快速路径绕过整合阶段

在生产环境中，这种基于阈值的路由带来了显著的效率提升。约90%的查询使用快速路径（单次LLM调用，首次生成令牌时间（TTFT）在几秒内，总延迟通常低于25秒）。剩余10%（复杂的多文档查询）接受完整的并行批次处理（约50-75秒，相比快速路径的25秒以内），与其复杂度相匹配。对于常规路径查询，通常使用N=4个批次，每个查询的综合成本约为1.4次LLM调用。这比始终使用多轮策略减少了72%的LLM调用次数，同时保持对复杂查询的完整质量覆盖。团队应根据其工作负载的查询量分布校准自己的阈值，并确保其低于模型的上下文窗口限制。

跨账户多模型故障转移

自适应流水线能够高效整合信息，但只有当其背后的模型持续可用时，快速流水线才有意义。在评审高峰期，当数千用户同时运行分析时，单个限流请求会削弱用户对工具的信心，迫使用户回归手动电子表格分析。标准的缓解方案——带抖动的指数退避——证明效果不足。Amazon Bedrock为每个模型和每个账户分配独立配额。将每个模型-账户组合视为独立容量空间，可在不新增基础设施的情况下成倍提升吞吐能力。我们不再等待容量释放，而是致力于发现从未被争夺的容量。本节将展示如何通过将每个模型-账户组合视为独立配额空间，在不新增基础设施的情况下实现容量倍增。

这些容量其实显而易见。Amazon Bedrock的配额在两个维度上独立：每个模型有独立限制，每个AWS账户也获得独立配额。因此，3模型×3账户的配置可提供9个独立配额空间。运行时，系统通过优先尝试排名最高的模型探索这个网格，同时随机化账户顺序以防止热点问题。该实现采用自定义Strands模型提供者，作为标准BedrockModel的即插即用替代方案，在保持与现有代理代码完全兼容的同时实现透明的容量扩展。图3展示了网格结构以及请求通过该网格的级联路径。

图3：3模型×3账户配置的故障转移级联，每个单元格是独立配额空间，请求仅在当前层级账户耗尽后才会降级至更低质量模型

三机制协调

三个机制协同工作实现这一目标。第一个是模型排序机制，建立质量-速度优先级。查询优先尝试排名最高的模型，仅在必要时级联，使用户自动获得最佳可用模型。第二个是账户级分布机制，通过随机负载均衡防止热点问题。每次故障转移尝试前，Python的random.shuffle()通过复制并原地洗牌AWS角色ARN列表实现随机化。负载随时间均匀分布在各账户上，无需复杂流量整形算法或集中协调。每个请求获得独立随机化，自然实现约1/N的流量分配（N为配置账户数）。这最大化了整个账户池的Amazon Bedrock API配额利用率。第三个是检测与快速恢复机制，完全避免退避。ThrottlingDetector捕获ThrottlingException、ServiceQuotaExceededException和TooManyRequestsException，立即尝试下一个模型-账户组合。AWS安全令牌服务（STS）AssumeRole可在100-200ms内获取新凭证，相比带抖动的指数退避多秒级延迟可忽略不计。

在覆盖超过4,000名用户的六个月生产部署中，N×M配额探索（其中N是模型数量，M是账户数量）成功吸收了流量激增，并在高峰期显著降低了用户可见的限流现象。改进程度与配置的模型-账户组合数量呈正相关。使用Locust框架进行的负载测试显示，系统能够持续支持超过100用户同时发起的模型请求，且未出现任何失败请求。下图展示了通过应用向Amazon Bedrock请求流式响应时，超过100个用户请求的负载测试详情。关键结论是基础设施无需扩展，配额空间本身实现了扩展。

图4：100+并发用户通过应用流式传输响应的负载测试结果

实时流式评估

当前的故障转移架构在配额压力下能够提供不间断的token流。然而，包含幻觉收入数据的可靠响应反而加剧了问题。没有准确性的可用性是一种隐患。我们最初的方案将质量检查作为顺序的后处理步骤：先生成完整响应，再运行评估器，最后交付验证后的输出。虽然这种方法实现了高准确性，但首次内容到达时间（TTFC）超过了1分钟，因为用户需要等待整个响应生成和评估完成后才能看到输出。这种准确性与响应速度之间的权衡促使我们提出一个关键问题：是否必须在验证开始前完成整个响应？本节将介绍通过使用生产者-消费者并发模式实现的并行评估架构，该架构回答了这个问题并几乎消除了验证开销。

段落独立性

验证第N段输出无需等待第N+1段生成。这种逻辑独立性使并行执行成为可能。它显著缩短了首次内容到达时间（TTFC），即从请求提交到用户看到首个已评估内容的耗时。

在顺序流水线中，用户需要等待所有段落生成并评估完成后才能看到任何内容。我们的并行方案在段落生成时立即进行验证，因此用户只需等待第一个段落生成和评估后即可看到内容，而无需等待整个响应完成。只有第一个段落会在用户看到内容前产生评估延迟。后续每个段落的评估会与下一个段落的生成并发执行，因此评估成本被包含在生成窗口内。对于每个后续段落，交付延迟仅取决于评估当前段落和生成下一段落中耗时更长的操作。

在实践中，段落生成耗时数秒，而确定性检查（如使用模糊词汇、表情符号）仅需数十毫秒，这种显著的稳定性余量使评估在常见场景下对用户几乎不可见，即使偶尔调用昂贵的基于LLM的评估也不会影响体验。

生产者-消费者架构与性能模型

图5：协调生产者、有界队列和消费者的生产者-消费者流式架构

该实现协调了三个异步组件。生产者任务从Amazon Bedrock流式API接收令牌，并通过可配置的启发式方法（Markdown边界使用双换行）将其累积为段落级单元。完整段落通过线程安全的有界缓冲区进行排队，该缓冲区采用互斥阻塞和先进先出（FIFO）顺序以保持一致性。哨兵值用于表示完成。消费者任务从缓冲区取出段落，执行顺序验证检查（如数据准确性验证），并将通过验证的内容以多词块形式流式传输，以实现平滑的交付体验。

在实际运行中，这种稳态行为会根据段落触发的评估器类型分为两种截然不同的模式。

定义λgen为段落生成速率，μeval为评估速率。缓冲区利用率ρ = λgen / μeval决定了系统平衡状态。由于评估方法的性质（确定性或基于LLM），我们预计ρ分布会呈现双峰特征，而非单一平均值。

在快速路径中，仅需确定性检查（如Weasel Word、Emoji）的段落评估耗时中位数约79ms，ρ ≈ 0.095，远低于1。在此模式下，缓冲区几乎为空，因为消费者需等待生成，评估过程不会引入可感知的延迟。在慢速路径中，触发基于LLM的数值验证的段落评估耗时中位数约2025ms，ρ中位数≈21.5，远高于1。在此模式下，反压机制会自然限制生产者的速率，防止队列无限制增长，同时消费者逐步追上处理进度。无内容丢失，当段落处理完成后交付会立即恢复。

这种模式划分是后文讨论的复合评估框架的直接结果。大多数文本在毫秒级内即可通过确定性检查，而包含数值指标的段落则会触发更深入的基于LLM的验证。

流式评估结果

为验证该架构，我们在企业部署环境中使用Anthropic Claude Sonnet在Amazon Bedrock上对1000个生产查询（约10439个段落）进行了性能测试，这些查询的商业智能请求平均每个响应包含超过10个段落。绝对时间值特定于该环境，但相对改进和架构模式可广泛适用于流式LLM部署。

| 评估模式 | 中位数TTFC | 与我们的方法相比 | |----------------------|------------|------------------------| | 并行流式处理 | 13.2秒 | – | | 无质量检查（未评估流式） | 11.8秒 | +1.4秒开销 | | 顺序后生成（基准） | 100.2秒 | 慢7.6倍 |

与顺序评估相比，并行架构实现了86.8%的延迟降低。与未评估流式处理相比的1.4秒差距仅反映了流水线达到稳态前首次段落评估的一次性开销。

复合评估框架

流式处理管道将段落传递给评估消费者，但单一的单体验证器只能解决一种故障模式。企业级质量保证需要同时覆盖多个正交维度。因此，该系统中的负责任AI具有双重性：Amazon Bedrock Guardrails在生成开始前筛选所有传入查询，复合评估器在段落到达用户前筛选所有传出段落。语言客观性、格式标准和数值准确性各自代表单一评估器无法覆盖的不同故障模式。本节介绍一种复合评估框架，通过共享接口协调独立评估器。正式的可扩展性约束确保该框架与前述实时流式处理架构保持兼容。

可扩展性

复合框架设计为持续扩展。如实时流式评估部分所述，每个评估器对管道缓冲区利用率ρ（评估延迟与生成时间的比率）做出贡献。只要所有评估器的ρ总和保持在1以下，添加新评估器就是有效的，这可保持流式处理管道的稳定性。在实际应用中，运行时间低于毫秒级的廉价确定性评估器可以无条件添加。昂贵的基于LLM的评估器必须触发足够少的段落，以保持加权贡献的有界性。

每个评估器实现标准接口。它接受段落内容作为输入，并返回带有检测到的问题和建议修正的通过/失败结果。这支持自主运行和与管道无关的集成。只要满足ρ准入约束，团队可以添加特定领域的评估器（如毒性检测、合规策略检查或货币格式验证），而无需修改管道。

三个参考评估器和自动修正器

我们实例化了三个针对商业智能响应中正交故障模式的评估器。

WeaselWordEvaluator通过正则表达式模式匹配强制客观语言，因为高管报告需要量化陈述（“16%增长”）而非主观描述（“强劲增长”）。EmojiEvaluator通过Unicode检测过滤对话表情符号，以保持正式呈现。DataAccuracyEvaluator处理数值幻觉，这是商业智能系统中风险最高的故障模式。伪造的指标传播到决策流程中会带来关键的合规风险，需要分两阶段的分层验证以实现全面验证。

评估器并行执行于同一段落，因此总评估延迟等于最慢触发评估器的延迟。评估器的严重违规会触发段落拒绝。可纠正的问题会调用配对的修正器。通用通过允许流式传输到用户。

自动修正将检测转化为可操作的补救措施。管道按顺序应用修正器。

• WeaselWordCorrector在保持语言流畅性的同时移除主观形容词。
• EmojiCorrector剥离Unicode字符。
• DataAccuracyCorrector通过“LLM Reasoning”标签标注伪造内容以保持透明度。

顺序至关重要。文本修改优先执行，随后是字符删除，最后是注释添加，这一流程为每个转换步骤提供稳定的输入。

复合评估结果

在生产环境中，复合框架标记的段落数量远超单一评估器独立运行时的水平。关键的是，近四分之一被标记的段落同时触发了两个或更多评估器，这意味着单一评估器部署将完全遗漏第二维度质量指标中并发出现的错误。这种多维度覆盖能力是复合方法的主要优势。扩展该框架的团队可通过单一接口实现新评估器的插接，只要总评估时间保持在段落生成窗口内，无需修改流水线。

数据准确性验证

在复合评估框架部分介绍的三个评估器中，DataAccuracyEvaluator针对影响最严重的故障模式。一个在语法上无误且措辞客观的响应仍可能虚构高管会采取行动的确切数字。实际场景中，这意味着当真实数据为“4.14亿美元”时报告“4.41亿美元”，这种差异足以在错误被发现前导致错误的资源配置决策。这种故障模式需要专用的两阶段验证架构，该架构从精确值匹配逐步过渡到语义验证。本节将介绍这种平衡检测精度与计算成本的架构。验证的第一阶段执行精确匹配以过滤无依据的输出，第二阶段则通过渐进式验证进行上下文验证，包括字符串相似性分析后接基于LLM的语义验证。

分层验证

幻觉检测面临相互冲突的目标。全面准确性需要语义理解，但实时部署要求亚秒级验证。单体LLM验证虽能保证准确性，但每段落需要2-3秒的不可接受延迟。纯粹的模式匹配虽然快速，但牺牲了上下文理解。例如，它可以正确提取“4.14亿美元”却无法检测到语义位置不当。两阶段架构通过渐进式计算投入的级联验证解决了这一矛盾。

该设计针对需要不同检测策略的两种错误模式。第一种错误模式是数值虚构，当LLM生成源语料库中不存在的指标时会发生。例如，当文档中仅包含“4.14亿美元”时报告“4.41亿美元”，或在源数据仅涵盖2024年第一季度时引用“2024年第三季度营收”。这些错误可通过第一阶段的精确值匹配进行确定性检测。第二种错误模式是上下文不匹配，当LLM错误应用源数据中已存在的指标时会发生，例如用营收数据进行成本讨论，将第一季度增长率应用于第三季度查询，或在不同业务单元间混淆指标。这些错误需要在第二阶段进行语义验证。分层方法针对每类错误应用适当的计算资源，对明显虚构内容使用廉价的精确匹配，仅在必要时进行昂贵的语义分析。

以下是技术文档的中文翻译：

两阶段级联验证机制的实际运作方式如下。第一阶段精确值匹配通过正则表达式模式从源文档和LLM响应中提取数值指标，然后检查响应中的每个指标是否在源数据集中存在精确匹配。未匹配的指标将被归类为"未验证"，从而以最低成本终止对虚假信息的验证。第二阶段渐进式上下文验证通过两个子阶段处理已匹配指标。2a阶段使用SequenceMatcher计算响应上下文Cr与源上下文Cs在w字符窗口（w=50）中的相似度ρ=ratio(Cr, Cs)。对于高相似度指标，直接归类为"匹配"，避免调用昂贵的LLM服务。2b阶段则通过ContextualDataAgent处理低相似度案例（σ<τ），执行语义验证以检测细微的上下文不匹配。这种级联设计将计算资源集中在最需要的环节。字符串相似度验证可在每个指标约1.7ms内完成清晰匹配判断，而LLM验证则在每次调用约1,758ms内处理模糊情况。

图6：从精确匹配到基于LLM的语义验证的两阶段数据准确性验证级联流程

各阶段的计算成本差异显著。第一阶段使用正则表达式和集合操作仅需约0.3ms。2a阶段字符串比较耗时约1.7ms。2b阶段LLM推理耗时约1,758ms。由于大多数指标能通过第一阶段验证（生产环境达87%），且仅有30%需要进入昂贵的2b阶段LLM验证，因此每个指标的有效平均成本约为812ms。这相比单一LLM验证方案实现了54%的成本降低。成本降低源于将大部分指标路由至廉价的确定性检查，仅小部分需要LLM验证。成本节约程度将因工作负载而异。数值内容比例较高的团队会有更多指标进入2b阶段，而文本密集型工作负载则能从早期终止机制中获益更多。

架构集成

这五种技术形成分层依赖链，每层都支撑上层功能。自适应流水线将可变文档量整合为LLM就绪的上下文，并将90%的查询路由至单次快速处理。该整合输出进入多模型跨账户故障转移层，该层将硬性API配额限制转化为透明路由决策，并为流式评估器提供不间断的token流。没有这种可用性保证，评估流水线必须同时处理质量失败和生成失败，这会显著增加设计复杂度。流式评估器针对可靠token流执行生产者-消费者并行化，在稳态下保持验证过程对用户不可见。复合框架和数据准确性级联机制接入消费者任务，在不破坏延迟预算的前提下，增加三维质量覆盖和数值幻觉检测能力。

在系统层面，生产部署中协调架构能够在大约13秒后开始流式传输响应，并保持99.3%的数值准确性。在为期六个月的部署中，每项请求均实现了持续可用性，无需专用验证基础设施、配额扩容或序列化瓶颈。

结论：弥合AI研究与生产实践之间的鸿沟

当高管在领导团队面前提出数据驱动的问题时，准确性和速度是不可妥协的。错误的指标或延迟的响应会立即带来职业后果。达到这一标准需要解决超越模型选择和基础系统设计的根本性工程挑战：指标幻觉、峰值并发负载下的API限流、阻碍实时交付的验证延迟，以及损害可信度的主观语言。

质量保障机制作为一个协调的流水线运作。自适应流水线编排将90%的查询路由至单一快速通道，在保持复杂多文档查询完整覆盖的同时，将常见场景的延迟保持在低位。跨账户多模型故障转移通过在多个独立模型账户空间扩展可用配额，显著降低生成停滞的可能性，在不引发用户可见限流的情况下吸收流量激增。实时流式评估在段落生成瞬间即进行验证，而非等待完整响应，将感知评估延迟降低高达86.8%。复合评估框架针对每个段落并行执行多项独立检查，捕捉单一评估者可能遗漏的并发故障。最后，数据准确性验证采用两阶段级联机制，首先通过廉价的精确匹配捕获数值幻觉，仅在必要时才进行昂贵的语义验证，根据测试结果，该方法在平均成本降低54%的情况下实现了约99%的数值准确性。

其结果是一个系统，能够在约13秒后开始流式传输验证过的响应，在为期六个月的部署中，即使在峰值全球负载期间，每项请求均保持可用性，并生成足够准确的输出，可直接用于高管业务审查。对于每天使用NarrateAI的数千位领导者而言，这些技术正是数值错误未在审查中出现、答案在会议期间而非结束后到达、系统在部署窗口期内跨越时区始终保持可用、输出可直接进入业务审查而无需重写的原因。

下一步

要应用这些模式，请首先通过分析查询量分布来判断自适应路由是否能降低您的LLM成本（自适应流水线编排）。如果在高峰期负载时遇到限流限制，跨账户故障转移（跨账户多模型故障转移）可在不更改基础设施的情况下立即带来容量提升。对于已实现LLM输出流式传输的团队，添加生产者-消费者评估（实时流式评估）是提升质量影响最大的改进措施。对于负责任的AI实践，请采用前述控制对的两个部分：对输入查询使用Amazon Bedrock Guardrails防护，对输出响应实施接地检查。仅输入筛选无法过滤幻觉内容，仅输出接地检查会使系统面临提示攻击和超出范围请求的威胁。

这些模式不仅适用于NarrateAI，也适用于其他对准确性和可靠性有严格要求的生产级LLM系统。要开始构建，请查阅以下资源：

• Amazon Bedrock用户指南 — 基础模型（FM）访问和配置
• Amazon Bedrock按AWS区域支持的模型 — 按AWS区域划分的模型可用性
• Amazon Bedrock AgentCore — 代理编排
• Strands Agents SDK — 本实现中使用的公开框架

致谢

我们衷心感谢我们的高管赞助人和导师，正是他们的远见和指导使这项倡议成为可能：AWS洞察部门总监Sujit Narapareddy；产品工程部门总监Aizaz Manzar；数据工程部门负责人Akhand Singh。

我们也要感谢那些技术专长和贡献对产品实现至关重要的团队成员：软件开发经理Aswin Palliyali Venugopalan；高级软件开发工程师Alok Singh；高级软件开发工程师Haymang Ahuja；高级机器学习工程师Jayson Carter；高级技术产品经理Tyler Durand。

作者简介

'"`