标签：#learn

Mithil Vakde trained a small transformer from scratch in 1.5 hours on a rented RTX 5090. The compute cost came to about 67 cents. The model scored 44% on the ARC-AGI-1 public eval, one point behind TRM's 45% and in the same band that left DeepSeek R1, o3-mini, and Gemini 2.5 Pro behind when the TRM paper ran the comparison ( arXiv 2510.04871 ). This is the third post in his ARC series. The previous result went viral and drew public scrutiny from researchers including Lucas Beyer, Jeremy Howard, and Rohan Anil. The new one raises the score, cuts the cost, and answers every objection in a long appendix. What the model does Each puzzle becomes a sequence of tokenized grids. The transformer trains on those sequences from scratch at test time, using both the train puzzles and the eval puzzle inputs, with the eval labels hidden. Test-time training is not a loophole here. ARC is a meta-learning benchmark built around skill acquisition, and Chollet's original paper frames the whole thing as a measure of how efficiently a system gains new skills ( arXiv 1911.01547 ). The architecture got a 2026 refresh: 8 layers, SwiGLU, RMSNorm, the NorMuon optimizer, 3D RoPE, and per-task embeddings. Inference augments each test input with color and dihedral permutations, inverts the augmentations, and submits the two most common outputs. The biggest change is the loss function. Previous versions trained on input and output tokens. This one trains on output tokens only, which makes the approach supervised. Score went from 40% to 44%. Vakde admits he does not fully understand why, and the training loss got worse even as scores improved. His guess is finite model capacity. The ablations back him up on what carries the result: drop the 3D RoPE and the score falls to about 24%, drop the per-task embeddings and it falls to about 24%. Representations, not compute, are doing the work. The lineage it joins None of these systems pretrain. They learn from the benchmark's roughly thousand examples: S

Why did I sign up to review when it’s not reciprocal? Am I an idiot? Am I dumb to sacrifice some of my precious time outside of work to review these papers when I don’t even have to? Yes. I tell myself I’m giving something to the community. But all I’m really doing is pissing off the authors as I reject their papers. I really wanted to accept one of them too. But, it wasn’t as well done as I’d hoped. Strong reject. Nobody made me sign up. Nobody even asked me personally. They sent a lovely form email that goes to everyone who’s published there. I let feeling important convince me to do it. How dumb of me! At least it’s only a couple of papers and a small amount of my time. And I’m learning something new reading stuff slightly outside my direct field, that I would never normally read otherwise. And I get to hone the skill of critical reading, thinking, and generally understanding how a paper should (or should not) be put together. Maybe it was a good idea after all. How does everyone else feel about non-reciprocal reviewing? I imagine those that agree to do it are in the minority. submitted by /u/OptimalOptimizer [link] [留言]

Please post your personal projects, startups, product placements, collaboration needs, blogs etc. Please mention the payment and pricing requirements for products and services. Please do not post link shorteners, link aggregator websites , or auto-subscribe links. -- Any abuse of trust will lead to bans. Encourage others who create new posts for questions to post here instead! Thread will stay alive until next one so keep posting after the date in the title. -- Meta: This is an experiment. If the community doesnt like this, we will cancel it. This is to encourage those in the community to promote their work by not spamming the main threads. submitted by /u/AutoModerator [link] [留言]

If you approach generative models as ""networks that create images,"" the field quickly turns into a collection of disconnected architectures. A more useful developer mental model starts one level lower: What probability structure could have produced the data, and how can we represent, learn, and infer that structure without making the computation impossible? That question connects autoregressive models, VAEs, flow-based models, GANs, and diffusion models. Their architectures look very different, but they all respond to the same underlying tension: high-dimensional data distributions are difficult to represent, learn, normalize, sample from, and reason about. Generative modeling can therefore be organized around three interacting problems: Representation: How do we represent a complex high-dimensional joint distribution? Learning: How do we make the model distribution approach the data distribution? Inference: Given an observation, how do we reason backward about hidden variables or the process that generated it? Once these three pieces are connected, the major families of deep generative models become much easier to understand. From prediction to distribution learning A discriminative model usually begins with a prediction problem. Given an input x , predict the most likely output y : f ( x ) = y ar g max ​ p ( y ∣ x ) The model focuses directly on the conditional relationship required for prediction. A generative model asks a broader question. Instead of learning only the path from x to y , it models the probability structure from which the data arises. For class-conditional modeling, for example, we can model p ( x ∣ y ) together with the prior p ( y ) and recover the posterior using Bayes' rule: p ( y ∣ x ) = p ( x ) p ( x ∣ y ) p ( y ) ​ In unsupervised generative modeling, the target becomes the data distribution itself. We assume the training samples come from some unknown distribution: x 1 ​ , x 2 ​ , … , x N ​ ∼ i.i.d. p data ​ ( x ) The model then construc

Originally published on tamiz.pro . We have collectively lost our minds over benchmarks. AgenticBench scores 90%? Great. Multi-Agent Hallucination Leaderboard rank #1? Impressive. Yet the moment you ship that same agent to a chaotic production environment with 14,000 SQL dialects, flaky APIs, and users who refuse to follow instructions, it collapses within hours. This is not a bug. It is a feature of how we evaluate these systems. The gap between benchmark performance and production reliability is the single most dangerous illusion in current AI engineering. Benchmarks measure capability ; production measures consequence . If you are building AI agents today, you are likely flying blind. Here is why your evaluation strategy is lying to you, and what actually happens when agents hit the wire. The Snapshot Fallacy Benchmarks are snapshots. They are static, curated, and deterministic. An agent tasked with answering a question from Wikipedia is doing retrieval and generation. In production, that same agent might be triggering a refund API while concurrently writing to a database. The problem is that benchmarks rarely account for statefulness . A chatbot that generates a perfect summary is qualitatively different from an agent that executes a five-step workflow where Step 3 depends on the output of Step 1, which was corrupted by a non-deterministic tool response in Step 2. Benchmarks usually test the trajectory in isolation. They do not test the persistence of the state across 10,000 concurrent requests. When you move from benchmark to production, you introduce temporal decay . The model context window fills. Tool schemas drift because the upstream API changed yesterday. Database schemas evolve. The agent you tested in January is functionally a different entity in June, yet your evaluation suite remains frozen in time. The Tooling Cliff The most common failure mode in production agents is not hallucination—it is tool failure . In a benchmark, if you ask an LLM to get_wea

Spent the past week wiring up CI and tightening a few decisions on a backend project. Nothing dramatic happened, but a few things stood out enough to write down. CI is worth setting up early, even on a solo project. First run caught a dependency that worked locally but was never actually declared in requirements.txt . Classic "works on my machine" gap. CI doesn't care what your machine has installed, only what the project actually declares, and that mismatch is exactly the kind of thing that's invisible until something forces the comparison. Pinned dependencies drift more easily than people expect. I had a specific package version pinned for a known compatibility issue, and a later, unrelated install silently bumped it past that pin. Caught it by chance during a review, not because anything alerted me. Worth adding an explicit check for that instead of relying on remembering. 404 over 403 for resources that belong to another user is a small choice with real weight. 403 confirms something exists and you're just not allowed to see it. 404 gives nothing away. Costs a bit of clarity for legitimate callers debugging their own mistakes, but that's a fair trade for not leaking what exists in the system. None of this is complicated. All of it is easy to miss quietly, and only shows up if something is actually checking. That's most of what good backend hygiene turns out to be.

LLM agents increasingly modify their own prompts, tools, middleware, resources, and execution harnesses at runtime. Such self-evolution can improve capability, but a successful mutation may leave persistent effects that cannot be safely reversed in states different from the one in which it was created. We introduce EvoUndo, a framework for representing, synthesizing, diagnosing, and independently verifying recoverability of model-generated self-modifications across counterfactual states. Across 600 unseen one-shot self-evolution tasks, we identify 197 capability-improving mutations that fail recoverability verification. Under the original recovery representation, conventional repair strategies recover 0/197 of these natural failures. Deterministic oracle analysis recovers 48/197 under the original recovery language L0, while the extended recovery calculus increases empirical oracle recovery to 191/197. A protocol-locked 2×2 grounding-by-expressivity intervention then separates two bottlenecks: exact state-address grounding increases successful recovery from 0/48 to 38/48 (79.2%) when the original language is sufficient, while extending the recovery language enables recovery on 142/143 (99.3%) failures in the oracle-defined S1 stratum. On the primary gpt-oss-120b backbone, adding exact-address diagnostics to the richer language reduces recovery to 133/143 (93.0%); a Qwen3.8-27B replication preserves the grounding and expressivity effects but not this negative interaction, indicating that the latter is model-dependent. These results indicate that reliable agent self-evolution requires co-designing verification, state grounding, witness semantics, and recovery-language expressivity rather than relying on iterative prompting alone. Paper: https://arxiv.org/abs/2608.28363 submitted by /u/AccomplishedLeg1508 [link] [留言]

Hi everyone, 2nd-year PhD candidate here staring down my first A* submission deadline (AAMAS 2027). I could really use some perspective on theory expectations, especially since I think I’ve methodologically painted myself into a corner. The setup My project started with a clean hypothesis: if architecture X is more robust than Y to perturbation A, and B is a strictly harder version of A, then the X > Y ordering should hold under B as well. I isolated three variables I suspected were driving the effect, ran experiments, and… got results that only partially support the hypothesis, with clear boundary conditions. Where I got stuck Trying to explain the “why” mathematically sent me down a theory rabbit hole. I ended up with two bad options: Claims tied to specific training outputs rather than structural/architectural properties, or Weak, hand-wavy speculations that feel like post-hoc rationalizations. I’m pretty sure I fell into HARKing.. I started building theory after seeing the results instead of deriving predictions beforehand. Furthermore, my codebase is built on an undocumented public repo, and I recently found a bunch of hidden parameters set to wrong values for my setting. I’m currently re-running everything, which is why I’m being vague about specifics. My “insights” from the first round are probably garbage. My actual questions For those who’ve reviewed for or published at AAMAS (or similar A* venues): how much formal theory is actually expected for an empirical MARL paper? Is “here’s the phenomenon, here’s the controlled experiments, here’s a plausible but incomplete theoretical sketch” a death sentence? If the theory ends up being training-dependent rather than structural, is that a sign I should pivot to a lower-tier venue, or can strong empirical characterization + limited theory still fly at A*? How do you recover from HARKing mid-project when you’re under pressure to publish in year 3/4 of a 4-year contract? Any advice on how to salvage the timeline or r

This article provides a step by step comparison of three Gemma 4 deployments on a single AWS hosted GPU enabled system. A suite of Python MCP tools is built to simplify management of each deployment, and one benchmark harness is shared across all three so that the runtime is the only variable. https://github.com/xbill9/gemma4-dev The whole exercise cost under three dollars, and that is the part worth keeping. Nineteen instances and about four and a half instance-hours bought three serving sweeps, nine timed boots and a handful of A/B restarts. It also bought five wrong claims, each caught by measuring instead of reasoning. On hardware where a run is expensive, the cheapest of those five would have shipped with a caveat attached. What is this project trying to Do? Three rigs in this monorepo serve google/gemma-4-E2B-it on an AWS G5g instance. One runs vLLM, one runs a pure JAX port, one runs PyTorch with transformers. The hardware is identical and only the runtime slot moves, so this should be the cleanest A/B available. For months it was not, because each rig measured itself with its own harness and quoted its own number. Three harnesses computing three statistics is not a comparison. Prerequisites An AWS account with G-family quota in us-east-1 . Each g5g.2xlarge is 8 vCPU, so 16 vCPU of spot quota runs two at once. A subnet, a security group opening TCP 8000, and an instance profile carrying AmazonSSMManagedInstanceCore plus read on the Hugging Face token secret. A Hugging Face token in Secrets Manager. It is fetched at boot into a root-only EnvironmentFile and never appears in user data. boto3 and the standard credential chain. No AWS CLI shell-outs, no inbound SSH rule, and no private key anywhere in the flow. AWS EC2 G5g Instance g5g.2xlarge — 8 vCPU, 16 GiB host Host CPU AWS Graviton2, aarch64 GPU 1x NVIDIA T4G, Turing, SM 7.5 GPU memory 15,360 MiB per nvidia-smi ; AWS lists 16,384 nominal G5g is the only family AWS ships that puts an NVIDIA GPU behind a Gravi

This article provides a step by step comparison of three Gemma 4 deployments on a single AWS hosted GPU enabled system. A suite of Python MCP tools is built to simplify management of each deployment, and one benchmark harness is shared across all three so that the runtime is the only variable. https://github.com/xbill9/gemma4-dev The whole exercise cost under three dollars, and that is the part worth keeping. Nineteen instances and about four and a half instance-hours bought three serving sweeps, nine timed boots and a handful of A/B restarts. It also bought five wrong claims, each caught by measuring instead of reasoning. On hardware where a run is expensive, the cheapest of those five would have shipped with a caveat attached. What is this project trying to Do? Three rigs in this monorepo serve google/gemma-4-E2B-it on an AWS G5g instance. One runs vLLM, one runs a pure JAX port, one runs PyTorch with transformers. The hardware is identical and only the runtime slot moves, so this should be the cleanest A/B available. For months it was not, because each rig measured itself with its own harness and quoted its own number. Three harnesses computing three statistics is not a comparison. Prerequisites An AWS account with G-family quota in us-east-1 . Each g5g.2xlarge is 8 vCPU, so 16 vCPU of spot quota runs two at once. A subnet, a security group opening TCP 8000, and an instance profile carrying AmazonSSMManagedInstanceCore plus read on the Hugging Face token secret. A Hugging Face token in Secrets Manager. It is fetched at boot into a root-only EnvironmentFile and never appears in user data. boto3 and the standard credential chain. No AWS CLI shell-outs, no inbound SSH rule, and no private key anywhere in the flow. AWS EC2 G5g Instance g5g.2xlarge — 8 vCPU, 16 GiB host Host CPU AWS Graviton2, aarch64 GPU 1x NVIDIA T4G, Turing, SM 7.5 GPU memory 15,360 MiB per nvidia-smi ; AWS lists 16,384 nominal G5g is the only family AWS ships that puts an NVIDIA GPU behind a Gravi

Fixing the “D.map is not a function” crash by tightening DB indexes and normalizing the API payload TL;DR: I added missing PostgreSQL indexes in apps/api/src/db/db.ts and forced the /condos/metrics endpoint to always return an array. The change stopped the runtime TypeError: D.map is not a function in the React selector and restored correct KPI calculations. The Problem Our internal “Condo Dashboard” started throwing a JavaScript error in production: TypeError: D.map is not a function at render (src/components/CondoSelector.tsx:45) at D.map(e=>(0,a.jsx)("option",{value:e.id,children:e.name},e.id)) D is the data array used to populate a <select> with condo options. When the page loaded, the dropdown was empty and the whole component crashed. The API call that feeds D ( GET /api/condos/metrics ) was supposed to return an array of objects { id, name } , but under certain conditions it returned null or a single object, breaking the .map call. The root cause turned out to be duplicate rows in the broker_tokens table that caused the query to return a malformed result set. Those duplicates were a side‑effect of missing unique indexes on the broker_tokens and condo_metrics tables. What I Tried First Guarding the Front‑end – I added a quick check in CondoSelector.tsx : const options = Array . isArray ( data ) ? data : []; This silenced the error, but the UI still showed no options because the API kept returning the wrong shape. It was a band‑aid, not a fix. Manual Data Normalization – In the API controller I forced the result to an array: const rows = await db . query ( sql ); return res . json ( Array . isArray ( rows ) ? rows : [ rows ]); This produced duplicate entries and confused downstream calculations. The KPI numbers in the dashboard were still off. Both approaches addressed the symptom but left the database inconsistency untouched, so the bug could re‑appear anytime new data landed. The Implementation 1. Add proper indexes (the real fix) The missing indexes allowed

YOLO26 ships a depth-estimation model — dense, full-resolution, per-pixel regression, a task architecturally much closer to image restoration than to detection. I wanted to know whether the backbone+neck weights it learns through depth training transfer to a different dense-regression task (deraining), compared with training the same architecture from scratch. The deraining model that came out of it is a useful byproduct, but the transfer result is the part I think is worth discussing. What I inherited from YOLO26-depth The CSPDarknet backbone and PAN-FPN neck, unchanged. The depth decoder's multi-scale fusion (project the P3/P4/P5 pyramid to a common width, progressively upsample-and-add P5→P4→P3). That part isn't depth-specific — it's just feature fusion — so RGBHead reuses it. What I changed / added Replaced the 1-channel Depth head with a new RGBHead . The config change is one line; RGBHead itself is a new restoration decoder, not a re-pointed depth head. Reconstruction tail that continues to full input resolution (deraining needs pixel-exact output; depth stops at 1/4 res). Skip connections from the stride-2 and stride-4 backbone layers into the tail, so fine detail has a path that doesn't route through an 8×-downsampled bottleneck. Residual output — the head predicts a correction added to the input (NAFNet/Restormer-style), not the image directly. LayerNorm in the head's own conv blocks; the backbone and neck stay on BatchNorm (folds into conv at TensorRT export, and keeps the model loadable from the whole YOLO26 pretrained zoo, not just the depth checkpoint). How it was trained and measured ClearView as an external lib — its mixed synthetic+real rain recipe, Charbonnier loss, and 10-test-set protocol — so the numbers land on ClearView's own model-zoo scale, not a benchmark I made up. Released scales: nano (5.25M) and small (12.13M). Loading the YOLO26-depth checkpoint into this architecture matches 468/468 backbone+neck tensors exactly — only the new RGBHead

After following various arXiv papers and researcher discussions on X/bluesky about latent reasoning and continual learning, one idea which resonates strongly is that path forward (towards AGI) may depend less on generating ever-longer chains of thought and more on finding architectures that can reason beyond the token stream. LLMs routinely reach correct answers through flawed or fabricated CoT steps, and produce perfectly logical steps that end in wrong answers (Kambhampati, 2025). The trace doesn't track the computation which clarifies that verbalized CoT is an imitation of reasoning and not the mechanism itself. The alternative mechanism which gets the most attention is latent reasoning: instead of verbalizing every intermediate result, the model repeatedly transforms its continuous hidden state and decodes only the answer. I’m breaking latent reasoning down into at least five distinct families: Continuous thoughts in autoregressive LMs: Coconut (Hao et al., 2024) feeds the model's own final hidden state back in as the next input embedding while Soft Thinking (Zhang et al., 2025) reasons in a continuous concept space. Theory here argues a single continuous state can hold several search frontiers at once and expand them in parallel (Zhu et al., 2025) . Compressed discrete non-linguistic tokens: Abstract-CoT (Ramji et al., 2026) swaps verbal rationales for a short sequence from a learned vocabulary. It is non-linguistic, but still serial and externally decoded, the discrete end of the spectrum . Recurrent depth and looped models: recurrent-depth LMs (Geiping et al., 2025) and looped Transformers (Saunshi et al., 2025; Zhu et al., 2026) reapply a shared block to a latent state. Mostly framed as parameter efficiency and test-time-compute scaling, not as a new reasoning interface . Task-trained recursive solvers: HRM (Wang et al., 2025) and TRM (Jolicoeur-Martineau, 2025) recursively refine latent and candidate-answer states. Their ARC pipelines are transductive: eval

The Brave Wanderer: I made Claude play a Pokémon it never read a guide for Full timeline video of this 2,000-turn run (game frames + a live cost counter on the left, the model's real-time thinking log on the right): https://youtu.be/ewyM7mzGzTM At the end of the first article in this series , I made a promise. Fable 5's fluency in FireRed owed half its credit to the walkthroughs it had memorized — it wrote down "Oak's Parcel," an item the game hadn't shown it yet, 141 turns early. So the only honest exam is a new exam paper: "Same harness, same model, a map it cannot recite — I'll post the numbers." This article is those numbers. The exam paper is Pokémon Team Rocket Edition — the Chinese fan translation of the Spanish community hack Pokémon Edición Team Rocket, released in January 2026. You play a Team Rocket recruit working your way up from the Five Island base. Five story rounds, four regions; the Kanto chapter alone is labeled 30-35 hours for a human player. And most importantly: this game is essentially absent from the model's training data . No guide to recite. Just the screen and itself. There's also a lovely narrative twist: the hack sets your home base inside the original FireRed's Five Island Rocket Warehouse — the enemy hideout you raid late-game as the hero in the official version. Same map, opposite allegiance. Rules unchanged: vision only, one screenshot plus its own notes per turn, one button-press tool, a 2,000-action cap. The result, up front 8 hours 43 minutes, 2,000 turns, $113.44. It reached the middle of the prologue's first mission — roughly 40-60 minutes of human play time. It taught itself plenty: menus, battles, catching, the save flow, all from scratch; after losing to a fellow recruit it wrote a revenge battle plan into its notes, ground levels, and actually won the rematch; it even induced map rules like "dark blue water can't be surfed, light blue can," and maintained a dead-ends list and an NPC-interview checklist in its notes. One deta

In this blog post, we will see how I use AI to speed up incident investigation without letting it take over the decisions that need a human. It is 3:00 AM. Your phone starts making that familiar PagerDuty noise. You open the alert with half-open eyes. Error rates are climbing. Slack is already active. The incident commander wants an update. Depending on the severity, your director or CTO may also join the call. Every developer who goes on call will face this situation at some point. I have faced it a few times a year. The first time, panic is normal. You do not know where to start, which dashboard to open, or how to explain the issue while you are still investigating it. Experience teaches you how to stay prepared. AI can reduce some of that early morning panic too. It will not bring the panic factor down to zero, and it should not replace the engineer. But it can remove the first few minutes of searching, tab switching, and collecting context. The goal is simple: move from panic mode to confidence mode faster. I Started With a Prompt in My Notes I started with something small, before custom skills became common in coding harnesses. I kept one incident prompt at the top of my notes folder. I also pinned it in my clipboard manager. When an alert arrived, I filled in the blanks and launched the investigation: I received this alert: <PagerDuty or Slack alert link>. Context: - Service: <service name> - Environment: <environment> - Region: <region> - Error or symptom: <error details> - Investigation window: past <n> hours - Runbook: <runbook link> Start investigating the issue. 1. Analyze the relevant Splunk logs and dashboards. 2. Check recent deployments, configuration changes, and feature-flag changes. 3. Check upstream and downstream dependencies. 4. Check cloud-provider status pages and internal maintenance announcements. 5. Search PagerDuty history and incident records for similar symptoms. 6. Use parallel agents for independent investigation tracks where useful. R

Please post your questions here instead of creating a new thread. Encourage others who create new posts for questions to post here instead! Thread will stay alive until next one so keep posting after the date in the title. Thanks to everyone for answering questions in the previous thread! submitted by /u/AutoModerator [link] [留言]

I used to think encryption was simple: take a password, use it as the key, done. Then I built a small encryption tool myself, and realized that's not how any of this works. This is the first post in a series where I'm documenting what I'm actually learning while building CryptoGraphy , a small Python project I'm using to study applied cryptography properly instead of just calling library functions and hoping they're right. My background is in SOC analysis and pentesting — I'm used to finding broken crypto, not building it. Writing this project is forcing me to understand the "why" behind the fixes I used to just recommend. The naive approach If you've never dug into how encryption actually works, this looks completely reasonable: AES . encrypt ( password , data ) Pass in a password, get encrypted data back. It reads clean. It "works" in the sense that it runs without errors. And it's wrong in a way that's easy to miss if nobody ever shows you why. Why it breaks AES doesn't take a password. It takes a key , and that key has to be an exact size — in my project, 256 bits (32 bytes). A password is neither of those things. It's variable-length, human-chosen, and (unless your users are unusually disciplined) low-entropy. If you pad or truncate a password to force it into 32 bytes, you haven't created a strong key — you've created a shortcut for an attacker. They don't need to break AES. They just need to guess the password, since the password is the key in disguise. This matters because passwords and keys have completely different jobs. A password needs to be memorable to a human. A key needs to be unpredictable to a computer. Treating them as interchangeable collapses two different security properties into one weak one. The fix: derive the key, don't reuse the password In crypto.py , the password never touches AES directly. It goes through a key derivation function first — specifically Argon2id: from argon2.low_level import hash_secret_raw , Type SALT_SIZE = 16 KEY_SIZE

Hey everyone, My brother and I just released TontaubeV1, a 2.9B-parameter open-weight TTS model focused on expressive speech, long-form generation/narration, and low-latency local inference. It is primarily aimed at English and German and supports zero-shot voice cloning from up to one minute of reference audio. It builds on DualCodec, a multi-codebook discrete audio codec. It was trained on 7 languages and ~200k hours of audio (mostly tested in English and German). I wanted to make a post to highlight two choices that worked well for us and seem less common in current TTS models: 1. Character-level tokenization We start from a Qwen3-1.7B checkpoint for our semantic codebook model. Many modern, and especially LLM-based, TTS models use the tokenizer from the backbone model, add special/audio tokens, and train the model on predicting the next token. We experimented early on with character-level tokenization and found that it generally worked better than using the original BPE tokenizer from Qwen. We still use the tokens emitted by the Qwen tokenizer, but force it to tokenize spoken text as a sequence of individual characters. When experimenting with forcing Qwen to predict text in this mode, we found that it was still able to answer questions correctly, which suggested to us that language understanding was retained even with this unusual representation. We did this because a) context length usually is not as much of an issue for TTS as it is for regular LLMs, since we do not require huge reasoning budgets and use chunking, and b) it makes the character-to-sound mapping much simpler internally. Speech is a lot about syllables and short character sequences. When using the regular BPE tokenizer, we found that the model went out of distribution more often and was more likely to encounter a sequence of tokens that was rare or absent from the TTS training data. Complex sequences of special characters can be particularly confusing because they may tokenize into combinations

I'm exploring Hidden Markov Models (HMMs) as a baseline method for "dataset exploration/discovery" where I have a bunch of unstructured data with no annotations, and wish to gain insights about the structure and semantics of the data within. I was wondering if there are more modern (deep learning based or otherwise) approaches which have completely superseded HMMs for such tasks. submitted by /u/fullgoopy_alchemist [link] [留言]

I own two laptops. A 2020 Intel MacBook Air, 8GB RAM, no unified memory, gifted by my sister. And a...