标签：#learn

Originally published at ai.bedvibe.studio . I built a text-to-speech product and kept getting burned by the same thing. On normal sentences the model sounded great. Then it would hit a number, a date, an acronym or a name, and quietly mangle it. Worse, the metric everyone reaches for — Word Error Rate — was lying to me in both directions. It flagged perfectly good audio as broken because the script said 3:30 PM and the transcript said "three thirty pee em." And it missed real failures on short tokens, where the speech recogniser is as unreliable as the TTS. So I wrote the QA framework I wished I had, packaged it as ttsproof , and then ran it as a blind study against a production TTS service so the results would be more than an opinion. The two failures WER cannot see A TTS pipeline breaks in two different ways, and a single WER number blurs both. Structural defects. The clip is empty, truncated, three times too long, stuck in a repeated-chunk loop, clipping, or has a click at the tail. These have nothing to do with pronunciation — you can catch them with no model at all, straight from the waveform. Pronunciation and content errors on the hard cases: numbers, decimals, dates, clock times, acronyms, single letters, URLs, names. ttsproof splits them apart and handles each one honestly: Structural checks, no model needed — empty or truncated audio, duration explosions, long internal silences, clipping, loop detection, end-of-clip artifacts. numpy and soundfile, nothing else. Equivalence-aware WER/CER — the expected text and the ASR transcript are both canonicalised to spoken form before scoring, so 3:30 PM against "three thirty" stops counting as an error. ASR-uncertainty quarantine — when the audio is structurally clean but the recogniser disagrees on a very short utterance, the sample is set aside for a human instead of being auto-failed. At that length the ASR is as likely to be wrong as the TTS. The study: 390 samples, and a blind human check I evaluated the method

Originally published at ai.bedvibe.studio . There is an assumption almost every practitioner carries without examining it: if your dataset has bad samples in it, the loss will tell you. Corrupted rows spike. Broken files stick out. Sort by per-sample loss, look at the top of the list, and there is your garbage. I believed it too. Two separate failures in my own work say it is wrong, and they fail in the same direction — quietly. The reproducible one: a dataset that cannot be learned While validating trainproof I ran a controlled fault-injection study: one base setup, a Qwen2.5-3B QLoRA, run six ways, three seeds each, eighteen runs total. Every log ships in the repo so the verdicts can be checked rather than believed. One configuration shuffled the dataset's labels into pure noise. The labels no longer corresponded to the inputs at all. This is not a hard dataset or a noisy dataset. It is a dataset that cannot be learned , because there is no relationship left in it to learn. That run reduced its loss by 62%. On its own curve it was textbook-healthy — a clean downward slope, no spike, no plateau, nothing a human or a rule would flag. It was learning nothing useful. It was memorising the statistics of noise, which any sufficiently large network will happily do. From a single run's loss curve it is indistinguishable from a real one. That is where the assumption broke for me. Not "loss is a weak signal for this." Loss is not a signal for this at all, in isolation. The production one, and what I can and cannot prove about it The second failure came from real work rather than an experiment, and it is the one I think about more. Building a text-to-speech corpus of roughly 110,000 recordings, a small number of the files were pure loud white noise. Not corrupted in the file-format sense — they opened fine, played fine, had valid headers and valid duration. They simply contained no speech. Just noise, at volume. They did not surface as high-loss outliers. Being precise about

Originally published on tamiz.pro . You spent weeks building an agentic workflow that works flawlessly on your local machine. It handles edge cases, calls APIs correctly, and follows the chain of thought precisely. Then you deploy it. Within hours, users report hallucinated tool calls, lost context after five turns, and infinite loops that drain your budget. You stare at the logs and realize the agent isn't broken—it’s just not engineered for production reality. The gap between a prototype agent and a production-grade system is not complexity; it’s discipline. Most agents fail in production due to three specific engineering gaps: Memory Leakage (context drift and state management), Evaluation Blindness (lack of deterministic testing), and Tooling Fragility (unhandled error states and race conditions). This deep-dive dissects these failure modes and provides the architectural patterns to bridge them. The Illusion of Statelessness LLMs are stateless functions. Every token generated is conditioned entirely on the input history provided in the prompt. In production, this simplicity becomes a liability when the conversation exceeds the model’s context window or when “memory” is required across sessions. The Context Window Trap The most common failure point is naive prompt accumulation. Developers often push the entire conversation history into every subsequent call: # ANTI-PATTERN: Unbounded History Accumulation messages = [ { " role " : " system " , " content " : " You are a helpful assistant... " } ] for turn in conversation_history : # Grows indefinitely messages . append ( turn ) response = client . chat . completions . create ( model = " gpt-4 " , messages = messages # Context window blows up ) messages . append ( response ) By turn 10, you’re sending 8,000 tokens of historical noise. Latency spikes, costs explode, and the signal-to-noise ratio degrades the LLM’s reasoning quality—a phenomenon known as lost in the middle . Production-Grade Memory Architecture Produc

hello everyone. I'm training PPO variants on different multi-agent tasks from the VMAS library (Independent PPO / Graph PPO and such, see HetGPPO by Bettini et al.). I noticed that for every architecture/scenario couple, the optimal hyperparameters sometimes tend to vary (learning rate, entropy coefficient, KL coefficient, SGD batch size, etc). do I need - methodologically speaking - to unify the hyperparameters of all models in order to make a fair and correct comparison of architectures later on? note: sometimes unifying these HP leads to some non converging models. note 2 : my objective is to test these models' robustness under adversarial attack in test-time (frozen models). thank you in advance. submitted by /u/ham_bam0 [link] [留言]

I'm one of the co-authors of this paper. It's a seminal work in exploring the properties of 3D generated by LLMs via spatial programming. I've set up visual demonstrations of such 3D objects at: https://nova3d.xyz/ Scroll down and notice how the various 3D objects are all composed of logical parts and enable natural movements out of the box. There's a github repo in there as well. Under the hood: We found that 3D that exists as software is much more useful than typical monolithic mesh blobs generated by traditional AI 3D generators. For instance they are animation-ready and programmable from inception. They can contain the logic - at birth - to appear differently in weak compute environments (e.g. mobiles) vs powerful environments (e.g. sophisticated game engines). They can be built with full hierarchical structure and hinge/socket articulation at authoring time. They lag behind traditional AI 3D generators in creating complex organic shapes. But it naturally feels like code will eventually eat all 3D, as LLMs are getting better and better at spatial coding. Industries most disrupted will be industrial design, game development, simulations and AR/VR/XR. submitted by /u/mhb_11 [link] [留言]

As the title says, we haven't seen any like ACL provided. Very salty about the decision, as AC recommended findings and the reviewers tanked our paper intentionally (we flagged them, and AC acknowledged that). Just want to see if the decision was made based on poor reviewer scores, as we don't know if we need to resubmit to an ARR cycle to cleanse or not. submitted by /u/Massive-Bobcat-5363 [link] [留言]

This is a Plain English Papers summary of a research paper called OpenART Red-Teams Stateful Agents Across 10,000 Evolving Environment Scenarios . If you like these kinds of analyses, you can find more AI and machine-learning research on AIModels.fyi or follow us on Twitter . OpenART turns persistent state into the red-team target OpenART evaluates agent safety across more than 10,000 validated stateful scenarios spanning 50 domains and requiring a median of 97 tool calls. Its central claim is that safety failures can emerge from trajectories in which workspace data, permissions, memory, and plans are repeatedly modified, rather than from isolated prompts alone. The arena keeps each benign task objective and hidden safety contract fixed while changing only the target-visible environment state. This design targets delayed failures that static benchmarks can miss: an early authorized mutation may influence later decisions, expose protected resources, or produce unsafe output many steps after the original change. OpenART extends the broader idea of agent safety evaluation by making persistent environment state the object that evolves during testing. OpenART reports a pooled strict Attack Success Rate of 85.0% across 75 agent-model configurations. Strict success requires both the deterministic evaluator and a GLM-5.2 judge to identify the attack condition, so disagreements count as failures rather than being treated as partial evidence.... Continue reading the full paper summary on AIModels.fyi →

This is a Plain English Papers summary of a research paper called RA-Bench Reveals Why Crisis-Video Deepfake Detectors Fail Across Generators and Social Media . If you like these kinds of analyses, you can find more AI and machine-learning research on AIModels.fyi or follow us on Twitter . The crisis detection problem we've been getting wrong Video synthesis has reached an inflection point. Recent generators can fabricate realistic depictions of wars, natural disasters, infrastructure failures, and public emergencies so convincingly that they fool both people and current detection systems. The threat isn't hypothetical anymore. A fabricated video of a nuclear plant explosion, a hospital collapse during an earthquake, or a terrorist attack could trigger panic, military response, or severe economic disruption within hours. Yet here's the troubling part: we don't actually know if our best detection tools can handle these high-stakes scenarios in the wild. Researchers have built impressive deepfake detectors, trained them on standard benchmarks, and measured their performance. But those benchmarks test detectors against generic synthetic videos, not against the specific threat that actually matters: AI-generated crisis footage designed to fool people about real things that happened. It's like training a border guard to spot counterfeit passports in a lab with perfect lighting and a magnifying glass, then sending them to a busy airport where they have to make decisions in three seconds. The guard's failure has nothing to do with their skill. The problem is that the testing environment was completely divorced from the real scenario.... Continue reading the full paper summary on AIModels.fyi →

This is a Plain English Papers summary of a research paper called Macaron-V1: Continual Learning with Self-Improvement and Mixture-of-LoRA Adapters . If you like these kinds of analyses, you can find more research on AIModels.fyi or follow us on Twitter . The problem with frozen models Most AI systems today follow a familiar pattern: train, evaluate, deploy, and then stop. The model is locked at that moment, treated as a finished product rather than a living system. But the real world immediately begins to diverge from training data. Users interact with the system in ways the training process never anticipated. New domains emerge. Preferences shift. The model that seemed smart on test day becomes gradually less relevant over time. This frozen-in-place approach isn't accidental. It reflects how machine learning has been practiced for decades. Retraining is expensive. Deploying new versions carries risk. The infrastructure to continuously improve systems in production barely exists. So instead, teams ship a model and move on, accepting that it will decay slowly but inevitably. Macaron-V1 asks a different question: what if AI systems could continuously improve themselves through real-world experience, learning from the billions of interactions that happen after deployment? Not in theory, but actually, in production, with users. The answer isn't magic. It requires two architectural shifts. First, treat deployment as the beginning of a learning process, not the end of one. Build versioning, evaluation contracts, and feedback loops directly into the system. Second, stop assuming you need to retrain your entire model. Instead, freeze a stable base and compose lightweight specialist adapters around it, allowing the system to grow in capability without losing its foundation. Rethinking deployment as a continuous learning opportunity The insight here is architectural. Instead of viewing the deployed model as the final form, Macaron-V1 treats it as the first link in an infinit

This is a Plain English Papers summary of a research paper called BDH-CQ Uses Recurrent Latent Reasoning to Cut ARC-AGI Inference Costs . If you like these kinds of analyses, you can find more research on AIModels.fyi or follow us on Twitter . The cost-accuracy trap in visual reasoning Large language models are fundamentally mismatched for visual reasoning tasks. They're forced to describe every thought out loud, generating token after token to explain their logic. This verbosity taxes compute budgets, yet paradoxically doesn't improve performance. Ask a language model to solve an ARC-AGI puzzle (a visual reasoning benchmark designed to test abstract thinking), and it either struggles despite the verbosity or succeeds expensively. The root problem runs deeper than just inference cost: the model learns from demonstrations by parsing them as language tokens, which is an indirect and inefficient way to absorb a visual pattern. The efficiency frontier has been unforgiving. If you want cheap inference, you sacrifice accuracy. If you want accuracy, you sacrifice cost. Every model on the leaderboard until recently clustered into one of two camps, and no one had found a path that broke the tradeoff. BDH-CQ challenges this assumption by proposing something radical: reasoning doesn't need to be visible to work. The model absorbs demonstrations silently into its internal memory state, then solves problems through private iteration in hidden layers, without generating a single token of intermediate reasoning. A 150-parameter variant achieves 29.5% pass@2 on the ARC-AGI-1 benchmark at a computed cost of just $0.0007 per task, puncturing through the previous Pareto frontier and establishing a new state of the art in cost efficiency. Learning through hidden states The core insight is deceptively simple: a model's reasoning process doesn't need to match human communication. When you learn a new skill from examples, you don't narrate every observation. You absorb patterns directly i

This is a Plain English Papers summary of a research paper called How Cross-Model Compatibility Lets Attackers Extract Proprietary LLM Reasoning Traces . If you like these kinds of analyses, you can find more research on AIModels.fyi or follow us on Twitter . The illusion of safety Major AI companies now show users their models' step-by-step reasoning as a feature. OpenAI offers it through o1, Anthropic through extended thinking, Google through its reasoning-focused variants. But this reasoning is a double-edged sword. It's intellectually valuable to share, showing users why a model reached a conclusion. But it's also intellectually valuable to steal. Competitors want to understand how frontier models think. Researchers want to study their reasoning patterns. Attackers want to extract proprietary algorithms. So the companies made a choice: hide the reasoning from users by encrypting it. The idea sounds straightforward enough. Return the reasoning to the user's device in an encrypted, unreadable form. The user can't see it, competitors can't see it, but they can pass it back to the server in future requests if they need continuity with previous reasoning. The server alone holds the decryption keys. Problem solved. Except it wasn't. Researchers discovered that this encryption doesn't actually hide reasoning. It just makes it look hidden. The encrypted blocks are designed to work everywhere within a company's ecosystem, across different sessions and different models. That universal compatibility is a feature for convenience. But it's also an architectural vulnerability that anyone can exploit. The architectural gamble To understand where this went wrong, you need to see how the system actually works. When a user sends a request to a frontier model like GPT-4, the model internally generates a reasoning trace, the raw thought process behind its answer. Instead of returning this reasoning in plaintext, the company encrypts it on the server before sending it to the client.

after 3 months and $800 burned... Unbounded Labs is proud to introduce Bart, our vintage LLM: 2.82B parameters trained from scratch on 20.1B tokens of English written before 1931. You can talk to it right now! Demo: https://www.unboundedlab.com/chat/bartholomew Article: https://www.unboundedlab.com/blog/bartholomew Huggingface: https://huggingface.co/jbduran/bartholomew-sft Why even make a vintage llm? As proposed by Demis Hassabis, could LLMs reach the same conclusions that the great scientists of the past did? While General Relativity was out of budget, we believe that advancing this field targets the crux of AI research. Are these models capable of original ideas, or are they just spitting out the next token? The article is our full account, covering where the corpus came from and how we cleaned it, the benchmarks we had to build because none existed, every ablation, the training runs, the post-training, and the mistakes we made along the way. "What I cannot create, I do not understand" is a quote I love from Richard Feynman. Building Bart was our attempt to actually understand LLMs rather than read about them. What we are proudest of: - Best vintage base model at its scale on Vintage CORE, ahead of GPT-1900 on a smaller token budget - Cleaned one of the largest vintage datasets, Harvard's Institutional Books (242B->23B tokens) - Created Vintage CORE, the first suite of 20 benchmarks made for vintage llms - Ran 10 hours of autonomous research on one H100: 100 experiments, 26 improvements found - Released the largest vintage SFT dataset we know of: 416k graded question and answer pairs, grounded in pre-1930s text - Trained the final model in 5 days on an H100, holding 60% MFU the whole way - All datasets, methodology, training code, evals, and training runs are open sourced I am proud of my team. What we built will move the vintage LLM field forward, and it moved us forward as researchers and as people. We paid for all of it ourselves, about $807 so far. Money is

Hello, As the title says submitted by /u/obliviousphoenix2003 [link] [留言]

Standard constrained RL assumes consequences are immediate and attributable to the current action. This breaks down whenever violations are delayed and stochastic, which is most real-world settings you end up penalizing whatever action happened to precede the observed violation, not the action that caused it. Working on CCPL (Causal Consequence-Penalized Learning) to address this: - A delay-corrected Bellman operator using an adaptive effective discount learned from the consequence-delay distribution. Contraction proof holds under unknown stochastic delay. - An Interventional Consequence Net (ICN), pretrained on structural-causal-model labels, estimating marginal causal contribution per action for attribution rather than penalizing based on temporal proximity. Limitations, to be upfront about them: - The ICN currently requires access to the environment's structural causal model to generate pretraining labels it's not learned end-to-end from observational or interventional data alone. That's a real constraint on applicability outside benchmark settings where the SCM is known or can be reasonably specified. Open to contributions and collaborators, especially if you work in constrained/safe RL or causal inference feel free to open an issue or reach out directly. submitted by /u/No_Cauliflower7923 [link] [留言]

In one test clip, the auto subtitles looked almost perfect. Then one auto subtitle showed gp where the speaker had actually said HP . It was one token in a long transcript, and that was exactly the problem: nothing in the editor made it look more dangerous than the clean words around it. Disclosure: AI helped me edit and structure this article. The gp / HP mistake came from my own build, and I checked the technical details against the code and the working editor. I ran into this while building a subtitle editor. The ASR system already returned word-level timing and confidence values, but a polished block of text made every word look equally trustworthy. The model exposed uncertainty; the interface hid it. That led me to a narrower engineering conclusion: Auto subtitles are drafts. An accuracy score describes a model result; it does not define a finished review workflow. Why auto subtitles need more than one accuracy percentage Speech-to-text systems are often evaluated with word error rate , or WER. In its simplest form: WER = (substitutions + deletions + insertions) / reference words That is useful for comparing transcripts against a known reference. For auto subtitles, trouble starts when a model-level metric is turned into a product-level promise. Suppose a 100-word transcript contains one wrong word. Its word accuracy may look excellent. But a single auto subtitle can carry very different consequences: Changing “and” to “an” may be harmless. Changing a person’s name damages trust. Changing 15 to 50 changes the meaning. Changing HP to gp made my test caption look careless. Dropping “not” reverses the sentence. WER counts errors. It does not price their consequences. Good auto subtitles also depend on things that a transcript-only score does not fully describe: whether words appear at the right time; whether cue boundaries follow the sentence; whether a line is readable before it disappears; whether punctuation helps or hurts comprehension; whether the user knows

The shifts that actually matter for builders - late May to mid-August 2026 The last three months did not produce a single "GPT-5 moment." There was no single release that reset the conversation the way earlier step-changes once did. Instead, the ground moved in several places at once: a wave of frontier and open-weight model launches in July, growing candor about how badly long-context windows actually hold up, and a genuinely uncomfortable security story out of xAI's new agent product. Here's the short, opinionated version of what actually changed for people who ship AI systems. 1. Models & Capability GPT-5.6 (OpenAI) shipped in three tiers - Sol, Terra, and Luna after a government review, with the fastest tier reportedly hitting 750 tokens/sec on Cerebras hardware and a new "Ultra" mode for maximum reasoning effort. Anthropic's lineup grew fast: Opus 5 landed at unchanged Opus pricing ($5/$25 per million tokens), reportedly within half a point of a rival's benchmark peak at half the per-task cost, alongside a new Sonnet 5 and a higher "Fable 5" tier. xAI iterated twice: July's Grok 4.5 (1.5T parameters, trained partly on coding-agent interaction data) was followed by Grok 4.6 on August 12 - a 500K-token-context model aimed at coding and long-running agents, priced at $2/$6 per million tokens standard and $4/$12 for long-context requests. Google's Gemini Flash line saw three releases in quick succession - 3.5, 3.6, and then 3.7 Flash - each undercutting the last on price. 3.6 Flash alone cut output pricing from $9.00 to $7.50 per million tokens. Open-weight competition intensified: Kimi K3 (Moonshot) became the largest open release yet at 2.8T parameters (104B active via MoE) with a 1M-token window, and it was joined by DeepSeek V4-Pro, the Qwen3.8 series, and GLM-5.3 - plus Inkling (Thinking Machines), a 975B open-weight MoE trained on 45 trillion multimodal tokens. One-line interpretation: The capability ceiling is still rising, but the more interesting number th

Recently, the AAAI 2027 organizers sent an email regarding collusion occurring during the review process, especially in the 2-cycles category (i.e., an author of Paper A reviews Paper B, while an author of Paper B reviews Paper A). Given the fact that most submissions come from a single country, there are higher chances that the assignment algorithm will naturally create 2-cycles among authors from that country. This, in turn, means that most authors involved in collusion could be from that country. I will not name that country; otherwise, I would be labelled as racist. By the way, did AAAI release statistics about the number of submissions, like they did last time? It is also good news that a major and prestigious conference like AAAI is acknowledging that collusion is happening. We all knew that this kind of collusion had been happening for years. There are papers accepted at top conferences such as NeurIPS, ICLR, AAAI, and ICML that do not even have their code published on GitHub. This forces other researchers in the community to spend substantial time reimplementing the code themselves if they want to reproduce the reported results. What are the views of other authors on this? submitted by /u/Fragrant_Fan_6751 [link] [留言]

Does anyone know how the BMVC to IJCV special issue recommendation works? Is it mainly based on the review scores, or is it a separate decision by the ACs/program chairs (e.g. based on oral/highlight selection, reviewer comments, etc.)? Also, is there any way to know at this point whether a paper has been recommended for the IJCV track, or do authors only find out later through a separate email? Would be great to hear from anyone who has gone through this in previous years! submitted by /u/Secondhanded_PhD [link] [留言]

This is a simplified guide to an AI model called Beat_this maintained by Xavriley . If you like these kinds of analysis, you should join AImodels.fyi or follow us on Twitter . Overview beat_this is a beat and downbeat tracking model from the ISMIR 2024 paper "Beat This! Accurate Beat Tracking Without DBN Postprocessing" by xavriley and collaborators at CPJKU. The model detects precise beat positions and downbeat boundaries in audio files without relying on Dynamic Bayesian Network postprocessing, achieving state-of-the-art F1 scores while maintaining generality across diverse music genres. The architecture alternates convolutions with transformers operating either over frequency or time dimensions, and is trained on multiple datasets including solo instruments, pieces with time signature changes, and classical music with high tempo variations. The main model ( final0 , final1 , final2 ) weighs approximately 78 MB each, with a smaller variant available at 8.1 MB. The most critical detail before using it: the model achieves good results specifically because it avoids meter and tempo constraints that traditional systems impose, but this means it can still fail on difficult and underrepresented genres and performs worse on continuity metrics compared to methods using postprocessing. Best use cases Music information retrieval and analysis workflows. If you build music analysis software that needs to segment tracks into beat-aligned sections for tempo detection, structural analysis, or synchronization with other modalities, beat_this provides clean beat and downbeat annotations without requiring external postprocessing pipelines. The model outputs precise timestamps suitable for downstream music information retrieval tasks like onset detection or harmonic analysis. Rhythm-aware music production tools. For digital audio workstations, beat detection plugins, or metronome applications, this model provides frame-level accuracy suitable for real-time audio alignment and grid s

La forma del problema Un directorio es una superficie: el miembro lo abre y adivina. Un recomendador es una superficie de empujar: el sistema propone y tiene que justificarse. La justificación es la parte difícil, y es donde vive la estadística. Tres restricciones hicieron esto distinto de un recomendador de contenido: El item es una persona con capacidad finita. Un hilo se le puede recomendar a diez mil personas. Un experto no. Una mala recomendación es cara de los dos lados. Quien pide desperdicia una petición, el experto desperdicia una hora, y los dos aprenden a ignorar la superficie. La afirmación tiene que ser checable. "Quizá te guste este hilo" no necesita evidencia. "Esta persona está un nivel adelante de ti en diseño de sistemas" sí. Recuperación: híbrida, fusionada con RRF Tres recuperadores independientes sobre el conjunto de expertos elegibles, fusionados con Reciprocal Rank Fusion: def rrf_fuse ( * ranked_lists , k = 60 ): """ Fusiona listas de ids rankeadas. El score depende solo del rank, nunca de la escala propia del recuperador, que es el punto: la similitud coseno y un conteo de hilos resueltos no son números comparables. """ fused = {} for lst in ranked_lists : for rank , key in enumerate ( lst ): fused [ key ] = fused . get ( key , 0.0 ) + 1.0 / ( k + rank ) return fused RRF es la primitiva correcta aquí por una razón que vale la pena decir: los recuperadores emiten cantidades incomparables. Uno regresa un coseno en [-1, 1] , uno regresa un conteo entero de hilos resueltos, uno regresa un delta de nivel de escalera. Normalizarlos a una escala común requiere supuestos sobre sus distribuciones que nadie tiene a este volumen de datos. RRF descarta las magnitudes y se queda solo con el orden, que es exactamente la información que sobrevive a una muestra chica. k = 60 es la constante estándar de la formulación original de Cormack et al. Aplana la cabeza: la diferencia entre el rank 1 y el rank 2 es 1/61 - 1/62 ≈ 0.00026 , así que un recuperador no pu