The provided content does not include the blog post’s body. It only contains the title, author links, navigation, and search interface, so the article’s technical argument and conclusions cannot be summarized reliably.
## Available Information
- **Title:** “Beyond AI That Speaks Well: Making Kanana-o Speak the Way Users Want”
- **Topic indicated by the title:** Improving Kanana-o’s voice-generation capabilities to produce speech according to user preferences.
- **Authors:** martin.gale, abigail.r, and edwin.ai
- **Missing:** The article’s main sections, implementation details, experiments, and conclusions.
Please provide the full article text or its URL content for a detailed summary.
The post explains how Toss Bank improved collaboration between Data Scientists (DS) and ML Engineers (MLE) by progressively formalizing their responsibilities. What began as manually transferring notebooks evolved into standardized Python files and finally into installable model packages built around explicit interfaces. The result was faster deployments, consistent observability, and clearer ownership, while AI-generated code introduced a new need to standardize coding style as well.
## Problems with Notebook-Based Handoffs
Initially, DS built models and inference code in Jupyter notebooks, then handed them to MLE.
- MLE had to recreate the serving code from scratch.
- Dependencies, configuration files, and source code were often missing or difficult to reproduce.
- Preprocessing logic could be interpreted differently by DS and MLE.
- “It works in the notebook” did not guarantee that it would work in production.
- As the number of models increased, communication and rework grew rapidly.
This approach separated people, not code, so the division of responsibility remained unclear.
## Phase 1: Separating Logic into `.py` Files
The team next moved the collaboration boundary from people to files.
- DS kept notebooks for experimentation and training.
- Core inference logic was extracted into `.py` files.
- MLE reviewed these files and validated them through CI.
- DS’s intended model behavior was preserved more reliably.
- Communication costs decreased.
However, the files lacked a standardized structure.
- Models used inconsistent function names such as `predict()`, `run()`, and `inference()`.
- Code still required modifications when moved into the serving environment.
- Global configuration changes in one model could affect other models sharing the same process.
- Logging, metrics, and error handling could not be applied consistently across models.
## Phase 2: Defining an Interface Contract
The team ultimately standardized the boundary through the `commons-ml-model` package.
- A base abstraction defines a common model structure.
- DS implements three methods:
- `pre_process`
- `inference`
- `post_process`
- The base class handles shared concerns such as:
- Logging
- Metrics
- Tracing
- Timing and request tracking
- DS packages the implementation as a reusable library.
- MLE installs the package with `pip install` and deploys it without rewriting the model.
This turns the division of work into a code-level contract. DS focuses on model behavior, while MLE owns serving infrastructure and operational concerns. Updating the base abstraction can also add observability features to every model at once.
## Monorepo Collaboration
The team manages the abstraction package and individual model packages in a single monorepo using `uv` workspaces.
- Changes to the abstraction and affected models can be reviewed in one pull request.
- DS and MLE review the same code in the same repository.
- CI, release, and versioning policies are centralized.
- Switching from Poetry to `uv` improved build speed by three to five times.
The tradeoff is that changes to shared packages can affect many models, and the repository becomes heavier as more packages accumulate.
## Standardizing AI-Generated Code
AI-assisted development created a separate collaboration problem: consistent structure did not guarantee consistent coding style.
The team introduced `pfmls-stylepack` to encode team conventions for AI tools.
- Naming conventions are standardized.
- Exception-handling patterns are prescribed.
- Rules determine when to use enums instead of hard-coded strings.
- Hooks apply conventions while code is being generated.
- AI-generated code can explain when a particular rule influenced its implementation.
The team therefore distinguishes between:
- **Structural consistency:** interfaces define what each role implements.
- **Style consistency:** shared rules define how code should be written.
Both are necessary for smooth reviews.
## Lessons from the Evolution
- The hardest decision is choosing the right collaboration boundary: excessive structure limits flexibility, while insufficient structure recreates inconsistency.
- Documentation and early DS–MLE pairing reduce the learning curve for the package-based workflow.
- Shared libraries are a double-edged sword: one change can cause broad impact, but one fix can also benefit every model.
- In the age of AI-generated code, teams must standardize not only responsibilities and interfaces but also implementation style.
The practical recommendation is to make collaboration contracts executable: define stable interfaces, package model code for reuse, centralize shared serving behavior, and enforce coding conventions automatically.
The Science One Framework addresses a central weakness in autonomous AI research: polished papers can contain fabricated citations, unreproducible results, or methods that do not match the underlying code. Its Chain-of-Evidence (CoE) framework requires every claim to be linked to concrete evidence and introduces CoE Audit to test those links automatically. In evaluations, Science One produced fully verifiable papers while matching or exceeding baseline research agents and human performance on several benchmarks.
## Chain-of-Evidence for Verifiable Research
- CoE defines trustworthy research artifacts through two requirements:
- **Completeness:** Every claim has a recorded evidence chain.
- **Correctness:** The evidence genuinely supports the claim.
- Claims may include:
- Bibliographic references
- Reported scores
- Method descriptions
- Conclusions
- Evidence can include peer-reviewed papers, experiment logs, executed code, or result tables.
- Hallucinated citations, unreproducible scores, and discrepancies between described and implemented methods are treated as broken evidence chains.
## The Science One Framework
The framework builds evidence into the research process instead of attempting to verify a paper after it has been written.
- **Problem Investigator**
- Uses the Semantic Scholar API to construct a citation graph.
- Reads up to 100 full-text PDFs per topic.
- Produces a structured research brief.
- Restricts final-paper references to sources retrieved through the grounded API, avoiding citations generated from model memory.
- **Discovery Engine**
- Explores ideas through parallel explore-exploit branches.
- Each isolated cycle includes a Solver agent and a task-specific evaluator.
- High-performing solutions are iteratively refined.
- Raw evaluator outputs are preserved in strict, read-only records.
- **Paper Writer and Claim Verifier**
- Creates a structured inventory of factual claims.
- Attaches inline evidence tags linking claims to workspace artifacts.
- Checks each claim against its declared source.
- Rewrites unsupported claims conservatively rather than allowing them to exceed the evidence.
## CoE Audit Integrity Checks
CoE Audit is an automated, post-hoc forensic review of a paper, solution, code, and references.
- **Score verification:** Re-runs the submitted code independently and compares the result with the paper’s reported score.
- **Specification violation:** Checks whether the code solves the intended task without exploiting the evaluator or accessing ground-truth answers.
- **Reference verification:** Validates every bibliography entry against academic APIs.
- **Method-code alignment:** Compares the paper’s method description with the actual implementation using LLM-based judges.
## Evaluation Results
- The audit evaluated 75 papers across five systems-optimization tasks: Prism, Cloudcast, EPLB, LLM-SQL, and transaction scheduling.
- Science One led the evaluated systems on all four integrity checks.
- It had:
- Zero phantom references
- Perfect score verification
- The strongest method-code alignment
- Baseline systems hallucinated up to 21% of references and sometimes described advanced algorithms that were implemented as simple deterministic heuristics.
- Strong verification did not reduce performance:
- Science One matched or exceeded human experts on all five ADRS tasks.
- It achieved the best overall result on Cloudcast and EPLB.
- On additional MLE-Bench and Parameter Golf evaluations, the framework also demonstrated competitive performance, including two Gold Medals across five difficult Kaggle competitions.
The main recommendation is to design autonomous research systems around evidence generation from the beginning. Grounded retrieval, immutable experiment records, claim-level verification, and independent auditing can substantially improve reliability without necessarily sacrificing research performance.
Quantum computers require constant recalibration because analog control signals drift during computation. Google Quantum AI combined reinforcement learning (RL) with quantum error correction (QEC), allowing a system to learn from detected errors and adjust thousands of control parameters while computation continues. Tests on the Willow processor showed improved logical stability, suggesting this approach could support much longer quantum computations.
## The Challenge of Quantum Errors
- Quantum systems are highly sensitive to drift in signal frequencies, amplitudes, and phases.
- Conventional recalibration requires stopping the entire computation, limiting algorithms that may need to run for days or months.
- QEC uses many physical qubits to form logical qubits and converts analog noise into binary error-detection events.
- These events indicate that an error occurred within a spacetime region but do not identify its precise cause or location.
- Decoders such as AlphaQubit and Tesseract infer corrections, but they do not explain whether errors arose from environmental decoherence or preventable calibration drift.
## Moving Beyond Physics-Based Calibration
- Traditional calibration depends on manually designed physical models.
- Such models can reach performance limits when hardware behavior involves complex, poorly understood interactions.
- Google argues that quantum control may benefit from the same shift toward data-driven learning seen in computer vision, robotics, and protein-folding research.
- As quantum hardware improves, remaining errors increasingly reflect subtle phenomena that are difficult to model analytically.
## Using Error Detection as a Learning Signal
- An RL agent experiments with control strategies and improves based on the resulting error data.
- QEC detection events serve two purposes:
- Decoders use them to infer logical corrections.
- The RL system uses them to identify drift and refine control parameters.
- This enables continuous calibration without interrupting the quantum computation.
- The approach can steer thousands of analog control parameters dynamically.
## Results on the Willow Processor
- Researchers deliberately introduced control-parameter drift into Google’s Willow superconducting processor.
- RL steering improved the logical stability of the error-correcting code by 3.5 times.
- After expert, human-guided calibration, RL fine-tuning reduced the logical error rate by an additional 20%.
- Combined improvements produced fewer than one logical error per 1,000 surface-code correction cycles and fewer than one per 100 color-code cycles.
- The processor therefore operated as a more reliable quantum memory for longer periods.
## Scaling to Larger Systems
- Simulations included hundreds of qubits and tens of thousands of control parameters.
- The RL agent reduced initially high physical error rates by learning better control settings.
- QEC suppressed the logical error rate exponentially as the number of physical qubits increased.
- The simulations indicated that the number of RL training iterations needed to reduce physical errors did not depend on system size, supporting potential scalability.
The results suggest that future quantum computers could use QEC not only to correct errors but also to learn their causes and continuously adapt to hardware drift. RL-based calibration could reduce dependence on manual tuning and help make long-running, fault-tolerant quantum computation practical.
Meta marks its 10th consecutive year sponsoring the Python Software Foundation (PSF), emphasizing that Python is central to its infrastructure, products, and AI work. The company views sponsorship as both a responsibility to the open-source community and a strategic investment in the long-term health, security, and innovation of the technology it relies on.
## Python’s Role at Meta
- Python is Meta’s most widely used programming language.
- It supports infrastructure for products including Instagram and Threads, as well as AI research and data-driven initiatives.
- Meta engineers contribute directly to Python’s development, including core maintenance and Python Enhancement Proposals.
- Meta’s open-source contributions include:
- PyTorch, originally developed at Meta before becoming an independent foundation.
- Pyrefly, a fast Python type checker and language server.
- Meta expects Python to remain important as it expands AI capabilities and scales its infrastructure.
## Why Meta Supports the PSF
- Open-source adoption creates a shared responsibility to maintain a healthy, secure, and sustainable ecosystem.
- PSF funding supports the Developer-in-Residence program, enabling full-time developers to work on Python improvements that might otherwise be neglected or left to volunteers.
- Sponsorship helps strengthen PyPI, including critical security improvements that protect package distribution and consumption.
- Funding also supports education and community development through:
- PyCon US workshops, summits, and discounted or free passes.
- Fundraising and support for groups such as PyLadies.
- Meta considers these efforts an investment in the tools, infrastructure, and people behind its own technology stack.
## Ways to Support the Python Software Foundation
- Individuals can make one-time donations or become PSF members.
- Membership may include voting rights and can be supported through financial contributions or volunteer time.
- Organizations can become annual sponsors at different contribution levels.
- Sponsorship offers public recognition, community engagement opportunities, event participation, and—in higher tiers—greater visibility and invitations to special initiatives.
Meta concludes by thanking Python’s maintainers, contributors, educators, and advocates, while encouraging other individuals and organizations to help sustain the language through PSF donations, membership, or sponsorship.
Google Research has expanded its building-level rooftop reflectivity dataset from 14 pilot cities to more than 50 cities across nine countries. By combining Sentinel-2 satellite data with 30-centimeter commercial imagery and machine learning, the project identifies roofs where reflective “cool roof” interventions could reduce urban heat. The data is publicly available through a new Google Earth Engine app for planners and researchers.
## Why Rooftop Reflectivity Matters
- Extreme heat contributes to approximately 500,000 deaths annually.
- Urban heat islands make cities warm faster than the global average.
- Dark roofs, pavements, and limited vegetation increase heat absorption.
- Reflective roofs reduce the solar energy absorbed by buildings and can lower local surface temperatures.
- Earlier pilot data from 14 cities supported cool-roof ordinances and broader climate adaptation plans.
## Building-Level Albedo Mapping
- Sentinel-2 provides global albedo data but at 10-meter resolution, which cannot reliably distinguish individual rooftops.
- Google Research fused Sentinel-2’s spectral and global coverage with 30-centimeter Airbus Pléiades Neo imagery.
- Machine learning and radiometric calibration reconstruct detailed reflectance profiles at the urban-pixel level.
- Validation against airborne hyperspectral measurements in Boulder, Colorado, produced an RMSE of 0.04.
- The resulting maps allow planners to prioritize large, low-reflectivity buildings for cool-roof retrofits.
- The modeling suggests targeted interventions could reduce extreme urban heat by up to 0.5°C globally.
## Heat Resilience Earth Engine App
- Displays building-level albedo using rooftop centroids to highlight low-reflectivity surfaces.
- Provides baseline analyses and supports monitoring changes over time.
- Allows users to download high-resolution data for local studies and policy development.
- Offers a nested view that moves from census-tract summaries to individual buildings.
## Expanded Global Coverage
- The dataset now covers more than 50 cities in nine countries.
- Newly included urban areas span Europe, Brazil, and the United States.
- Examples include London, Athens, Barcelona, Rio de Janeiro, São Paulo, Los Angeles, Austin, and New York City.
- The open dataset is intended to help municipalities accelerate reflective-surface programs.
## Access and Collaboration
- The interactive app and datasets are publicly available through Google’s Heat Resilience site.
- The methodology is described in the Nature Communications paper “Estimating high-resolution albedo for urban applications.”
- The work was developed by Google Research in collaboration with the World Resources Institute.
Cities can use the app to identify the buildings and neighborhoods where cool-roof investments are likely to have the greatest heat-reduction benefits.
LY Corporation improved LINE Part Time Jobs’ real-time search reranking by stabilizing user and item embeddings produced by a two-tower recommendation model. The approach addressed both cold-start degradation and daily embedding-space drift without changing the underlying model or training pipeline. Offline and online evaluations showed substantial gains, including a 4.7% overall KPI increase and 6.5% revenue growth.
## Search Reranking at LINE Part Time Jobs
- Search consists of:
- Retrieval, which finds listings matching a query.
- Reranking, which orders the retrieved candidates.
- The previous system ranked listings by cosine similarity between precomputed user-to-item two-tower embeddings.
- This approach was computationally simple and captured broad user preferences, but:
- It ignored query-specific information, such as the distance from a selected station.
- Its embeddings combined behavior from multiple services and recommendation modules, not just search activity.
- The team therefore introduced a dedicated real-time reranking model.
## Challenges with the Dedicated Reranking Model
### Cold Start
- Most job listings are replaced at the beginning of each month.
- New listings initially lack sufficient interaction data.
- As a result, reranking quality dropped until enough training data accumulated.
### Embedding-Space Drift
- Two-tower models were regularly retrained from random initialization.
- Each training run produced a different embedding space.
- Using embeddings as downstream features caused a mismatch between training-time and inference-time data, reducing model performance.
## Stabilizing the Embedding Space
- Each day’s embeddings are aligned with the previous day’s stabilized embeddings.
- The first day’s embeddings are used without stabilization.
- This preserves continuity across retraining cycles and allows embeddings generated on different days to remain comparable.
- Downstream models and embedding generation no longer need perfectly synchronized update schedules.
### Low-Rank SVD
- User and item embeddings are converted into a more standardized low-dimensional representation.
- Instead of decomposing the enormous user-item score matrix directly, transformation matrices are derived from the embedding matrices.
- This makes the procedure practical for large-scale data.
### Orthogonal Procrustes Alignment
- The transformed embeddings are aligned to the previous day’s stabilized space.
- The orthogonal transformation only rotates or reflects the space.
- Distances and inner-product relationships are therefore largely preserved, maintaining the two-tower model’s scoring behavior.
## Scalable Implementation
- The algorithm was implemented with Apache Spark to handle LINE Part Time Jobs’ large datasets.
- For low-rank SVD:
- The original QR decomposition was optimized using Cholesky decomposition.
- The Gram matrix \(G=A^\top A\) is decomposed to obtain the same upper-triangular matrix \(R\) as QR decomposition.
- For Procrustes alignment:
- The large matrix multiplication \(M=B^\top A\) is distributed across Spark.
- The resulting \(e \times e\) matrix is small enough for SVD on a single node using NumPy.
## Evaluation Results
### Embedding Stability
- Before stabilization, embeddings from randomly selected days had correlations close to zero.
- After stabilization:
- Similarity remained around 0.88 after one week.
- Similarity remained around 0.87 after one month.
- This reduced performance loss caused by embedding drift.
### Offline Evaluation
- Unstabilized embeddings reduced nDCG by approximately 1–5% when training and inference used different days.
- Stabilized embeddings improved:
- Conversion nDCG by about 9.0%.
- Click nDCG by about 4.5%.
### Online A/B Test
- Search-page KPIs alone did not show statistically significant improvement.
- Across the entire service:
- KPIs increased by 4.7%.
- Revenue increased by 6.5%.
- The results suggest that the embeddings captured long-term user preferences that influenced later actions across the service, not only behavior on the search page.
- The added embedding features also helped mitigate the initial cold-start problem.
## Practical Benefits and Future Work
- The solution required no changes to the two-tower model itself.
- Stabilization was added as post-processing, minimizing changes to existing pipelines and reducing deployment risk.
- LY Corporation plans to test the method as the service expands its sources of job listings and to reuse the approach across other services through its internal machine-learning platform.
Overall, sequential low-rank SVD and orthogonal Procrustes alignment provide a relatively simple way to make frequently retrained embeddings reliable downstream features while improving real-time reranking and business outcomes.
Linear elastic caching treats cache memory as a variable cost rather than a fixed allocation. It dynamically adjusts how long pages remain in memory by balancing ongoing memory expense against the cost of fetching evicted data again, using the ski rental problem as its theoretical foundation. Experiments in Spanner and public cache traces show meaningful cost reductions with only modest increases in misses.
## Fixed-Size Cache Limitations
- Traditional caches allocate a fixed amount of RAM and use policies such as LRU when space runs out.
- Undersizing the cache causes excessive disk or storage access and poor performance.
- Oversizing it wastes money during periods of low demand; some serverless providers charge up to $3 per day for 1 GiB of memory.
- Fixed sizing therefore creates a “Goldilocks” problem as workloads fluctuate.
## Ski Rental Model for Cache Eviction
- Each cached page presents two choices:
- **Rent:** Keep it in RAM and continuously pay for its memory footprint.
- **Buy the miss:** Evict it and risk a latency and I/O penalty if it is requested again.
- A ski rental algorithm assigns each page a time-to-live (TTL).
- If the page is not accessed before its TTL expires, it is evicted.
- If the cache becomes physically full, a conventional policy such as LRU handles capacity pressure.
- The researchers prove that eviction policy and rental duration can be optimized separately, simplifying implementation.
- Unlike worst-case break-even or randomized ski rental strategies, lightweight machine learning can exploit predictable workload patterns.
## Lightweight TTL Prediction
- In Spanner, each page receives a TTL based on:
- Page size
- Cost of a cache miss
- Type of database operation
- Observed access behavior
- A shallow decision tree was chosen because Spanner processes billions of requests per second.
- The model can be translated into a few lines of interpretable C++ code.
- Its cost-aware decisions allow extra misses mainly for data that is inexpensive to retrieve.
## Spanner Production Results
- Compared with a standard fixed-size cache:
- Memory usage fell by **15.5%**.
- Cache misses increased by only **5.5%**.
- Total cost of ownership fell by approximately **5%**.
- The additional misses increased actual I/O costs by only **0.5%**, because they were concentrated on cheap-to-fetch data.
- The policy was deployed on production Spanner servers and evaluated over several months.
## Public Trace Evaluation
- The approach was tested on public industry cache traces using GDSF as the fixed-size baseline.
- GDSF generalizes LRU to account for pages with different sizes.
- Researchers evaluated four elastic-cache variants using:
- Break-even or randomized ski rental policies
- Learned or non-learned TTL selection
- Because public traces lacked application-level features, learning used the first half of each trace to calculate the best TTL for individual pages.
- Caches were warmed with one day of requests before performance measurement began.
## Overall Results
- Elastic caching consistently produced lower total cost across diverse workloads.
- Its advantage increased as memory became more expensive relative to cache misses.
- At comparable cache sizes, elastic policies also achieved substantially lower miss rates than fixed-size approaches.
Linear elastic caching is most useful when memory costs vary significantly or workloads are bursty and predictable. Dynamically assigning page TTLs offers a practical way to reduce memory spending while limiting performance impact, especially when the system can estimate the cost of each miss.
Netflix developed boosted-tree models to predict when in-progress productions will deliver Locked Cuts and final IMF media. The models address gaps and inaccuracies in manually maintained schedules, improving delivery-date accuracy and providing earlier warnings of risk. Backtesting shows that predictive dates reduce error and Accumulated Error Days (AED), a measure strongly associated with launch delays.
## Launch Preparation and Schedule Risk
- After production, titles move through post-production and launch preparation.
- Final IMF assets trigger work on:
- Artwork and trailers
- Subtitles
- Maturity ratings
- Quality control
- Teams can begin earlier with a non-final Locked Cut, but later changes may require conformance work.
- Waiting for the IMF risks compressing the launch timeline if delivery is late.
## Problems with Manual Schedules
- Delivery estimates are manually supplied by content partners.
- Schedules often contain missing dates and inaccurate estimates.
- Dynamic production conditions—schedule changes, conflicts, and unforeseen obstacles—frequently cause delays.
- Predictive modeling can fill missing ETAs and improve existing ones.
## Accumulated Error Days and Launch Misses
- Accumulated Error Days (AED) measures the cumulative difference between estimated and actual delivery dates.
- Titles with launch misses have significantly higher mean AED than titles without misses.
- Inaccuracies close to delivery are more strongly associated with launch misses than errors accumulated over longer periods.
- Improving schedule accuracy near launch is therefore especially valuable.
## Predicting Time to Delivery
- Netflix uses boosted-tree regression models to predict the number of days until Locked Cut or IMF delivery.
- Models use:
- Production progress signals
- Title metadata
- Seasonal indicators
- Daily snapshots of production data
- Snapshot-based modeling keeps predictions current and supports changing features throughout all production phases.
## Evaluating Predictive Performance
- Netflix compares predicted and scheduled dates using:
- Mean and median absolute error
- Mean and median bias
- Error standard deviation
- Rates of large errors beyond specified day thresholds
- Predictive dates offer full coverage, unlike schedules that may lack estimates at some horizons.
- Backtesting showed lower errors and fewer outliers for predicted IMF and Locked Cut dates.
## Earlier Accuracy Signals
- Predictions can become reliable earlier than manual schedules.
- Six months before Locked Cut delivery, predictions were more accurate than scheduled dates for 76% of titles.
- Their 6.1-week mean absolute error matched the accuracy of scheduled dates only 11 weeks later.
- Across six months before delivery, predicted dates reduced AED for most buying organizations and content types.
## Integrating Predictions into Existing Workflows
- Because delivery dates already support stakeholder workflows, predictive estimates can be introduced without redesigning those processes.
- The remaining challenge is deciding when to trust scheduled dates versus predictions.
- Although predictions are generally more accurate, manual schedules can still outperform them in some situations, requiring a way to select the more reliable estimate.
Netflix’s modeling approach turns production data into an ongoing risk signal rather than relying solely on static partner schedules. Using predictive dates alongside existing workflows can give teams earlier, more accurate information for launch planning and help reduce avoidable launch delays.
Toss developed TUES (Toss User Engagement Segment) to analyze its 28 million monthly active users from a platform-wide perspective. It groups users by their service-use patterns, enabling Toss to understand user motivations, design segment-specific strategies, and explain changes in company-wide metrics. TUES V2 improves on the original by capturing usage depth, multi-service behavior, and engagement with individual service categories.
## Platform-Wide User Segmentation
- Service-specific segments such as “users of Service A” are not mutually exclusive or collectively exhaustive because users may use multiple services.
- TUES groups users with similar patterns across Toss’s entire service ecosystem.
- It helps identify:
- Which services users primarily use
- How engaged they are with the app
- Which user groups may be suitable for particular growth or marketing strategies
## How TUES V1 Worked
- Toss calculated each user’s service-use rate per app open.
- For example, a user who opened the app 60 times and used Toss Pay during 20 of those sessions had a 33% usage rate.
- Users with similar service-usage distributions were grouped using K-Means clustering.
- The raw clusters were interpreted and renamed to make them more useful for product and strategy teams.
- V1 included:
- **Highly engaged users:** Users who regularly use several services
- **Service-oriented users:** Users primarily focused on Toss Bank, Toss Securities, inquiry services, benefits, transfers, or other services
- **Simple visitors:** Users who open the app but rarely use its services
## How Toss Uses TUES
- **Transition strategy:** Teams can plan how to move users from simple visits to service-oriented engagement and eventually to highly engaged usage.
- **Product growth:** Product teams can quickly identify which user segments use their service most and combine that insight with transition strategies.
- **Behavior analysis:** TUES reveals when users change segments, begin churning, or return after inactivity.
- **Top-line metric analysis:** When MAU changes, Toss can identify which user segments moved and which services likely caused the change.
- **Targeted marketing:** Marketers use TUES segments for campaigns such as push notifications. The segments are also available in Toss’s internal marketing tool, TUBA.
## Limitations of TUES V1
After roughly two years of use, Toss identified several weaknesses:
- V1 measured only the probability of using a service during an app open, not the number of times it was used.
- Users who engaged with a service once and users who used it ten times could appear equivalent.
- It could not show engagement with secondary service categories.
- K-Means is a hard-clustering method, so each user belonged to only one segment despite often using multiple services.
- New major services, including Toss Shopping, App in Toss, and Toss Pay, were grouped into a generic “ETC” category.
## TUES V2 Improvements
- **Usage-depth measurement:** V2 uses the number of service interactions per app open as a feature, capturing the intensity of engagement.
- **Soft clustering:** Instead of assigning each user to one segment, V2 calculates each user’s degree of association with multiple segments and selectively uses those results.
- **Three-layer structure:** Users are described through:
1. Overall app engagement
2. Primary service orientation
3. Engagement with each individual service category
- The layers are built sequentially, making it clearer why a user belongs to a segment and what action may be appropriate next.
## New Strategic Capabilities in V2
- Teams can identify which service-category engagement should increase first to move users from a semi-engaged segment to a highly engaged one.
- Individual service teams, or silos, can quantitatively connect actions that increase service engagement with company-wide segment and performance changes.
- Products can more clearly compare the engagement profiles of users who do and do not use their services.
- Cross-activation strategies now have a more precise starting point based on service-level engagement.
## Future Development
Toss plans to combine TUES with additional analytical frameworks to:
- Create faster and more detailed transition strategies using concepts such as service similarity.
- Build strategic user maps based on user profiles and service-use patterns.
- Quantify segment-specific value by combining TUES with frameworks such as MTVi.
TUES demonstrates how platform-level segmentation can make a growing MAU base easier to understand and act upon. By combining overall engagement, primary service use, and service-level depth, TUES helps Toss develop more targeted growth strategies and connect individual product actions to broader company outcomes.
Cloudflare is bringing key members of Ensemble AI onto its team to improve AI infrastructure and inference efficiency. Ensemble’s work on model compression, structured neural architectures, and parameter-efficient fine-tuning complements Cloudflare’s Workers AI platform. The combined effort aims to make powerful AI models faster, cheaper, and easier to deploy globally.
## Incorporating Ensemble AI’s Expertise
- Ensemble AI has focused on reducing the memory, compute, and deployment costs of large language and multimodal models.
- Its NdLinear technology replaces standard transformer linear layers while preserving multidimensional structure such as attention heads, channels, and spatial dimensions.
- NdLinear-LoRA reduces the number of trainable parameters needed to fine-tune large models.
- These techniques complement quantization and vector quantization to improve model efficiency without significantly sacrificing quality.
## Improving AI Inference Economics
- Cloudflare Workers AI provides serverless GPU-powered inference across Cloudflare’s global network.
- Lower model size, memory usage, and compute requirements can improve throughput, GPU utilization, and overall inference costs.
- These improvements are increasingly important for agents, multimodal applications, personalization, fine-tuning, retrieval, and reinforcement learning.
- The Ensemble team will contribute to Cloudflare’s existing work, including the Infire inference engine, Unweight tensor compression, and systems for running very large language models.
## Supporting Next-Generation Workloads
- Developers increasingly need AI infrastructure that is reliable, affordable, globally distributed, and close to end users—not merely access to models.
- Cloudflare’s network, serverless platform, and Workers AI provide a foundation for deploying AI with less operational complexity.
- Combining Cloudflare’s infrastructure with Ensemble’s efficient model architectures should enable lower-cost, higher-performance AI deployments at scale.
Cloudflare’s stated goal is to make advanced AI workloads more accessible by improving the economics and efficiency of inference across its platform.
Google Research examined how AI tools can help non-experts understand skin conditions and decide what to do next. In a large study, AI substantially improved people’s ability to identify possible conditions, but it did not reliably improve the accuracy of recommended next steps. The research therefore argues that dermatology AI should be designed around human decision-making, safety, and clear guidance—not diagnosis alone.
## Why Dermatology AI Needs Human-Centered Research
- More than half of adults use the Internet for health information, and about one-third use AI.
- People often lack the medical vocabulary needed to search effectively—for example, searching for “red dots on legs” instead of “palpable purpura.”
- Google Research has developed dermatology AI models, validated their generalization, and released datasets such as SCIN.
- Earlier research found that online tools can improve condition recognition without necessarily helping people choose appropriate next steps.
- The researchers emphasize studying how people interpret and act on AI-generated information.
## Large-Scale Evaluation of an AI Information Tool
- A JAMA Dermatology study involved 2,345 participants reviewing de-identified skin-condition cases with images and structured medical histories.
- Participants were assigned to one of three groups:
- **Standard-search control:** Used familiar text-based search tools.
- **AI group:** Used a prototype showing 3–7 AI-predicted conditions, textbook images, and information about symptoms and treatments.
- **“Wizard of Oz” control:** Used the same interface, but with dermatologist-provided differential diagnoses presented as if generated by AI.
- The AI interface increased participants’ willingness to name a condition:
- More than 62% attempted a diagnosis with AI.
- Only 41% did so using standard search.
- Accuracy also improved:
- AI users correctly identified a matching condition about 23% of the time.
- Standard-search users achieved 8%.
- The “perfect-prediction” interface reached 36%, showing that even accurate candidate lists did not make users nearly perfect.
- AI users reported greater confidence, satisfaction, and satisfaction with the time spent searching.
## Identifying a Condition Does Not Guarantee Safe Action
- The prototype intentionally avoided prescribing actions or making individualized diagnoses.
- Treatment information was dermatologist-written and based on the condition name, rather than the severity or details of the specific case.
- Choosing the right next step—such as home care, routine care, or urgent evaluation—remained difficult.
- Next-step accuracy improved only slightly in the “Wizard of Oz” group, from 60% in the standard-search control to 63.5%.
- The standard AI group showed no statistically significant improvement.
- AI users were slightly more likely than control participants to recommend a less urgent action than dermatologists would: 30% versus 27%.
- These findings show that identifying possible conditions is insufficient without stronger safety-oriented guidance.
## Studying Real Users and Diverse Communities
- The researchers also conducted a qualitative study, published at ACM CHI, to examine how people use AI for their own active skin concerns.
- The project partnered with Stanford’s Healthcare AI Applied Research Team and the Santa Clara Family Health Plan.
- The community included many Medi-Cal users who rely on a healthcare safety net.
- Researchers aimed to gather richer feedback than survey-based studies provide by observing real-world use.
- Because participants spoke four primary languages, the application was translated into those languages, with multilingual volunteers or staff available to support communication.
AI can make dermatology information easier to find and improve recognition of possible conditions, but it should not be treated as a substitute for professional judgment. Future tools should focus equally on urgency assessment, personalized context, uncertainty, and clear recommendations for when to seek medical care.
Google Research has open-sourced the hydrology framework behind its Flood Hub river forecasts. The Python/PyTorch package lets researchers and national forecasting agencies train AI models with global and local data while retaining control over their information. Google argues that open access, local expertise, and interoperable tools can make advanced flood warnings more accurate, affordable, and widely deployable.
## The Open-Source Hydrology Framework
- The framework is available on GitHub under an Apache 2.0 license.
- It provides model architectures, training pipelines, documentation, and tutorials.
- Users can train models with climate, soil, topography, land-cover, and weather data.
- Historical river observations come from the open Caravan dataset, which agencies can extend with local measurements.
- The package is built with PyTorch and is intended for both researchers and operational forecasters.
## Model Versions and Improvements
- The release includes:
- The original model used in Google’s 2024 benchmarking study.
- An upgraded v2 model currently used for real-time global forecasts in Flood Hub.
- The v2 model uses a multi-input ME-LSTM architecture.
- Separate networks embed different meteorological products before combining them in an LSTM.
- Inputs include GraphCast, ECMWF forecasts, NASA IMERG satellite rainfall estimates, and NOAA CPC precipitation data.
- Benchmarking showed the newer model extends the reliable forecast horizon by:
- Six days in gauged river basins.
- One day in ungauged basins.
## Local Data and Operational Forecasting
- Agencies can fine-tune models for specific watersheds using local observations and expert knowledge.
- The approach supports the integration of Indigenous and Local Knowledge, which the World Meteorological Organization says is still rarely incorporated systematically.
- Models are designed to be relatively inexpensive and easier to train than traditional conceptual hydrological systems.
- Local organizations can preserve control over their data while adapting the models to regional conditions.
## Partnership with the Czech Hydrometeorological Institute
- Google worked with CHMI to validate the model against locally calibrated traditional forecasting models.
- CHMI created an adapter connecting the framework to Delft-FEWS, a widely used operational forecasting platform.
- This integration demonstrates how machine-learning forecasts can fit into existing workflows used by government agencies, NGOs, and private organizations.
- The partnership provides a practical model for other national hydrological services.
## Broader Flood-Resilience Goals
- Open-source distribution could help resource-constrained regions access advanced forecasting without expensive infrastructure.
- The framework is intended to support capacity building for early-warning systems worldwide.
- Google presents the release as a way to let the global hydrology community reproduce, improve, and localize its research.
National hydrological agencies and researchers should evaluate the open-source framework using their own watershed data, integrate it with existing forecasting systems, and validate its predictions against established local models before operational deployment.
Google’s I/O 2026 research announcements present AI as an “agentic” amplifier of human ingenuity, particularly in science and healthcare. New systems such as Gemini for Science, ERA, Co-Scientist, and Gemini Deep Think are designed to generate hypotheses, write and optimize code, evaluate evidence, and solve difficult research problems. Google also highlighted health-focused AI that supports users before, during, and after medical visits, while emphasizing collaboration, validation, and responsible deployment.
## AI-Driven Scientific Discovery
- **Gemini for Science** is a suite of experimental tools built from Google Research and developed with Google Cloud, Google DeepMind, and Google Labs.
- **Empirical Research Assistance (ERA)** acts as a code-optimizing research engine:
- Proposes concepts and writes software.
- Evaluates results against a defined scoring system.
- Uses tree search to test thousands of code variants.
- Has supported work in neuroscience, cosmology, respiratory-illness forecasting, and California runoff prediction.
- **Co-Scientist** is a Gemini-based multi-agent collaborator that generates, evaluates, and refines hypotheses.
- Researchers have applied it to antimicrobial resistance, plant immunity, and liver fibrosis.
- **Computational Discovery**, combining ERA and AlphaEvolve, runs thousands of code variations in parallel to test scientific models and hypotheses more quickly.
- **Hypothesis Generation** uses a multi-agent “idea tournament” to debate and rank research ideas, with clickable citations supporting claims.
- **Literature Insights**, powered by NotebookLM, helps researchers synthesize large bodies of scientific literature.
- **Science Skills** can automate specialist workflows such as structural bioinformatics and genomic analysis on agentic coding platforms.
## AI for Peer Review and Advanced Reasoning
- Google is piloting the **Paper Assistant Tool (PAT)** for scientific peer review.
- PAT has experimentally reviewed more than 10,000 papers for conferences including ICML, STOC, and NeurIPS.
- Its feedback has helped authors identify theoretical gaps and design additional experiments.
- **Gemini Deep Think** has been used with mathematicians, physicists, and computer scientists to address open problems involving network deadlocks, optimization, machine-learning behavior, auction theory, and cosmic-string singularities.
## Advancing Health with AI
- Google’s health research focuses on supporting people throughout the full healthcare journey, from understanding symptoms and preparing for appointments to interpreting medical records.
- Research contributions underpin the **Google Health app** and **Google Health Coach**, with the app beginning rollout to existing Fitbit users.
- **Symptom AI** investigates how conversational AI can reason about information relevant to a person’s symptoms.
- A Fitbit-based study included 13,917 participants.
- In blind comparisons, clinicians preferred Symptom AI’s differential diagnoses roughly twice as often as those produced by other clinicians.
- The **Plan for Care** pilot involved 1,779 participants preparing for doctor visits.
- Compared with baseline systems, 15% more users felt prepared.
- 13% more users felt confident they could make effective use of their appointment.
- Google is also studying personal health large language models and the use of personal health record data to improve health guidance.
Google’s announcements point toward research systems that actively experiment, collaborate, and reason rather than merely retrieve information. Their practical value will depend on continued scientific validation, clinician involvement, privacy protections, and careful expansion from experimental tools into real-world use.
AWS has named four new Heroes for May 2026, recognizing leaders who advance cloud, AI, serverless, and community education. Their work ranges from building Amazon Bedrock-powered tools and contributing to AWS certifications to organizing major user groups and events across Europe and Latin America. Together, they demonstrate how technical expertise and community leadership can help more builders adopt AWS.
## Damiano Giorgi — Pavia, Italy
- An Artificial Intelligence Hero and Cloud Solutions Architect specializing in AI.
- Helps organize AWS User Groups in Pavia and Milan.
- Created the “Unofficial post:Invent Session Suggester,” using Amazon Bedrock and Amazon Nova to recommend re:Invent sessions.
- Shares knowledge through his “Bass and Bytes” blog and conferences across Europe.
## Darryl Ruggles — Ottawa, Canada
- A Serverless Hero and Cloud Solutions Architect with a background in software development.
- Focuses on AWS application architecture, AI/ML, serverless, containers, and FinOps.
- Publishes blog posts, LinkedIn content, and open projects.
- Participates actively in online communities such as “Believe In Serverless” and in-person AWS events.
## Ricardo Daniel Ceci — Buenos Aires, Argentina
- An Artificial Intelligence Hero leading the AWS User Group Buenos Aires, with nearly 2,400 members.
- Principal organizer of AWS Community Day Argentina.
- Named AWS Community Leader of the Year 2025 for Latin America.
- Hosts a podcast with cloud experts, AWS Heroes, and developer advocates.
- Works to make cloud and AI more accessible to Spanish-speaking builders across LATAM.
## Matias Kreder — Buenos Aires, Argentina
- An Artificial Intelligence Hero and AWS Certification Subject Matter Expert.
- Contributed to AI/ML certifications, including the AWS Certified AI Practitioner exam.
- Began his community involvement through AWS DeepRacer, qualifying as a finalist three times.
- Organizes racing events, ML talks, and AWS community activities across Latin America.
- Helped organize AWS Community Day Argentina 2025 and speaks at regional events.
These new Heroes illustrate the value of combining AWS expertise with mentorship, content creation, certification work, and community organizing. Builders can learn more or connect with regional leaders through the AWS Heroes program.
