InsightFinder’s Miranda Warns Non-Deterministic AI Triggers Production Failures
Ai4
Enterprise AI rollouts fail in production when teams rely on deterministic monitoring tools instead of unified observability that traces real-world model drift and multi-step pipeline errors.
## Background
This talk was published on YouTube by the channel Ai4 on August 29, 2025. It features George Miranda, VP of Marketing at InsightFinder AI, presenting on the operational challenges of moving AI models from pilot to production. The presentation explores key pitfalls in delivering enterprise AI and introduces an approach to intelligent monitoring, evaluation, and governance.
## TL;DR
George Miranda examines why enterprise AI initiatives frequently fail when transitioning from laboratory environments to live production. Drawing parallels to the historical shift from traditional software development to DevOps, he outlines four primary root causes of AI rollbacks: data quality degradation, unreliable model outputs, security and governance risks, and a general lack of operational visibility. Miranda emphasizes that deterministic monitoring tools fall short for non-deterministic AI systems and presents strategies like real-time behavior learning, distributed LLM tracing, evaluation gateways, and integrated cross-stack telemetry to build tight feedback loops and preserve reliability.
## Atmosphere & style
The presentation carries an authoritative, pragmatic, and analytical tone, grounding abstract AI engineering concepts in relatable real-world analogies like the McDonald's drive-through AI failure. Miranda speaks with the pragmatic confidence of an experienced software and observability veteran, weaving personal industry context into a clear, structured narrative. The style is educational yet punchy, transitioning smoothly from humorous cautionary tales to serious technical frameworks for enterprise AI governance.
## Key takeaways
- [00:04](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=4s) Enterprise AI deployments often fail in production because laboratory environments cannot account for unpredictable real-world user interactions and physical edge cases.
- [00:04](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=4s) McDonald's automated drive-through AI order-taker failed and was pulled from production due to background noise, hardware issues, diverse accents, and unexpected user requests.
- [02:54](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=174s) AI and ML engineers are undergoing a DevOps-style shift, being placed on-call to manage complex non-deterministic systems in live production environments.
- [05:50](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=350s) The four main root causes of AI production rollbacks are poor data quality, unreliable/hallucinated outputs, security/governance breaches, and a lack of system visibility.
- [07:45](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=465s) Traditional deterministic monitoring tools fail to detect AI model drift, as models can pass standard operational health checks while silently returning flawed decisions.
- [10:01](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=601s) Bi-weekly sprint reviews and simple user feedback mechanisms are far too slow for catching and correcting LLM output failures in production.
- [10:01](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=601s) Distributed tracing tailored for LLMs is necessary to pinpoint errors across complex, multi-step dependency chains spanning from input pre-processing to final rendering.
- [13:04](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=784s) Production AI governance requires dynamic prompt guardrails, evaluation gateways, and real-time model routing based on safety, performance, latency, and cost.
- [16:22](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=982s) The AI black-box problem is fundamentally a lack of unified visibility and connective tissue between AI components and the underlying tech stack.
- [18:30](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=1110s) Effective AI observability requires integrating telemetry across the entire stack so data science, SRE, and platform teams share a single unified operational context.
## Detailed walkthrough
### [00:04](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=4s) The Real-World Reality Check: McDonald’s AI Order-Taker Debacle
AI applications are everywhere—one quick walk across the expo floor proves it. However, pushing these applications into production often leads to catastrophic failures. Take McDonald's, for example, which famously rolled out an automated AI order-taker at its drive-throughs. They approached the project with immense preparation: partnering strategically with IBM, investing millions of dollars, gathering massive datasets, and leveraging adaptive learning, natural language processing (NLP), tokenization, parsing, and semantic analysis. Built on a scalable IBM Cloud infrastructure with state-of-the-art monitoring, the deployment seemed bulletproof.
Yet, the actual results were hilarious and disastrous. Tik Tok was quickly flooded with viral videos showcasing the system's absurd mistakes—such as adding $250 worth of chicken nuggets to an order or pairing butter and ketchup with ice cream and water. The core issue was not a lack of lab preparation, but the unpredictable nature of the real world. In production, the system was overwhelmed by background noise, faulty microphones, broken speakers, heavy regional accents, complex orders, and customer slang. Users will inevitably interact with AI in ways developers never intended or predicted in a laboratory setting. Ultimately, McDonald's was forced to pull the plug entirely, removing AI order-takers from their drive-throughs.
- **Key Technical Components Used:** IBM strategic partnership, IBM Cloud infrastructure, NLP, adaptive learning, tokenization, semantic analysis, and parsing.
- **Real-World Failures:** Background noise, faulty audio equipment, diverse accents, complex requests, and unexpected customer slang.
- **Viral Outtakes:** AI adding $250 of chicken nuggets or adding butter and ketchup to orders of ice cream and water.
- **Core Lesson:** Without a fast feedback loop to catch and pull production edge cases back into the development cycle, AI initiatives risk total rollbacks.
[02:54](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=174s) From DevOps to AI Engineering: The On-Call Paradigm Shift
George Miranda, co-author of O'Reilly’s *Observability Engineering*, draws a direct parallel between the historical evolution of software engineering and the current state of AI/ML. Miranda spent the first half of his career working on large-scale distributed systems in the video game and finance industries before becoming a consultant during the industry-wide shift to DevOps. During that era, software engineers suddenly found themselves responsible for running applications in production. As systems grew more complex and decomposed into microservices, engineers were put on call and quickly discovered that certain elusive bugs only manifest in live environments where traditional debugging tools fail.
While at Honeycomb—the company that coined the term "observability" for software systems—Miranda witnessed this shift firsthand. Roughly three months after ChatGPT debuted, Honeycomb released a production application built on top of ChatGPT. They were immediately caught off guard by unexpected customer queries and missing edge cases that even Honeycomb’s own observability platform could not surface. Now at InsightFinder AI, Miranda argues that AI and ML engineers are facing the exact same inflection point: as AI moves into production, AI/ML engineers will inevitably be placed on call and must build robust feedback loops to adapt to real-world usage.
- **Speaker Background:** Co-author of O'Reilly's *Observability Engineering*, former engineer in finance and gaming, former Honeycomb team member, now at InsightFinder AI.
- **DevOps Analogy:** Just as distributed microservices forced traditional developers into on-call rotations and modern observability, production LLMs force AI/ML engineers to adopt production response patterns.
- **Honeycomb Case Study:** Released a ChatGPT-powered feature 3 months after ChatGPT's launch; faced unexpected user prompts that standard tooling could not evaluate.
[05:50](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=350s) The 4 Root Causes of AI Production Rollbacks
When AI initiatives fail in production and force a rollback, the root causes almost always fall into one of four primary categories:
1. **Data Quality (The Crumbling Foundation):** When underlying data suffers from drift, corruption, or staleness, the AI system rapidly becomes unreliable.
2. **Unreliable Outputs (AI as a Liability):** Beyond funny LLM hallucinations, problems like algorithmic bias, toxicity, and off-brand responses pose devastating threats to enterprise reputation.
3. **Security and Governance (The Trust Breach):** Risks such as malicious prompt injection or data leakage leave systems exposed and compromise enterprise security.
4. **Lack of Visibility (The Black-Box Problem):** A total absence of operational transparency creates a nightmare scenario in high-stakes customer interactions.
While physical issues like bad drive-through speakers or heavy accents contribute to failure, executive stakeholders point directly to these four categories when canceling projects. Customers do not blame their own accents; they blame the "janky AI system" and the bad answers it generates.
- **Primary Failure Categories:** Data Quality, Unreliable Outputs, Security/Governance, and Lack of Visibility.
- **The "Smoking Gun" Concept:** Physical environment factors cause errors, but the output failures (bias, hallucinations, leaks) are the incriminating evidence executives cite to justify rollbacks.
[07:45](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=465s) Addressing Pitfall 1: Data Quality & Model Drift
Standard observability tools are fundamentally built for deterministic systems—where an HTTP 500 status code cleanly signals a broken component. In contrast, AI and ML models are non-deterministic, where identical inputs do not consistently yield identical outputs. A model can pass every standard health check (latency, throughput, error rates) while silently making systematically flawed or biased decisions. For instance, a fraud detection model might operate with pristine performance metrics while quietly allowing fraudulent transactions to pass through at twice the normal rate for weeks.
Because model drift cannot be fixed with a simple bug patch or server restart, teams need dedicated data and pipeline observability. InsightFinder AI addresses this issue by deploying proprietary, unsupervised behavior-learning algorithms alongside models to detect minute deltas and data anomalies in real time—surfacing issues within seconds or minutes rather than days.
- **Deterministic vs. Non-Deterministic:** Traditional monitoring looks for binary failures (e.g., 500 errors), whereas AI monitoring must detect subtle quality degradation within operating parameters.
- **Fraud Detection Example:** A model can maintain healthy latency and error rates while failing its underlying business function by letting double the fraud slip through.
- **InsightFinder Approach:** Uses unsupervised behavior-learning algorithms to detect data changes and issue real-time anomaly alerts.
- **Stack Assessment Questions:** How fast can you detect data drift? Who gets alerted? Can you catch errors before they impact the end customer?
When LLMs fail in production, simple feedback mechanisms—like collecting thumbs-up/thumbs-down votes once per sprint to update Retrieval-Augmented Generation (RAG) patterns—are far too slow to prevent a brand from becoming a viral social media sensation. Furthermore, when an error rate spikes, pinpointing *where* the failure occurred across the dependency chain is extremely complex. The breakdown could be caused by bad user input, improper prompt pre-processing, an LLM API timeout, token exhaustion, actual model hallucination, or flawed post-processing before rendering the final response to the user.
To trace these multi-step failures, teams must implement distributed tracing tailored for LLM performance. InsightFinder utilizes distributed tracing to analyze every single transaction in real time. This grants complete visibility into inputs, outputs, and intermediate transformation steps with rich operational context, allowing teams to isolate exact failure points in complex dependency chains.
- **RAG & Sprint Review Limits:** Aggregating user feedback on a bi-weekly sprint basis is too slow for production protection.
- **Dependency Chain Failure Points:** Input collection $\rightarrow$ Pre-processing/Prompting $\rightarrow$ LLM Availability/Tokens $\rightarrow$ Output Generation/Hallucination $\rightarrow$ Post-processing/Formatting.
- **Tracing Solution:** Distributed tracing maps the entire path of an LLM request to quickly identify why and where an output failed.
Governance in production AI centers around building dynamic guardrails that filter out undesirable inputs and prevent toxic, biased, or harmful outputs. While developers can and should implement guardrails during initial training and testing, it is impossible to predict every input combination end users will attempt in the wild. When users inevitably circumvent these protections, engineering teams must immediately detect the breach, understand how it occurred, and incorporate that learning back into their prompt guardrails.
To manage this, InsightFinder uses LLM labs and evaluation gateways. These systems allow developers to upload "prompt packs" across multiple models simultaneously to compare real-time performance, expose potential safety or toxicity risks, and dynamically route user traffic. Requests can be routed intelligently based on model availability, output safety, latency, cost, and overall performance. Combining real-time evaluation with production feedback loops allows teams to quickly deploy updated prompts and harden guardrails against newly discovered exploits.
- **Key Risk Factors:** Prompt injection, toxicity, bias, and data leakage.
- **Evaluation Gateways:** Platforms that test prompt packs across various models to measure safety risks and compare real-world output quality.
- **Dynamic Routing Parameters:** Routing LLM requests across different commercial or open-source models based on cost, latency, availability, and safety evaluations.
- **Core Governance Metric:** The speed and tightness of the feedback loop between production discoveries and development prompt updates.
[16:22](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=982s) The Black Box Problem and the Missing Link in AI Observability
Addressing security and governance through guardrails and proper response monitoring goes a long way, but it leads directly into the broader "black box" problem—a major concern across the AI application landscape. While many tools on the expo floor promise to solve this, the issue often isn't purely an unsolvable black box. Rather, it is fundamentally a lack of visibility between what is happening inside the AI components and what is occurring in the rest of the tech stack. This disconnect typically manifests along two vectors: errors cascading through the dependency chain, or a failure in the connective tissue between disparate monitoring tools.
To illustrate this with a concrete example, consider an enterprise self-hosting an open-source model like DeepSeek for compliance, information security, or performance reasons. When undesirable results or performance bottlenecks occur, pinpointing the issue becomes difficult. Did the model fail on its own, or did missing data from upstream pipelines cause the issue? Was data written to a corrupted cache, or was there an underlying infrastructure bottleneck impacting performance? Traditional observability tools like Datadog and Splunk capture infrastructure health, but without integrated visibility, finding the root cause becomes an exercise in cross-team guesswork.
- **Breakdown of Team Silos:** A lack of shared visibility reproduces the historical friction seen between development and operations teams, now re-emerging between data science/ML teams and SRE or platform engineering teams.
- **Cross-Functional Communication:** While teams eventually figure out who to talk to, isolated tools delay incident resolution during critical production failures.
[18:30](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=1110s) Achieving Seamless Visibility and Evaluating Production-Ready Tooling
To overcome these operational silos, organizations need seamless visibility across the entire technology stack so every team uses a unified language to describe incidents. InsightFinder addresses this challenge by combining real-time alerts and causal root cause analysis interfaces with direct telemetry integrations across the existing stack. By operating as a value-add layer over existing infrastructure monitoring tools, all stakeholders—from SREs to ML engineers—gain a single, coherent view of system behavior and failure causes.
When evaluating AI observability tools on the market, several common pitfalls should be avoided. Engineering leaders must look critically at tools that only provide high-level surface metrics indicating *that* a problem is happening without explaining *why*. Similarly, guard against tools that blindly apply traditional infrastructure DevOps tactics directly to AI and ML environments without accounting for their fundamentally different behaviors. Finally, watch out for specialized AI/ML analysis products that operate in complete isolation from the rest of the stack. The ultimate goal is ensuring tools support everyone responsible for reliability in production.
- **Key Evaluation Criteria:** Ask how tools actively assist all production stakeholders in pinpointing exactly "where and why those issues are occurring."
- **InsightFinder Resources:** Attendees interested in discussing specific production use cases and building trustworthy AI were invited to visit booth 216 or stay behind for Q&A.
## Notable quotes
> [00:04](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=4s) The core issue was not a lack of lab preparation, but the unpredictable nature of the real world. — George Miranda
> [00:04](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=4s) Without a fast feedback loop to catch and pull production edge cases back into the development cycle, AI initiatives risk total rollbacks. — George Miranda
> [02:54](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=174s) As systems grew more complex and decomposed into microservices, engineers were put on call and quickly discovered that certain elusive bugs only manifest in live environments where traditional debugging tools fail. — George Miranda
> [02:54](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=174s) As AI moves into production, AI/ML engineers will inevitably be placed on call and must build robust feedback loops to adapt to real-world usage. — George Miranda
> [07:45](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=465s) Standard observability tools are fundamentally built for deterministic systems—where an HTTP 500 status code cleanly signals a broken component. — George Miranda
> [07:45](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=465s) A model can pass every standard health check (latency, throughput, error rates) while silently making systematically flawed or biased decisions. — George Miranda
> [10:01](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=601s) Simple feedback mechanisms—like collecting thumbs-up/thumbs-down votes once per sprint to update Retrieval-Augmented Generation (RAG) patterns—are far too slow to prevent a brand from becoming a viral social media sensation. — George Miranda
> [13:04](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=784s) While developers can and should implement guardrails during initial training and testing, it is impossible to predict every input combination end users will attempt in the wild. — George Miranda
> [16:22](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=982s) The issue often isn't purely an unsolvable black box. Rather, it is fundamentally a lack of visibility between what is happening inside the AI components and what is occurring in the rest of the tech stack. — George Miranda
> [18:30](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=1110s) Engineering leaders must look critically at tools that only provide high-level surface metrics indicating that a problem is happening without explaining why. — George Miranda
## Mentioned
George Miranda, InsightFinder AI, McDonald's, IBM, IBM Cloud, TikTok, Honeycomb, ChatGPT, O'Reilly, Observability Engineering, Datadog, Splunk, DeepSeek
## Video description
George Miranda, VP of Marketing, InsightFinder AI
Abstract
As AI models move from pilot to production environments, ensuring AI model reliability and performance becomes increasingly difficult. Many solutions have evolved into “Composite AI” systems—combining various traditional machine learning (ML) models and large language models (LLMs) both open-source and commercial sources for more robust capabilities. These systems not only involve the models themselves but also rely on complex data pipelines and robust IT infrastructure to remain operational and effective.
Additionally, AI & ML teams are closer than ever to the customer experience. Operating in production brings a new set of challenges and expectations. Many teams are still in development, but those already on the front lines have learned (often, the hard way) that many traditional tools and techniques fall woefully short. In this talk, I will explore the key challenges in delivering reliable and responsible enterprise AI and introduce a new approach to intelligent and efficient monitoring, evaluation, and governance that is designed to meet these challenges in production.
InsightFinder 的 Miranda 警告：非确定性 AI 会引发生产故障
当团队依赖确定性监控工具，而非能够追踪真实环境模型漂移与多步骤流水线错误的统一可观测性时，企业 AI 在生产环境的落地就会遭遇失败。
George Miranda 探讨了企业 AI 项目在从实验室环境转向实际生产环境时为何频频受挫。他将其与传统软件开发向 DevOps 演进的历史相类比，指出了导致 AI 系统回滚的四大根本原因：数据质量退化、模型输出不可靠、安全与治理风险，以及普遍缺乏运维可见性。Miranda 强调，传统的确定性监控工具无法有效应对非确定性 AI 系统，并提出了实时行为学习、分布式 LLM 追踪、评估网关以及跨技术栈集成遥测等应对策略，以建立紧密的反馈闭环并保障系统可靠性。
麦当劳撤下自动 AI 点餐系统印证了实验室测试难以应对真实世界中的背景噪音、口音及硬件异常，若缺乏快速反馈闭环极易引发全面回滚。 (0:04)
随着 AI 应用全面落地，AI/ML 工程师正在经历类似传统 DevOps 的转变，必须承担生产环境 On-call 职责以应对非确定性系统的线上故障。 (2:54)
导致生产环境中 AI 项目被迫下线的四大根本原因在于：数据质量与模型漂移、不可靠的幻觉输出、安全与治理风险，以及系统缺乏整体可观测性。 (5:50)
传统的双周冲刺审查机制无法及时拦截 LLM 线上错误，必须采用专用的分布式追踪技术，精确定位从输入预处理到最终呈现链路中的故障点。 (10:01)
生产级 AI 治理依赖动态提示词护栏与评估网关，能够依据模型可用性、安全性、延迟与成本等多维度指标实现实时的流量动态路由。 (13:04)
Reading summary
George Miranda of InsightFinder AI argues that deploying AI into production exposes non-deterministic vulnerabilities that traditional monitoring cannot resolve, requiring organizations to adopt specialized observability and rapid feedback loops.
Production Realities and the On-Call Shift (0:04)
Controlled laboratory environments fail to anticipate real-world usage patterns, leading to severe operational rollbacks. McDonald’s strategic partnership with IBM deployed an automated drive-through order-taker leveraging NLP, semantic analysis, and IBM Cloud infrastructure. However, real-world variables—such as regional accents, background noise, equipment flaws, and slang—resulted in viral errors, including orders with $250 in chicken nuggets or butter and ketchup added to ice cream, eventually forcing a complete shutdown of the system.
The Four Drivers of Production Failures (2:54)
According to Miranda, the evolution of AI engineering mirrors the DevOps transition, where microservices forced software developers into on-call rotations to debug production-only issues. AI and ML engineers now face a similar paradigm shift where live system edge cases evade standard tooling. Honeycomb, for example, launched a ChatGPT-powered feature three months post-launch and immediately encountered unexpected user prompts their own platform could not capture.
Monitoring Non-Deterministic Data and Output Chains (5:50)
Executive cancellations of AI initiatives generally stem from four root causes: degraded data quality, unreliable outputs like hallucinations and bias, security breaches such as prompt injection, and a total lack of operational visibility. While environmental challenges trigger failures, these four categories serve as the evidence executives cite when discontinuing initiatives. Traditional monitoring flags binary deterministic errors like HTTP 500 codes, but AI systems can pass latency and error-rate checks while silently failing business functions, such as a fraud model letting double the fraudulent transactions slip through.
Tracing Distributed Dependencies and Guarding Systems (7:45)
To identify silent degradation, InsightFinder employs unsupervised behavior-learning algorithms to surface data drift in seconds or minutes. Additionally, bi-weekly sprint reviews of thumbs-up or thumbs-down feedback are inadequate to protect brand reputation from output failures. Pinpointing issues across the dependency chain—from input pre-processing and API timeouts to model hallucinations and post-processing—requires distributed tracing tailored for LLM transactions.
Bridging Cross-Stack Observability Silos (13:04)
Managing security and governance requires continuous real-time guardrails rather than static test-time rules. Miranda notes that platforms using evaluation gateways can run prompt packs across multiple models, balancing dynamic routing against safety, latency, cost, and availability metrics while incorporating production exploits back into prompt defenses.
Unifying AI Context Across Infrastructure (16:22)
The broader "black box" challenge frequently stems from a disconnect between AI components and general IT infrastructure. For enterprises self-hosting open-source models like DeepSeek, identifying whether an issue arises from pipeline data gaps, cache corruption, or infrastructure bottlenecks is challenging using disparate tools like Datadog or Splunk alone. Miranda cautions against monitoring tools that report issues without explaining root causes, apply traditional DevOps metrics blindly to non-deterministic systems, or isolate AI analytics from the wider stack.
Achieving reliable AI deployments requires unified telemetry that bridges the gap between infrastructure SREs and ML teams. Without causal root-cause analysis that spans both data science components and underlying system dependencies, organizations face ongoing friction and slow incident recovery.
## Background
本内容由 Ai4 于 2025 年 8 月 29 日发布在 YouTube 平台上，演者为 InsightFinder AI 的营销副总裁 George Miranda。视频主要探讨随着 AI 模型从试点走向生产环境，面对复杂的复合 AI 系统（Composite AI）、数据管道及 IT 基础设施，企业在保障 AI 可靠性、性能与治理方面所面临的挑战与解决方案。
## TL;DR
演讲者通过麦当劳 AI 语音点餐试点的失败案例，揭示了生产环境与实验室环境之间的巨大鸿沟，并归纳出导致生产环境 AI 项目失败的四大核心诱因：数据质量劣化、输出不可靠、安全与治理缺陷以及缺乏可见性。针对这些挑战，演讲提倡从传统 DevOps 的可观测性理念演进至 AI 专用的全栈可观测性，利用分布式链路追踪、评估网关及无监督行为学习等技术，缩短生产故障的反馈闭环。此外，针对 AI 系统的“黑盒”难题与团队割裂现象，演讲强调建立跨 AI/ML 团队与 SRE/平台团队的统一数据视角，以实现智能监控与根因分析。
## Atmosphere & style
整场演讲风格专业且务实，充满了来自业界一线的洞察力与警示意义。演讲者结合自身在可观测性工程领域的深厚背景，以沉稳冷静且富有条理的语调将技术理论与真实的商业惨痛教训紧密结合。叙述节奏明快，兼具深度与生动性，使听众在感受生产环境不确定性带来的紧迫感之余，又能清晰地领悟到构建可靠 AI 系统的关键突破口。
## Key takeaways
- [00:04](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=4s) 麦当劳与其合作伙伴 IBM 投入数百万美元研发得来速 AI 语音点餐服务，因频繁发生订单严重差错，最终不得不全面撤回该试点项目。
- [00:04](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=4s) 真实生产环境中充斥着严重的背景噪音、损坏的硬件设备、复杂的方言口音和俚语，这与实验室中理想的训练与测试环境存在巨大鸿沟。
- [00:04](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=4s) 缺少从“生产环境到开发环境”的快速反馈回路（Feedback Loop），将直接导致 Enterprise AI 项目从部署走向撤回。
- [02:54](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=174s) AI/ML 工程师正在经历与当年 DevOps 转型相同的过程，需要负责生产环境的 On-call 并应对复杂系统带来的隐蔽故障。
- [05:50](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=350s) 生产环境 AI 项目失败的主要诱因可归结为四类：数据质量劣化、不可靠输出、安全与治理缺陷，以及系统缺乏可见性。
- [07:45](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=465s) AI 属于非确定性系统，传统的确定性监控指标（如 CPU、延迟或 500 报错）无法感知模型漂移和隐蔽偏见等核心故障。
- [10:01](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=601s) 仅靠用户打“赞/踩”这种周期漫长的反馈机制不够及时，需要建立全栈可见性以迅速厘清用户输入、Prompt 拼接、LLM 本身或后处理阶段的故障根因。
- [10:01](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=601s) 利用分布式链路追踪（Distributed Tracing）可以对 LLM 调用的完整依赖链及实时上下文进行捕获与剖析。
- [13:04](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=784s) 应对毒性和偏见输出等治理难题，关键在于缩短从发现安全边界案例（Edge Cases）到更新护栏（Guardrails）与 Prompt 工程的响应周期。
- [16:22](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=982s) AI 系统的“黑盒”痛点很多时候并非源自模型本身不可知，而是缺乏跨连接层（Connective Tissue）与完整依赖链的全局可见性。
- [16:22](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=982s) AI/ML 团队与 SRE/平台团队如果使用割裂的工具链，将导致责任推诿和排错效率低下，必须构建统一的语言与遥测数据视图。
- [18:30](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=1110s) 评估生产级 AI 监控与可观测性工具时，应避开仅提供高层级告警而无法提供根因分析（RCA）及跨堆栈可见性的产品。
## Detailed walkthrough
### [00:04](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=4s) 麦当劳 AI 点餐系统的生产环境滑铁卢
AI 应用如今无处不在，只需去展厅走一圈就能看到各种各样的落地案例。然而，将 AI 部署到真实的生产环境中却充满挑战。以麦当劳在其得来速（Drive-thru）试点的 AI 语音点餐助手为例，虽然他们拥有极高的硬件与资本投入——不仅选择 IBM 作为战略合作伙伴，耗资数百万美元，配备了海量训练数据、自适应学习、NLP 语音识别、分词、语义分析等高级模型，并辅以 IBM Cloud 的弹性算力和顶尖监控，但最终的实际效果却惨不忍睹。
在 Tik Tok 上迅速传播的视频展示了各种让人啼笑皆非的故障：有顾客被误点价值 250 美元的鸡块，还有人的冰淇淋和水里被自动加了黄油与番茄酱。麦当劳之所以陷入这种困境，是因为现实环境远比实验室复杂。真实的生产环境中充斥着各种无法预测的干扰因素，包括严重的背景噪音、损坏的麦克风与扬声器、含糊不清的方言口音、极为复杂的订单组合以及顾客使用的各种俗语俚语。
```
[实验室/开发阶段] [真实生产环境]
+-------------------+ +-------------------+
| 优质训练数据 | | 严重背景噪音/杂音 |
| 理想麦克风/音频 | ==========> | 损坏设备/方言口音 |
| 规范的标准表达 | | 俚语/超复杂订单 |
+-------------------+ +-------------------+
| |
v v
预想：完美运行 现实：订单混乱与回滚
```
顾客在生产环境中对 AI 应用的使用方式往往完全超出预设。由于缺乏能够在生产环境中实时捕捉问题并快速反馈修正的模型迭代机制，麦当劳最终只能被迫全面撤回该系统。这一案例告诫所有 Enterprise AI 团队，必须在上线前将可观测性（Observability）和治理（Governance）实践融入工作流，否则项目极易重蹈覆辙。
- 麦当劳联合 IBM 投入数百万美元研发得来速 AI 语音点餐，最终因故障频发被迫终止试点。
- 生产环境的主要干扰因素：背景噪音、硬件故障（麦克风/扬声器）、复杂口音、俚语及非标准订单。
- 关键经验：缺少“生产环境到开发环境”的快速反馈回路（Feedback Loop），将直接导致 AI 项目从 Rollout（发布）走向 Rollback（回滚）。
### [02:54](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=174s) 从 DevOps 到 AI：可观测性理念的演进
演讲者 George Miranda 介绍了自己的背景。他是 O'Reilly 出版社《Observability Engineering》（可观测性工程）一书的合著者，曾长期在游戏与金融领域担任大规模分布式系统的架构工程师。在软件行业向 DevOps 架构转型的过程中，他作为顾问服务过许多全球顶尖的复杂 IT 基础设施，后来加入提出“系统可观测性”概念的 Honeycomb 公司，目前则在 InsightFinder 工作。
回顾 DevOps 的发展历程，软件工程师逐渐需要直接面向生产环境，负责系统的 On-call 和运维。随着系统日益复杂并演化为分布式微服务，大量隐蔽问题“仅会在生产环境中发生”，传统基于预设日志和固化指标的调试工具随之失效。这迫使团队建立起实时捕捉生产环境微小异常并反馈至研发周期的闭环机制。
```
[传统软件/DevOps 转型期] [当前 AI / ML 工程师面临的现状]
+-----------------------+ +-----------------------+
| 微服务/分布式系统 | | 复合 AI 与 LLM 应用 |
| 生产特有故障 (On-call)| =======> | 非确定性输出/模型漂移 |
| 建立实时反馈与调试闭环| | 亟需专用 AI 可观测性 |
+-----------------------+ +-----------------------+
```
类似的故事也在 AI 领域重演。在 ChatGPT 刚刚问世三个月时，演讲者所在团队便基于 ChatGPT 推出了一款生产级应用，但很快发现团队根本未做好准备——用户的提问方向完全超乎想象。普通的性能监控工具（甚至当时的 Honeycomb）都无法呈现 AI 边缘边界的失效根因。这表明 AI/ML 工程师正在步入当年 DevOps 工程师的后尘，未来也将承担起生产环境的 On-call 职责，必须提早建立适应 AI 特性的可观测性体系。
- George Miranda 曾任职于 Honeycomb，参与合著 O'Reilly 权威著作《Observability Engineering》。
- 软件工程历史规律：系统分布式化导致“仅生产环境可见”的故障，催生了现代可观测性工程。
- 现状与趋势：AI/ML 工程师正在经历相同的角色转变，需要应对非确定性系统带来的上线挑战。
### [05:50](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=350s) 生产环境 AI 失败的四大核心诱因
导致 Enterprise AI 项目在生产环境中被迫回滚的原因，绝大多数可以归结为以下四大类：
1. **数据质量劣化（Data Quality）：** 基础架构的崩塌。包括数据漂移（Data Drift）、数据损坏和数据过期，这会导致 AI 系统快速退化为不可靠的执行者。
2. **不可靠的输出（Unreliable Outputs）：** AI 转化为企业负债。除了常见的大模型幻觉（Hallucination），还包括偏见（Bias）、毒性言论（Toxicity）以及偏离品牌调性的输出，这些都会给企业带来灾难性后果。
3. **安全与治理漏洞（Security & Governance）：** 信任危机的爆发。恶意提示词注入（Prompt Injection）会操控模型，而数据泄露（Data Leakage）则会直接曝光敏感信息。
4. **缺乏可见性（Lack of Visibility）：** 经典的黑盒难题（Black-box Problem）。在 高风险（High-stakes）的客户交互场景中，系统缺乏透明度将成为调试与合规的噩梦。
尽管在麦当劳的案例中，硬件与口音是表面上的诱因，但上述四大要素才是决定 AI 部署生死存亡的“确凿证据”（Smoking Guns）。当业务管理者或高层决定撤回一个 AI 项目时，归根结底是因为 AI 系统输出了错误结果或造成了业务风险。
- AI 项目回滚四大根因：数据质量劣化、不可靠输出、安全与治理缺陷、缺乏系统可见性。
- 风险递增效应：交互场景的风险（High stakes）越高，黑盒问题和不确定性带来的负面影响就越显著。
### [07:45](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=465s) 应对诱因一：数据与管道的可观测性
传统监控手段之所以无法解决 AI/ML 的数据质量问题，是因为传统监控假设系统是确定性的（Deterministic）——例如 HTTP 500 报错必然代表系统某处损坏。然而 AI/ML 属于非确定性系统（Non-deterministic），相同的输入不一定产生相同的输出。一个模型可能在所有传统健康指标（如延迟、吞吐量、错误率）上均表现完美，但实际上已经在输出严重偏颇的结果。
演讲者举例指出，在欺诈检测（Fraud Detection）模型中，即使服务器各项运行指标非常正常，模型也可能在几周时间内以两倍于平常的漏报率放行欺诈交易，而传统监控对此毫无察觉。因此，AI 架构需要针对数据漂移和管道进行实时可观测性分析。
```
传统确定性监控 (Deterministic) AI 非确定性监控 (Non-deterministic)
输入 A ===> 必然输出 B 输入 A ===> 可能输出 B1 / B2 / 异常 C
检查项: 500 错误/CPU/延迟 检查项: 行为漂移/分布偏差/隐蔽偏见
```
在 InsightFinder 的实践中，他们将自主研发的无监督行为学习算法（Unsupervised Behavior Learning）与客户的模型一同部署，能够捕捉微小的数据变化并实时发出异常警报，将感知时间从传统工具的数小时/数天缩短至数分钟甚至数秒内。
- 模型漂移（Model Drift）不是能通过简单 Patch 代码或重启服务器解决的传统 Bug。
- 隐蔽故障示例：欺诈检测模型各项性能指标正常，实际欺诈漏报率却已翻倍。
- 关键评估指标：团队能否在数秒或数分钟内捕获数据漂移，并在影响客户体验前完成预警。
### [10:01](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=601s) 应对诱因二：拆解 LLM 输出的复杂依赖链
针对 LLM 带来的不可靠输出，单靠收集用户的“赞/踩”（Thumbs up/down）并在每个迭代周期（Sprint）评估一次 RAG 模式是远远不够的，这种反馈速度无法阻止企业成为下一个 Tik Tok 负面舆情的主角。
当系统报错率上升或用户给出差评时，问题可能出在整个依赖链的任何环节：
- 是用户的原始输入存在问题（如麦当劳案例中的话筒杂音/口音）？
- 是系统在将输入送入 LLM 前的预处理/提示词拼接出了问题？
- 是 LLM 本身不可用（如 API 报错、Token 超限）？
- 是 LLM 输出了幻觉？
- 还是在将输出呈现给用户前的后处理阶段出现了偏差？
```
[用户输入] ──> [输入预处理/RAG] ──> [LLM 调用] ──> [输出后处理] ──> [呈现给用户]
│ │ │ │ │
(杂音/口音) (Prompt拼接错误) (Token超限/幻觉) (清洗/格式转换) (用户打差评)
```
要准确定位故障根因，必须对依赖链中的每一个环节建立全栈可见性。InsightFinder 通过分布式链路追踪（Distributed Tracing）技术对 LLM 性能进行实时分析。针对发往 LLM 的每一次请求，完整记录输入、中间处理步骤、LLM 响应及上下文数据，从而帮助团队迅速排查依赖链中的故障节点。
- 传统的“ thumbs up / thumbs down ”收集机制反馈周期太长，无法满足生产环境风险控制的要求。
- 故障定位维度：必须能够区分是用户输入异常、Prompt 拼接缺陷、LLM 本身失败（Token/API），还是后处理逻辑错误。
- 解决方案：应用分布式链路追踪技术，实现针对大模型每一次调用的全链路实时上下文捕获。
### [13:04](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=784s) 应对诱因三：安全护栏与治理的闭环迭代
AI 治理（Governance）的核心在于建立安全护栏（Guardrails），控制并过滤可能暴露不当输出的输入内容。虽然模型幻觉常被当作笑料，但偏见（Bias）和毒性内容（Toxicity）却会给企业声誉带来不可逆的打击。
由于团队无法在开发阶段预测用户的所有提问方式，解决这一难题的关键在于**缩短从发现异常到部署修复的响应周期**。InsightFinder 提供了评估网关（Eval Gateways）和 LLM Lab 功能，允许团队将 Prompt 集（Prompt Packs）同时投喂给多个不同模型进行实时性能与安全性对比，直观呈现各模型在偏见、毒性或安全风险上的暴露情况，从而按可用性、响应性能、成本等维度动态路由请求。
```
+---------------------------------+
| Eval Gateway |
| (对比各模型偏见、毒性与安全性) |
+---------------------------------+
│
┌───────────────────────┼───────────────────────┐
▼ ▼ ▼
[模型 A: 高安全/高成本] [模型 B: 低延迟/中风险] [模型 C: 开源/特定任务]
│ │ │
└───────────────────────┼───────────────────────┘
▼
[根据生产反馈快速迭代防护栏]
```
更重要的是，团队需要将生产环境中绕过护栏（Circumvent）的真实边界案例实时提取出来，重新反馈给 Prompt 工程和护栏系统，通过快速迭代来提升模型的安全防御能力。
- 治理重点：建立输入过滤与动态路由机制，防止毒性内容与偏见输出伤害企业品牌。
- 评估网关功能：支持将 Prompt Pack 实时分发至多模型进行对比测试，评估偏见、毒性及成本表现。
- 核心指标：开发与生产环境之间的反馈回路紧密程度，直接决定了团队修正安全漏洞与更新护栏的速度。
<ElicitationsGroup message="想要进一步探索 Enterprise AI 生产环境可观测性？">
<Elicitation label="了解如何为 RAG 系统搭建分布式链路追踪" query="请详细介绍如何为基于 RAG 的大模型应用设计分布式链路追踪（Distributed Tracing）架构及关键监控指标。"/>
<Elicitation label="探讨 LLM 生产环境防护栏（Guardrails）的最佳实践" query="在生产环境中，有哪些主流的 LLM Guardrails 架构和输入输出过滤机制？请提供具体的实现思路。"/>
</ElicitationsGroup>
### [16:22](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=982s) 破解 AI 系统的“黑盒”问题与技术栈断层
在谈到安全与治理之后，演讲者将焦点转向了 AI 应用中的核心痛点——“黑盒”（Black Box）问题。展会上虽然有大量针对黑盒问题的工具，但很多产品往往流于表面，甚至只停留在提供高阶指标的层面。演讲者指出，许多所谓的“黑盒”问题本质上并非模型本身完全不可知，而是缺乏跨系统的全局可见性（Lack of visibility）。在复杂的 Enterprise AI 架构中，问题往往发生在依赖链（Dependency chain）的故障或是不同系统间的连接层（Connective tissue）。
演讲者举例说明：假设企业为了信息安全、治理或性能需求，选择私有化部署（Self-host）像 DeepSeek 这样的开源大模型，一旦系统出现不理想的输出或异常，排查问题将变得非常棘手。原因可能多种多样：是数据管道（Data pipelines）缺失了关键数据？是数据落入了损坏的缓存（Corrupted cache）？还是底层的 IT 基础设施出现了瓶颈？如果 AI/ML 团队与负责基础架构的 SRE/Platform 团队各自使用孤立的监测工具（如 DataDog、Splunk 等），双方就无法实现数据关联与实时协同，重蹈以往开发（Dev）与运维（Ops）割裂的覆辙。
- **黑盒问题的两大核心根源**：依赖链中的故障传递以及系统间缺乏连接管道。
- **跨团队协同壁垒**：数据科学/ML 团队与 SRE/Platform 团队经常使用不同的语言和工具系统，难以快速准确定位瓶颈。
- **InsightFinder 的解决方案**：通过统一步骤的因果分析算法（Causal interfaces）、实时告警与根因分析（Root Cause Analysis），无缝对接现有技术栈并分析 Telemetry 数据，使整个团队使用同一种语言描述和排查事故。
---
### [18:55](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=1135s) 评估生产环境工具链的关注事项与总结
针对如何在市面上选择合适的 AI 可视化与监控工具，演讲者给出了几点非常关键的避坑建议（Watch outs）。选型时不能只看工具是否能发出警报，而要评估它能否跨越整个生产环境、帮助所有相关利益方定位并解决根本原因。生产环境的复杂度与开发测试阶段截然不同，企业必须建立起兼顾模型、数据与基础设施的可靠性治理体系。
演讲者在最后总结道，InsightFinder AI 致力于### AI 系统的黑盒问题与堆栈可见性缺失
解决 AI 应用中的黑盒问题（Blackbox Problem）不能仅靠治理措施，目前许多企业面临的核心痛点其实是“缺乏可见性”（Lack of visibility）。市面上大量的监控工具往往忽略了这一点，或者陷入了只关注局部细节的误区。在复杂的 AI 系统中，导致黑盒现象的“缺失环节”通常发生在两个维度上：一是依赖链（Dependency Chain）中的错误，二是连接各个系统组件的“连接组织”（Connective tissue）。
演讲者举了一个具体的生产环境案例：假设企业选择私有化部署（Self-host）开源模型（如 DeepSeek），其初衷通常是为了保障信息安全、合规性或追求更高性能。然而，一旦系统输出不理想的结果，排查工作将变得极其复杂。究竟是因为数据管道缺失了关键数据，还是数据落入了损坏的缓存中？亦或是底层 IT 基础设施存在性能瓶颈？当 AI/ML 团队与 SRE/平台工程团队分别使用 DataDog、Splunk 等不同工具时，两边缺乏相互看清问题的跨工具可见性。这种部门之间的割裂（Segmentation），恰如当年开发与运维（DevOps）之间的鸿沟，极大地降低了排查生产事故的效率。
- **黑盒问题的两大症结**：依赖链错误（如缺失或损坏的数据）与系统间的连接组织失效。
- **团队割裂隐患**：AI/ML 团队与 SRE/平台工程团队各自为政，缺乏统一的监控视角与协同机制。
- **跨堆栈可见性**：必须打破数据科学团队与运维团队之间的屏障，建立全局可见性。
### [18:30](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=1110s) InsightFinder 解决方案与选型防坑指南
为了解决系统割裂问题，企业需要实现全堆栈的无缝可见性（Seamless visibility），使所有运维和开发团队在描述生产事故时能够使用同一种“语言”。InsightFinder 的解决方案是通过嵌入现有技术堆栈并分析遥测数据（Telemetry），叠加实时警报和根因分析（Root Cause Analysis）算法，为整个团队提供统一的故障归因视角，实现数据协同与价值增值。
在选择生产级 AI 监控与可观测性工具时，演讲者特别指出了三个需要警惕的陷阱（Things to watch out for）：
- **避开仅提供高层级指标（High-level metrics）的系统**：此类工具只能告警“出事了”，却无法解释
## Notable quotes
> [00:04](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=4s) 因为现实环境远比实验室复杂。真实的生产环境中充斥着各种无法预测的干扰因素，包括严重的背景噪音、损坏的麦克风与扬声器、含糊不清的方言口音、极为复杂的订单组合以及顾客使用的各种俗语俚语。 — George Miranda
> [00:04](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=4s) 缺少“生产环境到开发环境”的快速反馈回路（Feedback Loop），将直接导致 AI 项目从 Rollout（发布）走向 Rollback（回滚）。 — George Miranda
> [02:54](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=174s) 随着系统日益复杂并演化为分布式微服务，大量隐蔽问题“仅会在生产环境中发生”，传统基于预设日志和固化指标的调试工具随之失效。 — George Miranda
> [02:54](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=174s) 普通的性能监控工具都无法呈现 AI 边缘边界的失效根因。这表明 AI/ML 工程师正在步入当年 DevOps 工程师的后尘，未来也将承担起生产环境的 On-call 职责。 — George Miranda
> [07:45](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=465s) 传统监控手段之所以无法解决 AI/ML 的数据质量问题，是因为传统监控假设系统是确定性的（Deterministic）——例如 HTTP 500 报错必然代表系统某处损坏。然而 AI/ML 属于非确定性系统（Non-deterministic），相同的输入不一定产生相同的输出。 — George Miranda
> [07:45](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=465s) 一个模型可能在所有传统健康指标（如延迟、吞吐量、错误率）上均表现完美，但实际上已经在输出严重偏颇的结果。 — George Miranda
> [10:01](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=601s) 单靠收集用户的“赞/踩”（Thumbs up/down）并在每个迭代周期（Sprint）评估一次 RAG 模式是远远不够的，这种反馈速度无法阻止企业成为下一个 Tik Tok 负面舆情的主角。 — George Miranda
> [13:04](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=784s) 由于团队无法在开发阶段预测用户的所有提问方式，解决这一难题的关键在于缩短从发现异常到部署修复的响应周期。 — George Miranda
> [16:22](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=982s) 许多所谓的“黑盒”问题本质上并非模型本身完全不可知，而是缺乏跨系统的全局可见性（Lack of visibility）。 — George Miranda
> [16:22](https://www.youtube.com/watch?v=F77MGQ_J6_M&t=982s) 如果 AI/ML 团队与负责基础架构的 SRE/Platform 团队各自使用孤立的监测工具，双方就无法实现数据关联与实时协同，重蹈以往开发（Dev）与运维（Ops）割裂的覆辙。 — George Miranda
## Mentioned
George Miranda, InsightFinder AI, InsightFinder, 麦当劳 (McDonald's), IBM, IBM Cloud, TikTok, O'Reilly, Observability Engineering, Honeycomb, ChatGPT, DeepSeek, DataDog, Splunk
## Video description
George Miranda, VP of Marketing, InsightFinder AI
Abstract
As AI models move from pilot to production environments, ensuring AI model reliability and performance becomes increasingly difficult. Many solutions have evolved into “Composite AI” systems—combining various traditional machine learning (ML) models and large language models (LLMs) both open-source and commercial sources for more robust capabilities. These systems not only involve the models themselves but also rely on complex data pipelines and robust IT infrastructure to remain operational and effective.
Additionally, AI & ML teams are closer than ever to the customer experience. Operating in production brings a new set of challenges and expectations. Many teams are still in development, but those already on the front lines have learned (often, the hard way) that many traditional tools and techniques fall woefully short. In this talk, I will explore the key challenges in delivering reliable and responsible enterprise AI and introduce a new approach to intelligent and efficient monitoring, evaluation, and governance that is designed to meet these challenges in production.
[Source](https://www.youtube.com/watch?v=F77MGQ_J6_M)
Source quotes
[0:04] George Miranda: 因为现实环境远比实验室复杂。真实的生产环境中充斥着各种无法预测的干扰因素，包括严重的背景噪音、损坏的麦克风与扬声器、含糊不清的方言口音、极为复杂的订单组合以及顾客使用的各种俗语俚语。
[0:04] George Miranda: 缺少“生产环境到开发环境”的快速反馈回路（Feedback Loop），将直接导致 AI 项目从 Rollout（发布）走向 Rollback（回滚）。
[2:54] George Miranda: 随着系统日益复杂并演化为分布式微服务，大量隐蔽问题“仅会在生产环境中发生”，传统基于预设日志和固化指标的调试工具随之失效。
[2:54] George Miranda: 普通的性能监控工具都无法呈现 AI 边缘边界的失效根因。这表明 AI/ML 工程师正在步入当年 DevOps 工程师的后尘，未来也将承担起生产环境的 On-call 职责。
[7:45] George Miranda: 传统监控手段之所以无法解决 AI/ML 的数据质量问题，是因为传统监控假设系统是确定性的（Deterministic）——例如 HTTP 500 报错必然代表系统某处损坏。然而 AI/ML 属于非确定性系统（Non-deterministic），相同的输入不一定产生相同的输出。
[7:45] George Miranda: 一个模型可能在所有传统健康指标（如延迟、吞吐量、错误率）上均表现完美，但实际上已经在输出严重偏颇的结果。
[10:01] George Miranda: 单靠收集用户的“赞/踩”（Thumbs up/down）并在每个迭代周期（Sprint）评估一次 RAG 模式是远远不够的，这种反馈速度无法阻止企业成为下一个 Tik Tok 负面舆情的主角。
[13:04] George Miranda: 由于团队无法在开发阶段预测用户的所有提问方式，解决这一难题的关键在于缩短从发现异常到部署修复的响应周期。
[16:22] George Miranda: 许多所谓的“黑盒”问题本质上并非模型本身完全不可知，而是缺乏跨系统的全局可见性（Lack of visibility）。
[16:22] George Miranda: 如果 AI/ML 团队与负责基础架构的 SRE/Platform 团队各自使用孤立的监测工具，双方就无法实现数据关联与实时协同，重蹈以往开发（Dev）与运维（Ops）割裂的覆辙。
Source quotes
[0:04] George Miranda: The core issue was not a lack of lab preparation, but the unpredictable nature of the real world.
[0:04] George Miranda: Without a fast feedback loop to catch and pull production edge cases back into the development cycle, AI initiatives risk total rollbacks.
[2:54] George Miranda: As systems grew more complex and decomposed into microservices, engineers were put on call and quickly discovered that certain elusive bugs only manifest in live environments where traditional debugging tools fail.
[2:54] George Miranda: As AI moves into production, AI/ML engineers will inevitably be placed on call and must build robust feedback loops to adapt to real-world usage.
[7:45] George Miranda: Standard observability tools are fundamentally built for deterministic systems—where an HTTP 500 status code cleanly signals a broken component.
[7:45] George Miranda: A model can pass every standard health check (latency, throughput, error rates) while silently making systematically flawed or biased decisions.
[10:01] George Miranda: Simple feedback mechanisms—like collecting thumbs-up/thumbs-down votes once per sprint to update Retrieval-Augmented Generation (RAG) patterns—are far too slow to prevent a brand from becoming a viral social media sensation.
[13:04] George Miranda: While developers can and should implement guardrails during initial training and testing, it is impossible to predict every input combination end users will attempt in the wild.
[16:22] George Miranda: The issue often isn't purely an unsolvable black box. Rather, it is fundamentally a lack of visibility between what is happening inside the AI components and what is occurring in the rest of the tech stack.
[18:30] George Miranda: Engineering leaders must look critically at tools that only provide high-level surface metrics indicating that a problem is happening without explaining why.
Original transcript
[0:04] So AI apps are everywhere. If you want
[0:06] to know what I'm talking about, just go
[0:08] into that expo floor, right? And you'll
[0:09] see them all over the place. So consider
[0:12] McDonald's, right? McDonald's put an AI
[0:15] order taker into their drive-throughs.
[0:17] Anybody ever experienced one of these in
[0:19] the wild? No. If you haven't, yeah, a
[0:21] couple folks. If you haven't, look them
[0:23] up on Tik Tok. There are tons of videos
[0:25] about this. I will spoil it for you. The
[0:28] roll out was bad.
[0:30] But why? How did they prepare? They had
[0:33] a really solid approach. They used IBM
[0:35] as a strategic partner. Uh they had a
[0:38] huge investment of capital and
[0:40] resources. Spent millions, had tons of
[0:43] training data, had adaptive learning,
[0:45] NLP to decipher human voices,
[0:48] tokenization, parsing, semantic
[0:50] analysis, highly highly developed
[0:52] models. performance was backed by
[0:55] scalable uh infrastructure in IBM cloud
[0:58] state-of-the-art monitoring.
[1:00] What were the results?
[1:02] It was stuff like this, right? Who
[1:04] doesn't need $250 worth of chicken
[1:06] nuggets, right? Who doesn't need butter
[1:09] and ketchup to go with their ice cream
[1:10] and water? It went hilariously bad.
[1:14] Check out the videos on Tik Tok. You
[1:15] will thank me later. But what happened,
[1:18] right? They prepared really well. Why
[1:20] did it go so wrong? In short, the real
[1:23] world. When they rolled out, there was
[1:25] tons of background noise, right? Faulty
[1:27] speakers, faulty microphones, hard to
[1:30] understand accents, complex orders,
[1:33] customers using slang.
[1:35] Customers will use your AI apps in
[1:38] production in ways that you never
[1:40] intended and in ways that you can never
[1:42] fully predict in a lab.
[1:45] So, McDonald's wasn't ready for that,
[1:47] right? They rolled out an AI app to
[1:49] customers believing that they had
[1:50] prepared for everything.
[1:53] But in production, you never know how
[1:56] users are going to behave and what they
[1:58] are going to ask your systems to do. So
[2:01] McDonald's pulled the plug. You will not
[2:03] find AI order takers in their
[2:05] drive-throughs anywhere. Why? Because in
[2:08] production, what you need is you need to
[2:10] build a feedback loop so that you can
[2:13] proactively catch those issues, see that
[2:16] they are happening in production and
[2:17] work to pull them into your development
[2:19] cycle and roll out fixes really quickly
[2:21] to iterate and make your models more
[2:23] reliable.
[2:25] If you do not have a good way to catch
[2:27] those issues and fix them before they
[2:30] impact customers, your AI initiatives
[2:32] are likely to follow a similar path,
[2:35] right? You need to be ready for
[2:37] production because it is a whole
[2:39] different world out there, right? Which
[2:40] means integrating observability and
[2:43] governance practices into your workflows
[2:45] now before you get to production because
[2:48] that's the difference between a
[2:49] successful AI roll out and a roll back.
[2:54] Uh so hi, I'm George uh co-author of the
[2:57] O'Reilly book observability engineering.
[2:59] Uh I'm relatively new to the AI space.
[3:02] Uh but I made a career by working as an
[3:05] engineer on large-scale distributed
[3:07] systems mostly in the video game and
[3:08] finance industries.
[3:11] Uh during the shift to DevOps uh I
[3:13] became a consultant and in the second
[3:15] half of my career I've worked with some
[3:16] of the largest most complex
[3:18] infrastructures on earth.
[3:20] This book was primarily written for
[3:22] software engineers who were newer to
[3:26] being this close to customers. Right? If
[3:27] you rewind the clock a little to uh the
[3:30] shift to DevOps, right? We became so
[3:32] digitally connected that most software
[3:35] engineers suddenly found themselves
[3:36] responsible for supporting apps in
[3:39] production, right? Which meant they were
[3:42] on call. They had to troubleshoot
[3:44] elusive issues that only happened in
[3:46] production. And as their systems became
[3:49] more complex, as they became
[3:50] distributed, as they decomposed into
[3:52] microservices, they discovered that
[3:55] there were issues that only happened in
[3:56] production. And for those issues,
[3:59] traditional tooling no longer worked,
[4:01] right? Traditional debugging methods
[4:03] were no longer sufficient.
[4:05] And they needed to build a feedback loop
[4:07] to find those tiny one-off errors in
[4:10] production, pull it back into the
[4:12] development cycle, and iterate on their
[4:13] apps quickly, right? And through that
[4:15] feedback loop, that's how I found
[4:17] Honeycomb. Honeycomb is the uh company
[4:18] that coined the term observability for
[4:21] software systems. And it was during my
[4:23] time at Honeycomb that I collaborated
[4:24] with my co-authors. We wrote this book
[4:27] and it's also there that I witnessed
[4:29] this phenomenon firsthand. So at
[4:31] Honeycomb uh about 3 months after chat
[4:34] GPT first debuted, we decided to release
[4:37] an application built on top of chat GPT
[4:39] to production and we were not ready. Uh
[4:44] customers asked all sorts of questions
[4:45] that we never anticipated that we did
[4:48] not think would be things that were on
[4:50] top of our customers minds. And what we
[4:52] discovered is that we needed ways to
[4:54] observe what was happening in production
[4:56] and find those edge cases that we didn't
[4:59] know about. Uh find edge cases that our
[5:02] normal tooling couldn't show, even
[5:03] Honeycomb couldn't show us and use that
[5:06] feedback to improve the resiliency of
[5:08] our AI systems. And so a lot of the
[5:10] lessons that I'm going to be talking
[5:11] about today, we learned the hard way. Uh
[5:14] I'm no longer at Honeycomb. I'm now at a
[5:16] company called Insightfinder. Uh and I
[5:18] was drawn to both Insightfinder and the
[5:20] AI space. uh because I believe this is
[5:22] the new frontier. Uh many of the same
[5:25] shifts that we saw in DevOps I think are
[5:27] coming for AI and ML engineers. So if
[5:30] you are an AI or ML engineer in this
[5:32] room uh you will also be on call if you
[5:35] are not already. Uh and uh if you know I
[5:39] mean look at what's happening to
[5:40] McDonald's, right? Like we need that
[5:42] sort of response pattern. So I think now
[5:44] is the time to start getting ahead of
[5:46] these issues because they're coming for
[5:47] us all in this room sooner or later.
[5:50] So today I'm going to talk about the
[5:51] common pitfalls and for running AI in
[5:54] production and give you concrete ways to
[5:56] assess if your tool stack is ready uh
[5:59] for production. So four main reasons
[6:01] that AI rollbacks happen. They almost
[6:04] always fall into one of these
[6:05] categories. So number one, data quality.
[6:08] This is a foundation that crumbles,
[6:09] right? So when data quality
[6:11] deteriorates, right? If you have drift,
[6:13] corruption, staleness, AI systems very
[6:15] quickly become unreliable actors.
[6:19] uh two reliable uh unreliable outputs,
[6:21] right? Your AI becomes a liability. And
[6:24] so LLM hallucinations make for all the
[6:26] funny Tik Tok videos, but bias,
[6:28] toxicity, off-brand responses can all be
[6:30] equally devastating.
[6:33] Three, security and governance, right?
[6:34] This is the trust breach. So malicious
[6:36] prompt injection can manipulate models.
[6:39] Data leakage can expose sensitive
[6:40] information. This is basically the
[6:42] scenario in which you unwittingly leave
[6:44] yourself exposed.
[6:46] And then four, the lack of visibility.
[6:48] Right? This is the blackbox problem. So
[6:50] a lack of transparency becomes a
[6:52] nightmare in high stakes customer
[6:54] interactions. And the higher the stakes,
[6:56] the more acutely you will feel this
[6:58] pain. But that's it, right? It's these
[7:01] four. It is almost always one of these
[7:03] four. And so I know what some of you
[7:05] might be thinking. Like in that
[7:06] McDonald's example, didn't you say it
[7:08] was bad microphones and accents and
[7:10] complex orders? And yes, those are
[7:13] contributing factors. But everything
[7:14] that's up on the screen, these are the
[7:17] incontrovertible, incriminating bits of
[7:19] evidence, right? They're the smoking
[7:20] guns. So, uh, you know, obviously there
[7:23] are a lot of other factors that go in
[7:24] like why was that gun there? How'd it
[7:26] get fired in the first place? But these
[7:28] are the things that your customers will
[7:29] point to, right? It's not their accents
[7:31] and orders that it's a problem, right?
[7:33] It's your janky AI system and the answer
[7:35] that it gave me. And this is what your
[7:37] stakeholders, the executives in your
[7:38] company will point to in terms of
[7:40] rolling back AI initiatives. So let's
[7:42] talk about how to mitigate these.
[7:45] All right. So number one, data quality.
[7:46] Uh this is why you need observability in
[7:49] your data and your pipelines. So
[7:51] standard observability solutions do not
[7:53] work for AI and ML models. So model
[7:55] drift is not a bug that you can patch,
[7:58] right? Or a server that you can restart.
[8:00] Traditional monitoring, right, assumes
[8:02] that you have deterministic systems. A
[8:04] 500 error always means that something is
[8:07] broken. Whereas with AI and ML, uh,
[8:11] predictable binary behavior swaps out
[8:13] for nuanced operations and
[8:15] non-deterministic systems, right? The
[8:16] same inputs do not always equal the same
[8:18] outputs, which means that a model can
[8:21] appear functional and normal, right? And
[8:23] everything is operational working within
[8:26] the expected ranges, but at the same
[8:28] time, it could be making systematically
[8:30] biased decisions that are not reflected
[8:33] in the standard performance metrics.
[8:35] Right? So like for example, let's say
[8:36] you're running a a fraud detection model
[8:39] and that model is passing all of its
[8:41] health checks, right? Uh latency,
[8:43] throughput, error rates, they all look
[8:45] good, must be working, right? But at the
[8:47] same time, that model could be letting
[8:50] fraudulent transactions slip through at
[8:51] twice the normal rate, right? And that
[8:53] could be the situation for weeks because
[8:55] it is invisible to traditional
[8:57] monitoring metrics. And so you need to
[9:00] be able to detect that kind of drift in
[9:02] real time to get ahead of unexpected
[9:04] changes that could have devastating
[9:05] consequences.
[9:07] Uh as a concrete example at
[9:09] Insightfinder, part of the way that we
[9:11] do this is um we use proprietary
[9:13] unsupervised behavior learning
[9:14] algorithms. We deploy them alongside
[9:16] your models so that we can spot small
[9:18] deltas in uh uh in data changes, right?
[9:22] Alert you to anomalies, let you know
[9:24] that they're happening. And further, we
[9:26] spot those in real time, right? We don't
[9:28] spot those in hours or days, right? It's
[9:31] there within minutes or seconds. So, uh
[9:34] the questions that you need to ask,
[9:37] right, for your stack is can you detect
[9:40] that sort of drift? Right? If so, how
[9:42] fast? Is that fast enough? Right? Who's
[9:46] getting alerted? How do they know what
[9:47] to do? Can you catch issues before they
[9:50] steamroll customer experience? Right?
[9:52] So, this is observability for your data
[9:54] and your pipelines. This is how you stop
[9:56] that crumbling foundation problem. This
[9:58] one pretty straightforward, right? Let's
[10:00] talk about others that are a little more
[10:01] complex. So two unreliable outputs,
[10:04] right? So I'm going to pick on LLMs. I
[10:06] was mostly talking about ML models in
[10:07] the last one, but this is the McDonald's
[10:09] story more or less, right? Worked fine
[10:11] in development, nightmare in production.
[10:14] So why was it a disaster in production?
[10:18] Right? Where did the failures occur? You
[10:20] have to know where if you're going to
[10:21] explain why. So first of all right the
[10:24] question is can you even detect that
[10:26] there is an issue in real time that your
[10:28] customers are experiencing right or how
[10:30] do you know that there are issues today
[10:32] are you just aggregating like a thumbs
[10:34] up and a thumbs down response and then
[10:36] evaluating those once a sprint to inform
[10:38] your rag patterns like that is that is
[10:41] an approach but is that fast enough
[10:43] right is that fast enough to detect an
[10:46] error before you become the next viral
[10:47] Tik Tok sensation
[10:50] so uh it's not all it's also just not
[10:52] enough to detect that there's an error,
[10:54] right? Let's say for example that uh
[10:58] your error rates like the error rate
[11:00] metric shot up. Great. You know that
[11:01] there's a problem. Where is there a
[11:04] problem? Did the LLM fail? Right? Was it
[11:06] inputs from the user? Right? Maybe in
[11:08] the McDonald's example, right? It was a
[11:10] bad speaker or accents, right? Or maybe
[11:12] that was fine. Okay. Is it in how you
[11:14] took those inputs and massaged them
[11:16] before you gave it to the LLM? Was it
[11:18] the LLM itself that failed? If it did
[11:21] fail, why was the LLM not available? Did
[11:24] you have an API error? Did you run out
[11:25] of tokens? Right? If it was the LLM
[11:28] itself, was it the output that was a
[11:30] problem? Right? If that like was it a
[11:32] hallucination? If that was fine, was it
[11:34] how you massaged those outputs before
[11:36] you gave them to the user? Or what if
[11:38] all of that was valid and the user just
[11:40] didn't like it so they gave you a thumbs
[11:42] down? Right? There are so many places in
[11:45] the dependency chain where that possibly
[11:47] could have gone wrong. Right? you need
[11:49] visibility into every single part of
[11:51] that to determine where or even why it
[11:54] happened.
[11:55] So as a concrete example right at
[11:57] Insightfinder we use distributed tracing
[11:59] to uh do real-time analysis of LLM
[12:02] performance right so that every single
[12:03] transaction that is being issued to your
[12:05] LLM you can see that entire dependency
[12:08] chain of the inputs the outputs all the
[12:10] intermediary steps right with rich
[12:12] context so that uh you know you can
[12:14] understand what is happening when it
[12:16] goes wrong in any given time but right
[12:19] more than one way to do this questions
[12:21] that you need to be asking in this
[12:23] scenario are how do you detect LLM
[12:26] issues, right? Are you detecting them
[12:28] fast enough to respond before customer
[12:31] damage actually occurs? Can you see the
[12:34] inputs? Can you see the processing
[12:35] steps? Can you see the outputs and any
[12:37] of the intermediary steps that go
[12:39] between input and thing that the user
[12:42] wanted?
[12:44] How quickly can you determine where an
[12:47] issue occurred or even why if something
[12:49] goes wrong with your LLM? Right?
[12:51] Observability can give you deep deep
[12:53] levels of context like that and those
[12:55] are the kinds of things that you need uh
[12:57] in order to debug those dependency
[12:59] chains. That's how you stop your AI from
[13:02] becoming a liability.
[13:04] Number three, security and governance.
[13:07] Now, this is a really really big topic
[13:08] and there are entire classes of tools
[13:11] that are built to solve this large and
[13:13] complex problem. Um but as AI and ML
[13:15] developers, uh there are some basic
[13:17] frontline defenses that we can add. And
[13:20] so data security is a massive topic. I'm
[13:21] just going to go ahead and pick on
[13:22] governance for this talk. And so
[13:24] governance is all about building guard
[13:26] rails and ensuring safety.
[13:29] So in other words, like you need to know
[13:31] what your users can possibly do, right?
[13:34] In other words, how do you limit or
[13:35] prevent undesirable actions from
[13:38] appearing in your results? We've already
[13:40] talked about detecting drift and
[13:42] controlling outputs. How do you control
[13:44] inputs? Right? Can you filter for inputs
[13:48] that are likely to expose undesirable
[13:50] outputs? If you do, congratulations, you
[13:53] have good guardrails. If you have
[13:55] guardrails, the questions are to ask
[13:57] are, you know, when users circumvent
[14:00] those guardrails for any reason. One,
[14:02] can you see that they were circumvented?
[14:03] Two, do you know why? And three, how can
[14:06] you incorporate that learning back into
[14:08] those guardrails to mitigate it in the
[14:10] future?
[14:12] So again, right, hallucinations make for
[14:14] all the funny videos, but bias is real,
[14:16] right? Toxicity is real. Both of them
[14:18] can have devastating consequences to
[14:21] your company uh and and its reputation.
[14:24] Uh so if you can't fix those before
[14:26] they're widespread, that's how you end
[14:28] up rolling back AI initiatives.
[14:31] Some ways potentially address that.
[14:34] Right. At uh Insightfinder uh we realize
[14:37] that you cannot possibly predict what
[14:39] users are going to ask your
[14:40] applications. Right? You you can and you
[14:43] should prepare for that in development.
[14:45] Um but even when you do, there's no way
[14:47] that you can possibly make a perfect
[14:50] model to address every circumstance.
[14:52] However, you can shorten the time
[14:55] between when you realize the
[14:56] unpredictable is happening and when you
[14:58] deploy a fix for it. So at
[15:00] Insightfinder, we do this a number of
[15:01] different ways, right? We have LLM labs,
[15:03] eval gateways that essentially let you
[15:06] do things like upload prompt packs to
[15:09] different models and compare performance
[15:11] real time to show you if your results
[15:14] are exposing bias or toxicity or present
[15:16] safety risks, right? You can see which
[15:19] models are prone to those and decide how
[15:21] to route your requests accordingly,
[15:23] right? And you can route them based on
[15:25] things like availability or uh
[15:28] performance of those results, cost, etc.
[15:31] Um, and you cannot predict everything
[15:32] that your users will do, but you can see
[15:35] where those gaps are, identify where
[15:37] they're likely to occur, right? Route
[15:40] those controls in ways that, you know,
[15:41] you can predictably uh uh be sure are
[15:44] going to uh perform in certain ways and
[15:48] uh and then use that in combination with
[15:50] what's happening in production to
[15:52] iterate those prompts, make them safer,
[15:54] and and introduce better guard rails.
[15:58] So, questions you should be asking,
[15:59] right? How do you know what's happening
[16:00] in production? How do you feed that back
[16:03] to your models in your prompts? How do
[16:05] you route LLM requests to different
[16:07] models based on some of those
[16:09] performance factors? In other words, how
[16:11] tight is the feedback loop that you have
[16:13] between development and production? Or
[16:16] in other words, how quickly can you
[16:18] move, right? That's essentially what
[16:19] we're talking about. So, you need
[16:21] observability in your prompts and
[16:22] responses to ensure proper governance.
[16:25] uh that's not how you solve the security
[16:26] and governance problem entirely but it
[16:28] it goes a pretty long way
[16:31] and then lastly four uh the blackbox
[16:34] problem. So this is a huge concern in AI
[16:37] applications, right? You will find a
[16:38] number of tools for this on the expo
[16:40] floor. But oftentimes what gets me about
[16:43] this is that the blackbox problem
[16:45] sometimes manifests in ways that isn't
[16:47] really entirely a black box, right? A
[16:49] lot of times it's that first part of the
[16:50] the statement there. It's about lack of
[16:52] visibility. And so I see a lot of
[16:54] products on the market today miss this
[16:57] or even worse just focus on this part
[16:59] which I think in some ways is worse. But
[17:01] there's a missing link between what is
[17:04] happening in your AI world and the rest
[17:06] of the stack. And that usually happens
[17:09] along two vectors. One, it's errors in
[17:11] the dependency chain, right? Which we
[17:12] touched on earlier. Um or two, it's
[17:14] connective tissue. So let let me put
[17:16] this into concrete terms, right? Um this
[17:19] is where other observability tools like
[17:22] uh like data dog, Splunk, etc. jump in,
[17:24] right? Let's say that uh you decide to
[17:28] self-host a model like deepseek for
[17:30] example right plenty of reasons to do
[17:32] that information security governance um
[17:34] performance etc. If something goes
[17:37] wrong, where did it go wrong? Right? Did
[17:39] you get undesirable results because data
[17:42] was missing from your pipelines? Right?
[17:44] Did that data land in corrupted cache
[17:46] somewhere? Was there actually an
[17:48] infrastructure problem that might
[17:49] explain the bottleneck that you're
[17:51] seeing?
[17:53] What you need here is visibility between
[17:55] tools, right? Does the AI or ML team
[17:57] that is investigating that LLM issue
[17:59] have visibility into the tools that
[18:01] would show that infrastructure
[18:03] bottleneck or vice versa, right? Does
[18:06] your S sur or platform team have access
[18:08] to systems that would show uh where the
[18:11] model issues are occurring, right? And
[18:12] be able to correlate those two. I mean,
[18:14] would those two teams know to speak to
[18:16] each other? I mean, sure, eventually,
[18:17] right, they would figure it out, but
[18:19] we've seen this type of segmentation
[18:20] before, right, between development and
[18:23] operations. And I kind of feel like
[18:24] we're going the same places with data
[18:26] science and ML teams versus S sur and
[18:28] platform.
[18:30] And so you need seamless visibility in
[18:33] your stack. You need to have your entire
[18:35] team using the same language to describe
[18:37] incidents that are happening. So at
[18:39] Insightfinder, we do that with uh the
[18:42] same algorithms and causal interfaces
[18:43] that we've talked about before, right?
[18:45] Real-time alerts, root cause analysis,
[18:47] but we also do that by plugging into the
[18:49] rest of your stack and analyzing your
[18:51] telemetry. So it's a value add on top.
[18:53] and everybody is seeing the same things.
[18:55] So, here are the things to watch out
[18:57] for, right, when you go down tooling in
[18:59] this route. One, uh beware of systems
[19:01] that only give you highlevel metrics,
[19:03] right? That tell you that maybe there's
[19:05] a problem happening, but not why. Uh
[19:08] watch out for tools that uh focus on
[19:11] infrastructure and DevOps tactics and
[19:13] then just try to apply those same
[19:14] methodologies to the AI and ML world,
[19:16] right? Fundamentally different models
[19:18] and vice versa. AI and ML analysis tools
[19:21] that operate in isolation from the rest
[19:23] of the stack. So essentially what you're
[19:25] doing is you're asking how your tools
[19:28] help not just you, right, but everybody
[19:31] that is responsible for ensuring
[19:32] reliability in production, right? How do
[19:34] they help you know where and why those
[19:36] issues are occurring?
[19:38] And so that's it, right? These are some
[19:41] of the most important questions to ask
[19:43] to examine if your tool chain is
[19:45] production ready. and you need to be
[19:47] production ready because it is a whole
[19:49] different world out there. And so again,
[19:52] it's just one way to do some of these
[19:54] things, but you need to be doing these
[19:56] things. So that's what we're building at
[19:57] Insightfinder. That's what we're p
[19:59] passionate about helping you do. We are
[20:01] passionate about building trustworthy AI
[20:03] and helping you overcome some of these
[20:05] challenges in production. Couple of
[20:07] resources. If you want to find out more,
[20:09] come see us at booth 216. Would love to
[20:11] talk to you about your use cases. But I
[20:13] think that's all I have time for. I'll
[20:14] hang out just in case there are
[20:16] questions, but would love to see you
[20:17] there. Thank you for your time.
