Machine Learning

149 posts

meta2 min readCurated summary

Modernizing the Facebook Groups Search to Unlock the Power of Community Knowledge

Facebook has re-architected Groups Search to make community knowledge easier to discover, understand, and validate. Its new hybrid retrieval system combines keyword matching with semantic search, while automated model-based evaluation measures relevance at scale. The result is improved search engagement and relevance without increasing error rates. ## Friction in Community Search - **Discovery:** Traditional lexical search depends on exact words, so a query for “small individual cakes with frosting” might miss posts discussing “cupcakes.” Semantic matching helps connect different phrasing with the same intent. - **Consumption:** Users often must read dozens of comments to identify consensus or useful advice, creating an “effort tax.” - **Validation:** Relevant expertise is frequently scattered across group discussions, making it difficult to evaluate purchases or decisions using community knowledge. ## Hybrid Retrieval Architecture - Queries are tokenized, normalized, and rewritten before retrieval. - The **lexical path**, powered by Facebook’s Unicorn inverted index, retrieves exact or closely matching terms and preserves precision for proper nouns and quotations. - In parallel, the **semantic path** uses a 12-layer, 200-million-parameter Search Semantic Retriever to encode queries into dense vectors. - Approximate nearest-neighbor search over a Faiss index retrieves conceptually similar posts, even when they use different words. ## Multi-Task Ranking - Results from lexical and semantic retrieval are merged for ranking. - The ranking model combines traditional signals such as TF-IDF and BM25 with semantic cosine-similarity scores. - A multi-task, multi-label model jointly optimizes for clicks, shares, and comments. - This approach balances theoretical relevance with the likelihood of meaningful community engagement. ## Automated Relevance Evaluation - Semantic similarity scores can be difficult to interpret, so evaluation was integrated into build verification testing. - Llama 3 with multimodal capabilities acts as an automated judge of search results. - Evaluation recognizes nuanced outcomes, including “somewhat relevant” results that share a broader domain or theme. - This enables scalable measurement of conceptual matching and result diversity without relying entirely on human labeling. ## Results and Future Work - The hybrid system outperformed the keyword-only baseline in offline quality and search-engagement metrics. - Facebook reports improved relevance without higher error rates. - Future plans include using LLMs directly during ranking and dynamically adapting retrieval parameters to query complexity. The approach demonstrates that combining lexical precision with neural semantic understanding can make community search more effective. Further LLM integration may help the system interpret post content and tailor retrieval more intelligently.

Read original(opens in new tab)
gitlab3 min readCurated summary

GitLab + Amazon: Platform orchestration on a trusted AI foundation

GitLab Duo Agent Platform and Amazon Bedrock combine GitLab’s software-lifecycle orchestration with AWS’s governed foundation-model infrastructure. Duo coordinates agents across planning, development, security, pipelines, and remediation, while Bedrock provides secure inference within AWS boundaries. The pairing aims to reduce shadow AI, fragmented tooling, unclear data flows, and unplanned cloud spending. ## The Enterprise AI Governance Problem - Teams often adopt unapproved AI tools, creating unknown prompt and code-data paths. - AI tooling and model choices become fragmented across developers and departments. - Security teams may lack control over logs, data residency, and access policies. - Existing AWS and Amazon Bedrock investments can be underused when teams rely on external point solutions. - The proposed division of responsibility is: - GitLab Duo Agent Platform: workflow and agent orchestration. - Amazon Bedrock: approved models and inference. - The organization: IAM, VPC, regional, security, and policy controls. ## GitLab Duo Agent Platform as the Control Plane - Duo provides specialized agents and flows that operate asynchronously across the software lifecycle. - Agents use shared GitLab context, including: - Issues - Merge requests - Pipelines - Security findings - It extends beyond a single conversational assistant by coordinating multiple agents across continuous workflows. - Potential tasks include planning, code development, merge-pipeline work, security scanning, and vulnerability remediation. ## Amazon Bedrock as the AI Foundation - Bedrock is a managed, serverless foundation-model layer operating within AWS. - Customer inputs and outputs are encrypted, not shared with model providers, and not used to train base models. - It supports compliance requirements including GDPR, HIPAA, and FedRAMP High. - Organizations can use native Bedrock models or import fine-tuned models through Custom Model Import. - Bedrock Guardrails can provide content filtering, hallucination detection, and sensitive-data protection. ## Deployment Options The core Duo capabilities remain consistent, but control and infrastructure ownership vary across three patterns: - **Self-hosted models with Amazon Bedrock** - Intended for GitLab Self-Managed deployments. - Uses a self-hosted AI Gateway. - Keeps inference traffic, prompts, logs, and lifecycle data within the organization’s AWS environment. - **GitLab-operated Bedrock models with GitLab-owned keys** - Intended for GitLab Self-Managed deployments. - Uses GitLab’s hosted AI Gateway. - GitLab operates the model layer while the deployment remains self-managed. - **GitLab.com with GitLab-operated Bedrock models** - Uses GitLab’s hosted AI Gateway and GitLab-owned keys. - Suits organizations that prefer the SaaS GitLab experience while using Bedrock-backed models. ## Practical Enterprise Uses - Platform teams can standardize models for code suggestions, security analysis, and pipeline remediation. - Centralized guardrails and logging reduce independent, unmanaged AI adoption. - Security agents can propose and validate fixes directly within GitLab. - Routing AI workloads through Bedrock helps organizations align usage with existing AWS agreements and spending commitments. The recommended approach is to treat GitLab Duo Agent Platform as the orchestration layer and Amazon Bedrock as the governed inference foundation, selecting the deployment model that matches the organization’s compliance, hosting, and control requirements.

Read original(opens in new tab)
gitlab3 min readCurated summary

Prepare your pipeline for AI-discovered zero-days

AI is accelerating both vulnerability discovery and insecure code production, shrinking the time defenders have to respond from months to hours. The post argues that security teams cannot remain the final defense layer; security controls, automated triage, and remediation must operate directly within development pipelines. AI-generated fixes can help close the gap, but they must follow the same policies, approvals, testing, and audit requirements as human-authored code. ## The Remediation Backlog Is Already Too Large - Most exploited vulnerabilities are already known and have patches available, but organizations cannot remediate them quickly enough. - Sixty percent of breaches in the 2025 Verizon DBIR involved known vulnerabilities. - Developers spend roughly 11 hours per month fixing vulnerabilities after release. - The median time to close half of internet-facing vulnerabilities is 361 days, while exploitation can begin within hours. - AI-assisted development is increasing the volume of insecure code: - Fortune 50 repositories reportedly gained more than 10,000 security findings per month by mid-2025. - AI coding tools may introduce outdated patterns, hallucinated packages, insecure examples, and excessive dependencies. - Security AI should therefore operate within existing development policies and audit trails rather than as a disconnected tool. ## Security Enforcement Must Move Into the Pipeline - Every change should pass security controls at the merge request, which becomes the central enforcement point. - Policies should be defined once and applied consistently across teams and projects. - Exceptions should be explicitly approved and logged. - IDE checks can catch straightforward problems—such as hardcoded secrets, vulnerable imports, and deprecated APIs—before code reaches review. - This allows human reviewers to focus on complex issues such as reachability, exploitability, and architectural risk. ## Automated Triage and Governed Remediation - AI should reduce the volume of findings developers must investigate by assessing: - False positives - Reachability - Exploitability - Severity - AI-generated fixes should not bypass normal governance. - Remediation proposals should be submitted as merge requests, with: - Required scans - Policy enforcement - Human approvals - Confidence scores - Complete audit records - Human and AI-authored changes should follow the same review and compliance process. ## Example: Responding to an Emerging Vulnerability - A proof-of-concept exploit may appear before a CVE, NVD entry, or scanner signature exists. - A security agent can inspect dependency graphs across projects, identify affected versions and call paths, and rank production exposure. - Teams can then launch a coordinated remediation campaign: - Upgrade dependencies where patches exist. - Apply targeted code changes where they do not. - Block merge requests that retain the vulnerable dependency. - Require security approval for fixes. - Pipeline tests can reject faulty AI-generated patches, allowing the agent to revise them before developers approve the corrected version. - Automatically collected scan results, policies, approvals, and merge timestamps provide audit evidence without manual reconstruction. ## Strengthen the Pipeline Before Attackers Catch Up - Organizations should verify that security scans run on every merge request, not only in selected projects. - Pipelines should detect compromised or vulnerable dependencies before build time. - Critical findings should move quickly from detection to the responsible developer without unnecessary tool boundaries. - The central recommendation is to make pipeline enforcement, AI-assisted triage, and governed remediation standard parts of the software supply chain before comparable offensive AI capabilities become widely available.

Read original(opens in new tab)
gitlab3 min readCurated summary

GitHub Copilot's policy for AI training: A governance wake-up call

GitHub’s April 2026 policy change will make Copilot Free, Pro, and Pro+ interaction data—including code, prompts, outputs, and context—available for AI training by default unless users opt out. The change highlights governance risks for regulated organizations, especially when protections vary by subscription tier or can be altered through policy updates. The post presents GitLab’s no-training commitment, contractual safeguards, and transparency documentation as a stronger model for enterprise AI governance. ## What the GitHub Policy Change Means - Beginning April 24, 2026, GitHub may use Copilot Free, Pro, and Pro+ data for model training by default. - Covered data includes: - User inputs and outputs - Code snippets - Associated context - Interaction data - Users must actively opt out. - Copilot Business and Enterprise customers remain exempt under existing contracts. - Data may also be shared with GitHub affiliates, including Microsoft, for AI development. - Organizations must review license tiers, settings, contracts, and internal AI governance controls. ## Why This Matters in Regulated Industries - Source code can expose: - Proprietary business logic - Internal system architecture - Sensitive data flows - Financial algorithms and risk models - Financial institutions may face intellectual-property and model-risk concerns involving trading strategies, underwriting rules, fraud detection, and credit models. - Frameworks such as Federal Reserve SR 11-7 and DORA require documented oversight of third-party technology and material changes in vendor practices. - Public-sector environments governed by NIST 800-53 and FISMA may require sensitive code to remain within controlled boundaries. - Healthcare organizations must consider HIPAA obligations when development tools interact with clinical or patient-adjacent systems. - Default opt-in training, individual opt-out requirements, and tier-dependent protections create compliance risks. ## Requirements for Enterprise AI Vendors - **Contractual certainty:** Vendors should clearly and unconditionally define how customer data is handled. - **Auditability:** Organizations need documentation about models, training data, subprocessors, retention, and compliance status. - **Independence from vendor incentives:** Customer code should not become training data for systems that may benefit competitors. - **Operational flexibility:** Regulated customers may require self-hosting, controlled processing boundaries, or clear procedures for vendor changes. ## GitLab’s AI Governance Position - GitLab states that it does not train AI models on customer code at any pricing tier. - Its AI vendors are contractually prohibited from using GitLab customer inputs or outputs for their own purposes. - The GitLab AI Transparency Center documents: - Models powering its features - Data handling practices - Subprocessors - Retention periods - Feature compliance status - GitLab emphasizes cloud and model neutrality, supports self-hosted deployments, and addresses vendor changes through its AI Continuity Plan. - The post argues that these policies reduce vendor-concentration, compliance, and intellectual-property risks. ## Closing the Governance Gap Organizations should ask every AI vendor: - Is customer data used for model training? - Who are the model subprocessors? - What happens if data practices change? - Can AI processing remain inside the organization’s infrastructure? - What indemnification applies to AI-generated output? The post’s recommendation is to favor vendors that provide durable, contractual, and auditable answers rather than relying on defaults, temporary opt-outs, or policies that can change with short notice.

Read original(opens in new tab)
gitlab2 min readCurated summary

CI Expert and Data Analyst AI agents target development gaps

GitLab 18.11 introduces two Duo Agent Platform agents aimed at development gaps left by faster AI-generated coding. CI Expert Agent helps teams create working pipelines, while Data Analyst Agent answers software delivery questions using GitLab data. Both benefit from being embedded in GitLab, where they can use current repository, pipeline, issue, and merge request context. ## CI Expert Agent: Faster Pipeline Setup - Now available in beta. - Inspects a repository to identify its language, framework, and testing setup. - Generates runnable build and test configurations without requiring developers to write YAML manually. - Explains each pipeline step in plain language through Agentic Chat. - Uses native GitLab CI semantics. - Addresses the common problem of delaying CI because `.gitlab-ci.yml` is difficult to create or validate. - Helps reduce regressions, oversized changes, and dependence on undocumented team knowledge. - Available on GitLab.com, Self-Managed, and Dedicated across Free, Premium, and Ultimate editions with Duo Agent Platform enabled. ## Data Analyst Agent: Natural-Language SDLC Queries - Generally available in GitLab 18.11. - Lets users ask questions about development performance in plain language and receive visualizations in Agentic Chat. - Covers merge requests, issues, projects, pipelines, and jobs. - Supports questions about: - MR cycle time and review bottlenecks - Project throughput and contribution patterns - Flaky tests and pipeline performance - Runner utilization and deployment frequency - Cross-portfolio lead times and project health - Eliminates the need to learn GitLab Query Language, request custom dashboards, or rely on separate analytics tools. - Generated GLQL queries can be copied into GitLab Flavored Markdown. - Exporting results to work items and dashboards is planned. - Available across GitLab.com, Self-Managed, and Dedicated Free, Premium, and Ultimate editions with Duo Agent Platform enabled. ## The Advantage of Platform-Native Context - Both agents operate within GitLab and can access existing code, pipelines, issues, and merge requests. - Their recommendations and answers are based on current operational data rather than generic examples or disconnected tools. - The agents are designed to support the full lifecycle: understanding code, configuring CI, shipping changes, and evaluating delivery performance. Together, these agents make GitLab Duo more useful beyond code generation. Teams should consider trying CI Expert Agent for faster initial pipeline setup and Data Analyst Agent for immediate, self-service insight into delivery performance.

Read original(opens in new tab)
gitlab2 min readCurated summary

Automate remediation with ready-to-merge AI code fixes

GitLab 18.11 makes Agentic SAST Vulnerability Resolution generally available, using AI to analyze vulnerabilities, generate code fixes, test them, and open ready-to-merge merge requests. The release aims to reduce developer context switching and AppSec triage while addressing vulnerabilities before production. It also adds faster scanning, risk-based prioritization, and stronger security governance. ## Automated Remediation in the Developer Workflow - Confirmed SAST true positives automatically enter GitLab Duo Agent Platform’s remediation flow. - The agent: - Analyzes the vulnerability in context. - Generates a root-cause fix. - Validates the change with automated tests. - Developers receive a ready-to-merge MR with a confidence score. - Incremental scanning for Advanced SAST provides results before a complete scan finishes. - The approach addresses the growing remediation burden as AI-generated code increases vulnerability volume. ## Prioritizing Vulnerabilities by Business Risk - Vulnerability scoring now uses CVSS 4.0 for more detailed exploitability assessment. - Policy-based severity overrides can use: - CVE information. - CWE classifications. - File paths and directories. - Approval policies can block or warn on merges based on: - Known Exploited Vulnerabilities (KEV). - EPSS score thresholds. - The Top CWEs dashboard chart helps teams identify recurring vulnerability classes and address systemic causes. ## Security Controls and Scanner Coverage - The new Security Manager role gives security teams permissions to: - Enforce scanners. - Configure security policies. - Manage triage and remediation. - Maintain compliance frameworks and audit streams. - The role excludes code modification and deployment permissions, keeping access appropriately scoped. - SAST configuration profiles allow teams to define scanning centrally and apply it across group projects without maintaining project-level YAML or relying on developers for configuration. GitLab 18.11 combines agentic remediation, faster and more risk-aware scanning, and centralized governance. Organizations seeking to reduce vulnerability backlogs can use these capabilities to automate routine fixes while preserving developer oversight through merge requests and confidence scores.

Read original(opens in new tab)
gitlab2 min readCurated summary

Claude Opus 4.7 is now available in GitLab Duo Agent Platform

GitLab Duo Agent Platform now supports Anthropic’s Claude Opus 4.7 across Agentic Chat and agent-powered software delivery workflows. The model is designed to improve long-running, multistep tasks through stronger reasoning, instruction following, and self-verification. GitLab says this should make agents more reliable across development, security, CI/CD, and deployment. ## Improved Reasoning and Instruction Following - Internal evaluations reportedly show Opus 4.7 outperforming Sonnet 4.6 and Opus 4.6. - It handles complex, conditional instructions more precisely. - Agents can complete multistep tasks with fewer errors and more predictable, auditable results. - Self-verification helps agents check generated code and tests before presenting them. ## Support Across the Software Lifecycle - **Development:** Faster code generation and test creation with less developer back-and-forth. - **Security:** More reliable vulnerability remediation through complete, correctly scoped sequences. - **CI/CD:** Better continuity when investigating pipeline failures, analyzing logs, and proposing fixes. - **Cross-stage workflows:** The model supports coordination across planning, coding, security, and deployment. ## Availability and Pricing - Claude Opus 4.7 is available now through model selection in GitLab Duo Agent Platform. - Model credit consumption details are provided in GitLab’s documentation. - New users can start a free trial. - GitLab Premium and Ultimate subscribers can enable Duo Agent Platform and use included GitLab Credits. Teams using GitLab’s agent workflows can adopt Opus 4.7 to improve reliability on complex, multi-tool tasks spanning the full software delivery lifecycle.

Read original(opens in new tab)
gitlab3 min readCurated summary

GitLab 18.11: Budget guardrails for GitLab Credits

GitLab 18.11 introduces spending controls for GitLab Credits used by the Duo Agent Platform. Organizations can set subscription-wide monthly caps, limit individual users, and monitor enforcement, making AI costs more predictable as adoption grows. The goal is to combine usage-based pricing with the budget certainty traditionally associated with seat-based licensing. ## Subscription-Level Spending Caps - Billing account managers can set a hard monthly ceiling in the Customers Portal. - When usage reaches the cap, Duo Agent Platform access pauses for all users until the next billing period. - Managers can raise or disable the cap mid-month to restore access. - Caps reset monthly and remain in effect until changed. - Because usage data is synchronized periodically, limited usage may occur after the cap is technically reached. ## Per-User Credit Limits - A flat per-user limit can be applied uniformly through the GitLab GraphQL API. - Custom overrides allow organizations to give higher allocations to selected users, such as staff engineers. - Limits apply to a user’s total consumption across all credit sources. - Reaching an individual limit pauses only that user’s Duo Agent Platform usage; their GitLab access remains intact. - Other users continue working until they reach their own limits or the subscription cap. ## Visibility and Notifications - Billing account managers receive email notifications when the subscription cap is reached. - Group owners on GitLab.com and instance administrators on Self-Managed installations can see users blocked by per-user caps. - Administrators can restore access by changing limits through the GraphQL API. - Per-user usage data supports monitoring, chargeback, and future budget planning. ## Benefits for Scaling AI Adoption - Hard caps make AI spending easier to forecast, approve, and include in quarterly budgets. - Per-user limits help distribute credits fairly across teams and cost centers. - Organizations can expand from small pilots to hundreds or thousands of developers without risking uncontrolled invoices. - Usage data helps platform teams understand consumption patterns and adjust allocations. ## Usage-Based Pricing with Guardrails GitLab contrasts its approach with seat-based AI tools, where organizations pay a fixed amount per user regardless of usage. GitLab Credits instead charge based on actual consumption while adding enforced spending limits, combining flexibility with predictable budgeting. ## Example Deployments - A 200-person engineering organization can set a subscription cap matching its approved monthly budget. - If usage approaches the limit, finance or billing managers can either increase the cap or wait for the next period. - A 2,000-person enterprise can apply standard limits to most developers while allocating higher caps to engineers handling complex work. ## Availability and Setup - The controls are available for GitLab.com and Self-Managed customers running GitLab 18.11. - Subscription-level caps are configured by billing account managers in the Customers Portal. - Flat and custom per-user caps are configured through the GitLab GraphQL API by namespace owners or instance administrators. Organizations adopting GitLab Duo Agent Platform should establish a subscription cap, define fair per-user allocations, and monitor usage regularly. These controls provide a safer foundation for expanding AI usage without sacrificing financial oversight.

Read original(opens in new tab)
meta2 min readCurated summary

Trust But Canary: Configuration Safety at Scale

As AI accelerates software development, stronger safeguards are needed to prevent faster mistakes from becoming larger incidents. Meta’s Configurations team uses canarying, progressive rollouts, health checks, and monitoring to detect regressions early. Data and AI also help reduce alert noise and speed up identifying the changes responsible for failures. ## Safe Configuration Rollouts - Meta deploys configuration changes gradually rather than releasing them everywhere at once. - Canarying exposes changes to a small subset of systems or users first. - Progressive rollouts expand the deployment only when monitoring indicates that the change is healthy. - These practices limit the impact of faulty configurations and provide opportunities to stop or reverse a rollout. ## Monitoring and Health Checks - Automated health checks and operational signals help identify regressions soon after deployment. - Monitoring provides evidence for deciding whether a rollout should continue, pause, or be rolled back. - Early detection is especially important at Meta’s scale, where a small configuration error can affect many systems. ## Learning from Incidents - Incident reviews focus on improving tools, processes, and safeguards rather than assigning blame to individuals. - The goal is to make future failures less likely and reduce their potential impact. - These reviews turn operational problems into improvements across the configuration management system. ## AI-Assisted Operations - Data-driven techniques reduce alert noise so engineers can focus on meaningful signals. - AI and machine learning help speed up bisection, narrowing down which change introduced a problem. - Faster diagnosis can shorten recovery times and make progressive deployment practices more effective. The episode recommends combining gradual releases, strong observability, blameless incident reviews, and AI-assisted analysis to keep increasingly rapid development safe at scale.

Read original(opens in new tab)
gitlab2 min readCurated summary

GitLab Duo CLI: Agentic AI now in the terminal

GitLab Duo CLI brings GitLab’s agentic AI capabilities into the terminal, extending AI assistance beyond interactive coding in an IDE. Its public beta supports both human-guided sessions and unattended automation across the software development lifecycle, including coding, CI/CD, testing, and troubleshooting. GitLab emphasizes security through approvals, prompt-injection detection, auditing, and configurable permissions. ## Terminal-Based Agentic Development - The CLI is designed for work outside the IDE and GitLab UI. - Terminals are well suited to: - Automation and scripting - Piping and chaining commands - Portable workflows - Reproducible debugging - IDEs remain better for interactive, context-rich development, while Duo CLI targets automation and machine-driven workflows. ## Installation - Users with GitLab’s `glab` CLI can start Duo CLI with: ```bash glab duo cli ``` - GitLab Duo CLI can also be installed as a standalone tool. ## Capabilities and Operating Modes - Duo CLI can build, modify, refactor, and modernize code. - It can access agents and flows defined in GitLab Duo Agent Platform. - Potential uses include: - Creating and optimizing CI/CD configurations - Running multi-step development tasks - Debugging failed pipelines - Integrating AI into unattended workflows ### Interactive Mode - Provides editor-independent terminal chat. - Keeps a human in the loop by requiring approval before actions. - Supports codebase exploration, code creation, error fixing, and pipeline troubleshooting. ### Headless Mode - Runs without user interaction. - Designed for CI/CD runners, scripts, and automated workflows. - Enables agents to operate in environments where no developer is present. ## Security and Governance - Interactive actions require human approval by default. - Prompt-injection detection is built into the Duo Agent Platform. - Composite identity controls agent access and makes AI-driven actions auditable. - Instruction files such as `chat-rules.md`, `AGENTS.md`, and `SKILL.md` define permitted tasks, resources, context, and actions. - These controls apply least-privilege principles to AI agents. ## Availability - Duo CLI is available through a free trial of GitLab Duo Agent Platform. - Free-tier GitLab users can sign up for the platform. - GitLab Premium and Ultimate subscribers can enable Duo Agent Platform and use included GitLab Credits. GitLab Duo CLI is best suited to teams that want AI assistance across the full development lifecycle rather than only inside an editor. Its combination of interactive approvals, headless execution, and platform-level security makes it useful for both developer support and automated DevSecOps workflows.

Read original(opens in new tab)
meta3 min readCurated summary

KernelEvolve: How Meta’s Ranking Engineer Agent Optimizes AI Infrastructure

KernelEvolve is Meta’s agentic system for automating the creation and optimization of low-level AI kernels across diverse hardware. It treats kernel tuning as a search problem rather than one-shot code generation, evaluating hundreds of alternatives with profiling and diagnostics. The system reduces optimization work from weeks to hours and has delivered over 60% higher inference throughput for an Ads model on NVIDIA GPUs and over 25% higher training throughput on Meta’s MTIA chips. ## Kernel Optimization at Meta - AI models rely on optimized kernels that translate high-level operations into hardware-specific instructions. - Meta runs models across NVIDIA GPUs, AMD GPUs, custom MTIA accelerators, and CPUs. - Production workloads require many custom operators beyond standard GEMMs and convolutions available in vendor libraries. - Kernels must be developed and tuned for each combination of: - Hardware type and generation - Model architecture - Operator type ## The Challenge of Hardware Heterogeneity - NVIDIA, AMD, MTIA, and CPU platforms differ in: - Memory architectures and hierarchies - Instruction sets - Execution models - Supported numeric data types - A kernel optimized for one platform may perform poorly or fail on another. - Hardware generations also require new optimization strategies. Meta’s MTIA roadmap includes four generations, from MTIA 300 through MTIA 500, in two years. - Manual tuning by kernel specialists cannot keep pace with these changes. ## Increasing Model and Operator Complexity - Meta’s recommendation systems have evolved from embedding-based models to sequence models with attention, GEM, and LLM-scale models such as Meta Adaptive Ranking Model. - Each new model generation introduces operators that earlier systems did not require. - Multiple model families may be involved in a single ads-serving request. - As model architectures and operator inventories grow, the number of kernel configurations expands rapidly into the thousands. ## How KernelEvolve Works - KernelEvolve generates candidate implementations in languages and DSLs including: - Triton, Cute DSL, and FlyDSL - CUDA, HIP, and MTIA C++ - A dedicated job harness compiles, runs, profiles, and evaluates each candidate. - Performance results, correctness checks, and diagnostic information are fed back to the LLM. - The system continuously searches through hundreds of alternatives instead of stopping at the first plausible implementation. - Its automated workflow includes profiling, optimization, testing, and cross-hardware debugging. ## Results and Broader Impact - KernelEvolve improved Andromeda Ads inference throughput by more than 60% on NVIDIA GPUs. - It improved training throughput for an ads model by more than 25% on Meta’s MTIA silicon. - The system operates across both public and proprietary hardware. - In production, it optimizes code supporting trillions of daily inference requests. - By automating kernel development, Meta can enable new hardware and adapt to changing model architectures with substantially less engineering effort. KernelEvolve turns kernel development from a manual, expert-driven bottleneck into a continuous automated process. Its search-based approach is particularly valuable as Meta’s hardware portfolio and model architectures continue to diversify.

Read original(opens in new tab)
line3 min readCurated summary

Applying Spark on Kubernetes to process large-scale advertising data for LINE services

LINE Ads processes tens of billions of advertising events daily and nearly one hundred billion internal data records. As growing numbers of features increased computational demands, its Spark-on-YARN environment suffered from resource contention, inefficient scaling, and Hadoop dependencies. The team migrated to Spark on Kubernetes to achieve infrastructure independence, containerized execution, flexible scaling, and easier operational automation. ## Large-Scale LINE Ads Data Pipelines - The data pipeline supports: - Real-time advertising-event processing - Abuse and validity checks - Machine-learning systems and model training - Analytics and system integration - Advertiser reporting - The platform must handle hundreds of billions of events per day and hundreds of thousands per second. - It must provide low latency, elastic capacity, minimal service impact during failures, and rapid recovery. - The most heavily used table grew to approximately 2.91 times its December 2022 size by December 2025 as more features were added. ## Limitations of Spark on YARN - Hadoop’s storage and compute resources were colocated, causing Spark workloads to compete with HDFS and other Hadoop components. - Scaling compute required adding Hadoop nodes, even when additional storage was unnecessary, increasing cost and wasting capacity. - JVM and Spark versions were difficult to manage independently, limiting access to newer Spark features. - Applications became tightly coupled to the Hadoop infrastructure. ## How Spark on Kubernetes Works - Kubernetes replaces YARN as the cluster manager. - Spark drivers and executors run as separate Kubernetes pods. - In cluster mode: - `spark-submit` requests a driver pod. - Kubernetes schedules the driver on an appropriate node. - The driver creates a `SparkContext`, builds the DAG, and requests executors. - Executors run as independent pods with individually allocated CPU and memory. - The driver divides the DAG into stages and distributes tasks to executors. - Shuffle data is normally tied to executor-pod lifecycles unless an external shuffle service is configured. ## Advantages over YARN - **Containerized execution:** Docker images package application dependencies, improving reproducibility and CI/CD integration. - **Infrastructure independence:** Spark can use HDFS, S3, GCS, or other storage systems without requiring a Hadoop cluster. - **Simpler autoscaling:** Kubernetes can scale pods and integrate with cloud VM autoscalers. - **Unified platform:** Spark, Airflow, machine-learning workloads, and API servers can share a Kubernetes cluster. - **Governance and isolation:** Namespaces, `ResourceQuota`, and RBAC provide flexible team-level controls. - **Operational automation:** Helm, ArgoCD, GitOps, and rolling updates enable more automated application management. ## LINE Ads’ Kubernetes-Based System The platform is organized into four layers: - **Deployment layer** - GitHub Actions runs CI workflows based on repository events. - ArgoCD monitors desired and deployed states and supports easier rollback and synchronization. - **Compute layer** - Kubeflow’s Spark Operator deploys applications through the `SparkApplication` Kubernetes custom resource. - Apache YuniKorn schedules batch jobs and supports resource coordination and gang scheduling. - LogSender forwards pod logs to OpenSearch. - ClusterMonitoring sends Prometheus metrics to the company’s monitoring system. - **Storage layer** - Kafka provides high-throughput, low-latency storage for real-time advertising actions. - Hadoop remains available for large-scale, long-term analysis. - **Monitoring layer** - Kubernetes workers and Spark applications are monitored through exposed Prometheus metrics and centralized logging. The migration to Spark on Kubernetes is recommended for organizations whose Spark workloads are outgrowing tightly coupled Hadoop environments. It separates compute from storage, improves deployment flexibility, and allows data applications to be managed as cloud-native workloads.

Read original(opens in new tab)
google3 min readCurated summary

Building better AI benchmarks: How many raters are enough?

Human disagreement makes AI benchmarks difficult to reproduce, yet evaluations often use only one to five raters per item and reduce their responses to a majority vote. The study introduces an `(N, K)` framework—balancing the number of items (`N`) against raters per item (`K`)—to determine how annotation budgets should be allocated. It concludes that the best balance depends on the evaluation goal: broad sampling for majority accuracy, but deeper rating for capturing nuanced human opinions. ## The Breadth-versus-Depth Trade-off - The “forest” strategy rates many items with few raters per item. - The “tree” strategy rates fewer items with many raters per item. - Historically, AI benchmarks have favored the forest approach, typically using one to five raters per example. - This approach can miss both the overall distribution of opinions and meaningful disagreement among raters. ## Simulating Annotation Budgets - The researchers built a simulator using real-world subjective datasets, including toxicity, hate speech, safety, offensiveness, and job-related tweet classification. - They varied: - **Scale (`N`)**: 100 to 50,000 total items. - **Crowd (`K`)**: 1 to 500 raters per item. - Thousands of configurations were tested for statistical reliability, including whether model comparisons reached significance at `p < 0.05`. - The simulator also examined messy conditions such as highly imbalanced categories and tasks with multiple labels. - The simulator has been released as open source. ## Why Three to Five Raters Are Often Insufficient - Low-rater evaluations may fail to represent natural human disagreement. - They provide too little depth to reveal nuanced opinions and too little breadth to establish a reliable overall picture. - In many settings, more than 10 raters per item are needed to produce results that reflect the variation in human judgments. - More ratings per item can make model comparisons more statistically reliable. ## The Evaluation Metric Determines the Optimal Strategy - **Majority-vote accuracy** - If the goal is to determine whether a model agrees with the majority of people, rating more items is generally more effective. - This favors the forest strategy. - **Opinion range and nuance** - If the evaluation must distinguish between responses such as “yes,” “maybe,” and “no,” more raters per item are essential. - This favors the tree strategy because only repeated ratings reveal the full distribution of human opinions. - There is no universally optimal number of items or raters; the correct allocation depends on what the benchmark is intended to measure. ## Reproducibility Without Unlimited Budgets - An appropriately chosen item-to-rater ratio can produce highly reproducible results with roughly 1,000 total annotations in some settings. - Spending more money does not guarantee reliability if the budget is distributed poorly. - The study’s framework is intended to help benchmark designers choose the allocation that best fits their metric and data characteristics. ## Moving Beyond a Single Ground Truth - Many AI evaluations assume that every example has one objectively correct label. - This assumption becomes increasingly problematic for subjective tasks involving toxicity, harmful intent, ethics, safety, or social interaction. - Preserving disagreement instead of collapsing it into a plurality label can make benchmarks more representative of real human judgment. - The authors argue that understanding disagreement is as important as measuring consensus. Benchmark designers should first decide whether they need majority accuracy or a detailed picture of human opinion, then allocate ratings accordingly. In subjective evaluations, using substantially more than five raters per item may be necessary for reliable and reproducible conclusions.

Read original(opens in new tab)
line4 min readCurated summary

Image Content Moderation in Large-Scale Service Environments (feat. Multimodal LLM)

Image content moderation has evolved from simple rule-based filtering into an AI-powered decision system capable of handling visual context, text, and policy complexity. At large platforms, the challenge is not only accuracy but also latency, cost, scalability, and adaptability to changing policies. LY Corporation addresses these demands through optimized traditional ML models, a hybrid ML–multimodal LLM pipeline, and modular decision-making that combines OCR, visual analysis, and contextual reasoning. ## The Evolution of Content Moderation - Early systems relied on keyword matching, rule-based filters, and predefined patterns. - Machine learning enabled broader pattern recognition and detection of modified or less explicit violations. - Modern systems combine: - Deep learning for text and image classification - Multimodal models for joint image–text understanding - LLMs for context-sensitive judgments - Separate prediction and policy layers for operational flexibility - Despite these advances, image moderation remains difficult because images lack explicit structure and their meaning often depends on context. ## Why Image Moderation Is Difficult - **Visual complexity:** Backgrounds, objects, people, colors, and composition interact in ways that simple object detection cannot fully interpret. - **Context dependency:** Symbols, gestures, and imagery may have different meanings across cultures; embedded text can also determine whether an image is harmful. - **Evasion and variation:** Memes, composites, partially obscured images, and AI-generated edits continually challenge existing detectors. - **Scale requirements:** Platforms may receive millions or tens of millions of images daily, requiring high accuracy alongside low latency, reliability, and cost efficiency. ## LY Corporation’s Moderation API - LY Corporation operates a monitoring platform designed to process large-scale traffic and enforce diverse content policies. - Its image moderation API detects: - Adult content - Violent or graphic scenes - Offensive or disturbing imagery - Identity documents containing personal information - Social media screenshots and other policy-sensitive images - The system is designed to apply service-specific policies consistently while maintaining high throughput. ## Improving Accuracy, Speed, and Cost ### Traditional ML Model Optimization - A PyTorch-based image classification model was selected with latency, cost, and throughput in mind. - The model was converted to ONNX and optimized with FP16 precision. - ONNX Runtime improved execution efficiency, while FP16 reduced memory usage and inference time. - These changes increased throughput by up to **4.3 times**. ### Hybrid ML and Multimodal LLM Architecture - The traditional classifier acts as a fast first-stage filter. - Clear cases are resolved immediately by the image model. - Ambiguous cases are sent to a multimodal LLM for deeper analysis. - More than 90% of production data could be classified by the traditional model alone. - Since multimodal LLM throughput was over 100 times lower than that of the traditional model, routing every image to the LLM would have significantly increased GPU usage and cost. - The hybrid approach preserves high-quality reasoning where necessary while avoiding unnecessary LLM calls. ### vLLM-Based LLM Optimization The team optimized multimodal LLM serving with vLLM, using characteristics such as repeated prompts, predictable token lengths, and prefill-heavy workloads. - **`enable_prefix_caching`:** Reuses KV-cache blocks for repeated system prompts and templates, reducing prefill computation. - **`max_model_len`:** Limits the maximum input-plus-output length to avoid excessive KV-cache allocation. - **`max_num_seqs`:** Controls concurrent requests, balancing throughput against per-request latency and resource contention. - **`max_num_batched_tokens`:** Sets the token budget per scheduling step; larger values can improve throughput for prefill-heavy workloads. - Regularly updating vLLM is recommended because new releases add improvements such as asynchronous scheduling, CUDA graph support, and broader quantization options. ## Moving Beyond Single-Model Policy Prediction - Earlier end-to-end vision models directly predicted final policy categories from images. - This worked for visually obvious violations, such as detecting smoking, but struggled with complex behaviors such as tobacco sales. - Sales-related judgments may require combining: - Product presence - Prices - Sales language - Contact information - Encouragement to purchase - Directly learning every combination of national regulations, service policies, and exceptions created overly complex output classes. - It also made the model harder to extend and maintain, while limiting the use of text embedded in images. ## Hybrid Decision-Making with OCR and Multimodal Reasoning - The redesigned system separates visual and textual information rather than forcing one model to learn every policy combination. - OCR extracts text from images when relevant. - Extracted text helps identify policy-violating behavior or intent. - Visual signals and textual evidence are then combined with a multimodal LLM. - This allows the system to reason about context and intent beyond simple object detection, while making policy logic more modular and adaptable. The practical recommendation is to avoid routing all traffic through expensive general-purpose models. Use fast specialized models for clear cases, reserve multimodal LLMs for ambiguity, optimize serving according to workload characteristics, and separate content understanding from policy decisions so the system can evolve as requirements change.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Cloudflare Client-Side Security: smarter detection, now open to everyone

Cloudflare is making its Client-Side Security Advanced product self-serve and offering domain-based threat intelligence free to users of its basic bundle. The service detects malicious browser-side JavaScript through browser reporting, AST-based behavioral analysis, and a new LLM review layer. Its goal is to catch sophisticated skimming attacks while reducing false positives and avoiding performance impacts on customer applications. ## Growing Threat of Client-Side Attacks - Browser skimmers can steal credentials, payment data, and personal information without disrupting page loads or checkout flows. - Recent examples include: - A browser keylogger placed on a major U.S. bank’s employee merchandise store. - Malicious npm package releases capable of enabling browser-based crypto theft when bundled into front-end applications. - These attacks often exploit trusted first-party or third-party scripts rather than obvious server vulnerabilities. ## Broader Access to Client-Side Security - Client-Side Security Advanced, formerly the Page Shield add-on, is now available to self-serve customers. - Domain-based threat intelligence is complimentary for customers using the free Client-Side Security bundle. - Advanced capabilities include: - Machine-learning and LLM-assisted malicious script detection. - Continuous code-change monitoring for compliance requirements such as PCI DSS v4.0 requirement 11.6.1. - Proactive positive security rules maintained through ongoing monitoring. ## Browser-Based Monitoring Without Application Changes - Cloudflare evaluates approximately 3.5 billion scripts per day, with enterprise zones averaging about 2,200 scripts. - The system gathers signals through browser reporting mechanisms such as Content Security Policy. - Customers do not need scanners or application instrumentation. - Traffic must be proxied through Cloudflare. - The approach adds no latency to web applications. ## Detecting Script Intent - Enterprise sites may contain thousands of scripts, and roughly one-third change within a 30-day period. - Manually approving every DOM interaction or outbound connection would create excessive operational overhead. - Cloudflare instead analyzes what scripts are attempting to do. - JavaScript is represented as an Abstract Syntax Tree (AST), allowing the system to identify behavioral patterns even when code is minified, renamed, or obfuscated. ## Reducing False Positives - Client-side compromises are relatively rare but potentially severe, unlike the high-volume attacks typically handled by a WAF. - Because genuine incidents are uncommon, even accurate detection systems can produce more false alarms than real alerts. - False positives contribute to security-team fatigue and can obscure actual compromises. - Legitimate but heavily obfuscated code—such as bot challenges, tracking pixels, advertising bundles, and minified frameworks—can resemble malicious code structurally. ## GNN and LLM Detection Pipeline - Cloudflare’s primary detector is a Graph Neural Network (GNN) operating on JavaScript ASTs. - The GNN learns structural representations of code and can recognize similar behavior despite syntactic changes. - It is optimized for high recall to detect novel and zero-day threats. - Although fewer than 0.3% of analyzed traffic is incorrectly flagged, Cloudflare’s scale makes that percentage a significant number of alerts. - An LLM provides semantic context, recognizing common JavaScript frameworks, domain-specific coding patterns, and benign forms of suspicious-looking obfuscation. - The LLM complements rather than replaces the GNN: - Scripts classified as benign stop after the fast GNN evaluation. - Scripts exceeding the GNN’s risk threshold are sent to an open-source LLM hosted on Cloudflare Workers AI for a second opinion. Cloudflare’s approach combines low-overhead browser telemetry, structural machine learning, and semantic LLM review. For organizations handling payments or sensitive user data, enabling these controls can improve visibility into third-party scripts, detect unexpected code changes, and reduce the chance that false alarms overwhelm security teams.

Read original(opens in new tab)