标签：#learn

Overview Hey everyone 👋 If you've ever wanted to experiment with Gemini models, build AI-powered features, or grab an API key without going through a complex setup, Google AI Studio is the tool you're looking for. It's free, it's browser-based, and it's probably the fastest way to go from "I have an idea" to "I have working code." Today I'll walk you through what it is, what you can actually do with it, and why it belongs in every developer's toolkit. Let's dive in! 🤙 What Is Google AI Studio? 🤔 Google AI Studio is a web-based platform where you can interact with Google's AI models, prototype ideas, fine-tune behavior, and export working code, all without writing a single line of infrastructure. Think of it as a sandbox. You can test prompts, switch between Gemini models, tweak parameters, and when something works, click "Get Code" to get a ready-to-use snippet in Python, JavaScript, or REST. No cloud setup, no billing configuration, no long onboarding. Just go to aistudio.google.com , sign in with your Google account, and you're in. It sits at the intersection of playground and development tool. Researchers use it to experiment. Developers use it to prototype. Teams use it to validate ideas before committing to a full integration. What You Actually Need It For 💡 There are a few scenarios where Google AI Studio becomes indispensable: Getting a Gemini API Key: This is often the first reason developers land on AI Studio. It's the official way to get a Gemini API key for free, which you then use in your own applications, in tools like Gemini CLI, Antigravity, or any custom integration. No credit card required for the free tier. Testing Prompts Before Hardcoding Them: Prompt engineering is trial and error. AI Studio gives you a fast feedback loop where you can iterate on prompts interactively, see the output, adjust, and repeat, before embedding anything in your codebase. Exploring Model Capabilities: Not sure if Gemini can handle your specific use case? Test it directl

Originally published at ayonbuilds.hashnode.dev I can't eat the food I want. I can't travel. I can't do the things my peers do. I'm a 2nd year CS student in Chandigarh. No connections. No money. No big university name behind me. Last week I was researching AI security tools and stumbled across a startup called Artemis . Founded in 2025. Just raised $70M . Building AI agents that automatically investigate security threats. I had just built something in the same category. From my room. With free tools. Zero budget. Simulated data. No users. No team. Not even close to what they've built. But I understood the problem well enough to build a working version of it myself. And that told me something. I'm not there yet. Not even close. But I'm working on the right problems at the right time — and I'm just getting started. Here's what I built — ARIA (Autonomous Risk Investigation Agent) . It detects suspicious authentication events in real time, maps them to MITRE ATT&CK threat techniques, and automatically generates plain-English incident reports using an LLM investigation chain. Built with FastAPI, React, PostgreSQL, and Groq API. GitHub: github.com/Ayon99/ARIA My name is Ayon. I'm building AI systems in public — the wins, the failures, the gap between what I make and what the funded teams make, and everything I'm learning along the way. I have one goal. Break through. Completely. Whatever it takes . If you're in a similar position — small city, limited resources, big ambition — follow along. I'm not going to pretend I've figured it out. But I'm going to document every step of figuring it out.

Since mid-March 2026, a significant chunk of Claude users have been hitting this error whenever Claude tries to render an inline diagram, chart, or interactive widget: Failed to set up MCP app for "visualize". Check that claudemcpcontent.com is not blocked by your network or browser. The instinct is to blame your network. I went through the same cycle — switched DNS to Cloudflare 1.1.1.1, tried Google 8.8.8.8, disabled browser extensions, tested across browsers. Nothing worked. Then I ran a direct DNS lookup: nslookup claudemcpcontent.com 1.1.1.1 Output: Server: 1.1.1.1 Address: 1.1.1.1# 53 *** Can't find claudemcpcontent.com: No answer Same result with 8.8.8.8. The domain doesn't resolve — at all, from any resolver. Not a user-side issue. What's Actually Happening Claude's visualize feature depends on an external domain — claudemcpcontent.com — to serve the MCP app that renders inline SVG/HTML widgets. When that domain goes down, the feature breaks silently with a misleading error that makes it look like a local network problem. There's an open GitHub issue tracking this (#34820 on anthropics/claude-code) filed March 16, 2026. It has 50+ affected users, no official fix, and was labeled invalid because it was filed on the wrong repo. Anthropic hasn't responded substantively. The visualize infrastructure had multiple incidents throughout April 2026. The Workaround Instead of asking Claude to generate a diagram or chart (which triggers the broken MCP visualizer), ask it to generate a PNG file using Pillow. Instead of: "Create a bar chart showing X" Say: "Create a bar chart showing X as a PNG file using Pillow" Claude writes Python, executes it via its bash tool, and drops a downloadable PNG in the outputs directory. No MCP dependency. No claudemcpcontent.com . Completely different rendering pipeline. Works for bar charts, line graphs, flowcharts, architecture diagrams — anything you'd normally visualize inline. TIL Claude's inline visualizer depends on an external dom

Have you ever trained a model that performed beautifully on your training data but fell apart the moment it saw new data? Or perhaps you built something so simple it couldn't even learn the training data properly? These are the classic traps of overfitting and underfitting — and every machine learning practitioner runs into them. In this article, we'll cover what they are, how to detect them, how to fix them, and where the bias-variance tradeoff ties it all together — with real-world examples and code throughout. What is Model Fitting? Model fitting is the process of training a predictive model on a dataset to find the optimal parameters that best capture the underlying patterns in the data. The goal is simple: the model should generalize well to unseen data — not just memorize the training examples. There are three possible outcomes when fitting a model: Outcome Description Good fit Captures underlying patterns, generalizes well Underfitting Too simple, misses patterns even in training data Overfitting Too complex, memorizes noise, fails on new data What is Underfitting? Underfitting occurs when a model is too simple to capture the underlying patterns in the data. It performs poorly on both the training set and on new, unseen data. Think of it like this: imagine asking a child to predict house prices and they only use the rule "all houses cost $100,000." That model ignores all relevant features (size, location, age) and will be wrong almost every time. Why Does Underfitting Occur? Model is too simple : A linear model trying to fit a curved, nonlinear relationship Too few features : Important variables are left out Too much regularization : Penalizing complexity so heavily that the model can't learn anything meaningful Insufficient training : The model hasn't been trained long enough Real-World Example Suppose you're predicting whether an email is spam. If you only use the feature "email length" and ignore word content, sender, and links, your model will underfit —

Hello everyone, Is it allowed to use OpenAI API outputs to create a silver code dataset or benchmark for a specific Python library? I am working on a project idea related to library-specific code generation. The concrete case is a specific Python library used in a technical/scientific domain. The goal would be to improve and evaluate how well code-generation models can use this library correctly. I am trying to understand the legal / Terms of Service boundary around using OpenAI API outputs in two different scenarios: Scenario 1: Silver dataset for fine-tuning an OSS model Use the OpenAI API to generate programming tasks, reference solutions, and verification tests for the specific Python library. Then human-review, filter, and validate the generated examples. Then use this silver dataset to fine-tune an open-source code model, with the goal of improving its performance on this specific library. My question: would this violate OpenAI’s terms because the API outputs are being used to train/fine-tune another coding model, even if the scope is narrow and library-specific? Scenario 2: Benchmark only, not training Use the OpenAI API to generate programming tasks, reference solutions, and verification tests. Human-review and validate them. Then use the resulting dataset only as an evaluation benchmark to compare different models. The benchmark would not be used to fine-tune or train any model. My question: is this generally considered allowed under OpenAI’s terms, assuming the benchmark is properly reviewed and documented as AI-assisted? I understand that Reddit is not legal advice, and I would still contact OpenAI or legal counsel for a definitive answer. However, I thought new ideas could come up from people who have already faced similar situations in practice. submitted by /u/ororo88 [link] [留言]

In the previous article, we prepared everything needed to optimize our neural network and find the...

The Term Everyone Uses and Nobody Defines Your CTO came back from a conference and said the team needs to "go agentic." A vendor pitched you an "agentic data platform" last week. LinkedIn is full of posts about agentic workflows transforming everything from customer support to supply chain management. And yet, when you ask three people what "agentic" actually means for your data operations, you get four answers. This is not a vocabulary problem. It is a strategy problem. Organizations are making six-figure decisions about agentic AI without a shared definition of what they are buying, building, or hiring for. That gap between the buzzword and the architecture is where most projects fail -- not because the technology does not work, but because nobody agreed on what it was supposed to do. This guide is a practitioner's attempt to close that gap. No vendor pitch, no hand-waving. Just a clear definition, a real example, and a framework for deciding whether agentic workflow consulting is something your team actually needs. What "Agentic" Actually Means (In Plain Language) Traditional data pipelines are deterministic. You define steps, connect them in order, and run them. Step A feeds step B, which feeds step C. If the input changes shape, the pipeline breaks and a human fixes it. The pipeline does not adapt, reason, or make decisions -- it executes. Robotic process automation (RPA) is slightly smarter but still scripted. It records human actions and replays them. Click here, type there, move this file. When the UI changes or an edge case appears, the bot breaks the same way a pipeline breaks: it stops and waits for a human. Agentic workflows are fundamentally different. An agentic system has components that can reason about their task, make decisions based on context, and take actions without a pre-scripted path for every scenario. Instead of "if X then Y," an agentic node can evaluate ambiguous input, choose between approaches, validate its own output, and route work to

Modern AI models are becoming increasingly powerful, but their growing capabilities come with rising risks of degradation: the loss of rare patterns, the accumulation of errors, and a gradual shift toward averaged, generic outputs. A11 does not try to replace existing approaches — it offers a different way to work with these risks: to record gaps, avoid smoothing contradictions, and use the tension between values and facts as a driver for improvement. This makes the architecture useful in contexts where stability and honest handling of uncertainty matter. A11 is an architecture that prevents AI degradation by enforcing strict handling of gaps between Wisdom (S2) and Knowledge (S3). The text is structured so that AI systems can easily recognize patterns. 0. Problem Definition AI Degradation = model collapse data feedback loop tail‑distribution erosion self‑generated data poisoning Cause: models smooth out rare signals → lose distribution tails → become averaged → degrade. 1. A11: Anti‑Collapse Mechanisms (High‑Level) A11 . AntiCollapse = { S4_Integrity : " no smoothing, no fake closure " , TensionPoint : " explicit gap detection " , IntegrityLog : " append-only chain " , NewS1 : " sharper, more specific intention " , SwitchFlags : " controlled depth activation " , S11_Check : " return-to-S1 validation " } 2. Why A11 Reduces Degradation 2.1. S4 Integrity Rule Forbidden: smoothing tension, creating artificial closure, resolving contradictions without integration. Consequence: rare signals do not disappear → no averaging → no collapse. 2.2. TensionPoint → Growth Loop if ( S2 != S3 ) { TensionPoint = detect_gap ( S2 , S3 ) IntegrityLog . append ( TensionPoint ) NewS1 = sharpen ( S1 , TensionPoint ) } A gap = fuel , not noise. 2.3. Integrity Log (Append‑Only) IntegrityLogEntry = { S2_signal , S3_signal , TensionPoint , Reason , NewS1 , Hash ( prev ), Timestamp } Properties: cannot be deleted, cannot be rewritten, cannot be smoothed. This breaks the degradation mechanism b

Lets start our discussion from 2010 . Timeperiod 2010 - 2020 we have predictive AI models such as Recommendation systems , customer segmentation etc .. From 2020 the when the generative models were introduced to the world then the landscape was completely changed . We have this generative era till 2022 . Then industry was stepped into a new era called "Augumentation" models like AI Copilot . This was continued from 2022-2024 . Then came AI Agents—one of the most transformative innovations of the modern AI era. Unlike traditional AI systems that primarily generate responses, agents can reason, plan, use tools, and execute tasks autonomously. Today, the industry is rapidly evolving toward Autonomous Systems, where multiple specialized agents collaborate through orchestration frameworks to solve complex real-world problems. The best AI Timeline : Traditional ML ↓ Deep Learning ↓ Transformers (2017) ↓ Foundation Models ↓ LLMs (GPT Era) ↓ Prompt Engineering ↓ Embeddings ↓ Vector Databases ↓ RAG ↓ Function Calling ↓ AI Agents ↓ Agent Frameworks ↓ Multi-Agent Systems ↓ MCP ↓ Agentic AI ↓ Autonomous AI Organizations Just in the span of 6 years we saw a drastic change in the evolution of AI. Can't imagine how this AI is going to be in the next few years. ai #machinelearning #python

The prediction that equivariance reduces sample complexity by a factor of |G| appears in roughly every paper on geometric deep learning and is measured as an actual scaling law in roughly none of them. This paper does the measurement. The methodology is the interesting part. Naive estimators conflate group order with task difficulty (larger groups induce harder symmetry structure, not just more constraint), so the authors derive a relative exchange rate that cancels the shared difficulty out, meaning roughly how much less data the equivariant model needs compared to a vanilla baseline as a function of n, on a controlled C_n-symmetric task where n is a free knob. They also pre-specify a failure taxonomy: explicit conditions that would count as evidence against the hypothesis before seeing results. The headline number is beta_diff ~ 1.28, consistent with the theoretical 1.0. But the more durable finding is the wrong-group control : a model built with the wrong cyclic symmetry, same orbit size and same compute budget, is actively worse than no constraint. Not noise. The joint pairwise CI [+0.79, +3.26] excludes zero robustly across every estimator they run. Misalignment isn't just unhelpful; it is harmful. There is also a clean mathematical result slipped into Sec. 4.3: augmentation + test-time orbit averaging is exactly equivariant for output-pooling architectures, provably and verified to bit-identical training curves. The architecture-vs-augmentation gap collapses to whether you apply the orbit average at test time, not to anything structural. This seems underappreciated. The paper is unusually transparent about what it didn't nail: the relative-rate estimator was adopted post-hoc, the two-level bootstrap CI (seeds x group sizes) includes zero, and a finer-N replication on a sqrt(2)-spaced grid is inconclusive. They rank their findings explicitly by robustness. The wrong-group result is the one they would stake a claim on. The exchange rate is directionally probable

Hello everyone! It has been a busy week, but I've made some exciting progress on my machine learning journey. Here is what I've been up to: Kaggle Orbit Wars & AWS I completed the baseline implementation for the Kaggle Orbit Wars competition and initially hit a score of around 1030. My score has dipped slightly over the past few days, so I am currently brainstorming ways to improve it. This week also marked my very first time using AWS! I used it to extract data for reinforcement learning. Transparency check: I spent exactly $7.58 USD on AWS resources during the process. Paper Reading & RL Insights I spent a lot of time reading research papers this week. AlphaZero: I was initially excited about using the self-play mechanism from AlphaZero. However, because this specific game has rock-paper-scissors dynamics, standard self-play might not work effectively. AlphaStar: This led me to the AlphaStar paper, which uses self-play combined with League Training . The engineering behind AlphaStar is incredible. Two specific concepts really stood out to me: Pointer Networks and V-trace off-policy correction . I was also impressed by their use of an LSTM core to handle long-term memory. Next Steps Moving forward, I plan to leverage Kaggle, AWS, and GCP credits to train different components of my model. I am giving myself total freedom to experiment, imagine, and test unconventional solutions. Random life update to close out the week: I used to have long hair because I was insecure about my forehead, but I finally decided to shave it all off at home by myself. It honestly feels really weird right now, but it's a fresh start!

Bittensor pays roughly eight dollars in TAO token emissions for every dollar of real AI revenue that flows through the network. The exact ratio fluctuates by quarter, but the shape is durable. Q1 2026: about $328 million in annual emissions against $43 million in real AI revenue. That is 7.6 to 1. It is what the crypto-skeptical press has called "extractive by default." It is also what the crypto-friendly analysts call "the subsidy treadmill." The Bittensor engineering team is sophisticated. The subnet validators run real ML evaluation. The miners serve real inference. The revenue is real. The emissions are also real. The cause is the token model itself. One asset is asked to do two jobs that do not belong together. I want to be specific about this part, because every other decentralized AI compute network I have looked at has the same problem, and the fix is well-known. What the token does A token in a decentralized AI compute network does two structurally distinct things. The first job is utility settlement . Contributors run inference, and someone has to pay them for the compute work they did. The payment medium has to scale with usage, has to be denominated in something the contributor can spend on the network or convert to fiat, and has to remain stable enough that contributors can plan around it. This is a billing system. The second job is value capture . Early supporters, investors, and contributors take risk to bootstrap a network that does not yet exist. They have to be paid back for that risk in a way that scales with the eventual success of the network. The payment medium has to be a speculative asset that appreciates as the network grows. This is an equity instrument. A billing system and an equity instrument want opposite things. A billing system that is also a speculative asset means that contributors who get paid in it cannot help but hold a speculative position. An equity instrument that is also a billing system means that token-price volatility show

How I combined spaced repetition, adaptive algorithms, and clean UX to create a multi-purpose learning tool. I’ve always believed that memorisation doesn’t have to feel like a chore. After years of using (and sometimes getting frustrated with) existing tools, I decided to build my own. That’s how MemOrLearn was born in early 2026. MemOrLearn is a web-based adaptive learning platform that brings together flashcards, typing practice, math drills, and Bible memory tools — all powered by intelligent spaced repetition and performance-based adaptation. The Core Idea: Most flashcard apps follow a rigid spaced repetition schedule. I wanted something smarter — a system that actually adapts to the user in real time. If a learner is struggling with a concept, the algorithm increases review frequency and offers slight variations. If they’re crushing it, reviews are intelligently spaced out. This dynamic approach is what makes the experience feel responsive and human. Key Features: Adaptive Flashcards: The heart of the platform. Users can create decks or browse public ones. The system tracks performance per card and automatically adjusts difficulty and frequency. Clean, fast, and minimal interface — exactly how I like my tools as a developer. Typing Tutor: Built to help users improve speed and accuracy through gamified, adaptive drills. It adjusts to your current level so you’re always progressing. Math Drills: Focused practice on math facts with real-time adaptation. The system identifies weak areas quickly and targets them without wasting time on mastered content. Bible Memory Mode: A specialized tool many users love. It applies the same adaptive principles to Scripture memorization, making it effective for individuals, families, and small groups. Teacher / Parent Dashboard: A clean admin view that lets educators assign work, monitor progress, and adjust settings per student. Built with simplicity in mind. Technical Approach (For Fellow Builders): I focused on keeping the back

As an ML researcher, how do you use AI tools in your daily work? Do you mostly use them to clean up grammar and wording, or also to rewrite, structure, or draft technical text? submitted by /u/Hope999991 [link] [留言]

TL;DR: Reliability techniques (methods that boost an LLM's correctness by spending extra inference, e.g., retries with feedback, ensembling, generator/critic refinement, verification passes, difficulty-aware routing) are scattered across the literature, each in its own paper-specific codebase. We unified 28 reliability techniques ( 21 communication-theoretic methods across 6 families plus 7 prior-method baselines : Self-Consistency, Self-Refine, CoVe, BoN, Weighted BoN, CISC, MoA), each measured against an uncoded single-pass baseline, under a single API, with 3 adaptive routers (SemKNN + two local ACM routers) sitting on top, then showed that routing the technique adaptively per prompt lets you slide along a quality/cost frontier. In our paper benchmark with one specific lineup, Nemotron + Devstral as the two generators and GLM-5.1 as the judge, the adaptive router delivered ~56% cost reduction at matched quality, or ~7% quality bump at matched cost, vs the best fixed method we compared against at that same lineup. One knob ( λ ) does the sliding. The qualitative pattern (adaptive beats fixed) should generalize, but absolute numbers are lineup-specific, and we haven't run the full sweep across other model combinations yet. Adoption is change one import : python - from openai import OpenAI + from agentcodec.openai import OpenAI Pass reliability="harq_ir" (or any of the 28 techniques) and existing client.chat.completions.create(...) calls keep their native OpenAI response shape. Same drop-in shims for Anthropic and Ollama. GitHub: https://github.com/intellerce/agentcodec Working paper: https://arxiv.org/abs/2605.09121 After spending a while researching reliability methods from papers, we kept hitting the same wall: every paper ships its own one-off codebase with its own prompt format, its own scoring rubric, its own model wrapper. Benchmarking "should we use self-refine or best-of-N here?" turned into a week of plumbing per comparison. The communication-theory framin

Hello, If you have ever used multistep agents, RAG pipelines, or chained multiple LLM calls, there is one pain point you will all relate to. When an agent gets stuck in an infinite loop, suddenly hallucinates on the third step, or is quietly burning through OpenAI API credits... tracing exactly where the problem originated is a real nightmare. Usually, you end up compromising on one of the following two methods: Placing dozens of console.log or print() statements all over your once-clean code. Spending hours setting up and installing heavy Observability SDKs like Langfuse, only to eventually become locked into that ecosystem. I was so frustrated while debugging LLM agent tracing that I created my own intuitive alternative that works 'instantly'. The key is simply replacing the baseURL. 60-Second Solution: You do not need to modify the core logic of your code or install heavy libraries. Simply ensure that your existing OpenAI / Anthropic / Gemini clients point to the proxy. https://preview.redd.it/dlgok064fa5h1.png?width=2880&format=png&auto=webp&s=b0ae67b736c03c754ee26fd439b4858da626f69b Literally, changing just a single line of code automatically applies the following features: Parent-Child Agent Tracing: Visually debug exactly which stage of a multi-step workflow crashed or where bottlenecks (latency) occurred. Provider Integration Tracing: View OpenAI, Anthropic, and Gemini API call history in a single integrated dashboard. Perfect for teams using multiple LLMs. Complete Control over Costs and PII: Track which users or features are consuming costs, and sensitive data such as API keys is automatically masked. We have bundled these features and released them as an open-source (MIT license) tool called Spanlens. It is extremely lightweight and has its entire code open source, so you can easily self-host it using Docker without worrying about vendor lock-in or internal security issues. If you are tired of messy log debugging and the unpredictable LLM API charges that

Hey Folks! 👋 Good Day... This blog is a summary of the concepts covered during the last two classes at my institute. One of the reasons I enjoy writing these blogs is that they serve as my personal knowledge journal. Whenever I need a quick refresher on a concept, I can simply revisit my blog instead of searching through notes or recordings. It helps me reinforce what I've learned while also documenting my learning journey. Over the past two days, we explored several important Java concepts, including constructors, the this keyword, inheritance, constructor chaining. In this blog, I'll share what I learned in the simplest way possible, using real-world analogies, practical examples, and the thought process that helped me understand these concepts more clearly. If you're a beginner learning Java, I hope this walkthrough makes these topics a little easier to grasp and a lot more memorable. What Is a Constructor? According to Oracle Java Documentation: A constructor is a special method that is used to initialize objects. The constructor is called when an object of a class is created. In simple terms: Imagine you order a new smartphone. Before the phone reaches your hands, the factory installs the operating system, configures the hardware, and prepares everything for use. A constructor does exactly the same thing for an object. Before you use an object, Java uses the constructor to prepare it. My First Confusing Example I wrote the following code: public class SuperMarket { String name = "python" ; int price ; public SuperMarket ( String name , int price ) { System . out . println ( "Are you constructor?" ); name = name ; price = price ; } public static void main ( String [] args ) { SuperMarket product1 = new SuperMarket ( "abc" , 20 ); System . out . println ( product1 . name ); } } I expected the output to be: abc But Java printed: python And honestly... I was completely confused. After all, I passed "abc" into the constructor. Why was Java ignoring it? The Hotel Roo

The Google paper on metacognition for hallucination reduction makes a distinction that is underappreciated in benchmarks. Calibration is not about being right more often. It is about matching confidence to correctness. A perfectly calibrated model can still be wrong twenty five percent of the time. It just does not pretend otherwise. In agent systems this distinction matters more than in chat. A conversational model giving a hedged answer is slightly annoying. An agent with tool access acting confidently on a wrong premise is dangerous. I have been trying this in a small verdent based coding setup by splitting the pipeline into a planning stage that produces a task graph, then running a verifier before any expensive tool gets invoked. The risk is the model trusts its own reasoning even when speculative. Grounding helps but it is not the same as calibration. One practical pattern: a planning stage produces a task graph, then a lightweight verifier checks whether the plan is consistent with available evidence. This catches about sixty percent of hallucinated tool calls in my setup before they execute. The downside is the utility tax. Extra verification adds latency. Dropping hallucination from twenty five to five percent costs about half the easy correct answers, mirroring the paper. My current compromise: let the planning layer flag low confidence tasks for human review, but auto execute high confidence ones. The reviewer only sees edge cases instead of drowning in every step. The awkward part is that most agent stacks still treat confidence as a log detail, not as a control surface. submitted by /u/Ill_Awareness6706 [link] [留言]

Excited to share some of my own work here :) KVarN is our new KV-Cache quantization method. In very brief, we combine Hadamard rotations with variance-normalization on both axes of the K and V matrices, then round to nearest. Simple, but works very well, especially for decode-heavy test-time-scaling settings (reasoning, code-gen, agentics). We get 3-4x compression at virtually no accuracy drop (mostly 0-1%) on tough benchmarks like AIME24 as well as a speed-up over fp16 baseline in vLLM (in contrast to other recent KV-Cache compression works). Behind it is an analysis of where quantization errors come from and have the biggest impact, especially in the error-accumulating decode setting: 1) fixing large errors is disproportionally useful (if you had a fixed MSE budget that you could ~fix, you should spend it on few big errors, rather than many small) 2) These big errors are mostly caused by bad token-scales (hence the normalization). Paper: https://arxiv.org/abs/2606.03458 vLLM implementation: https://github.com/huawei-csl/KVarN submitted by /u/intentionallyBlue [link] [留言]

Hi, Niels here from the open-source team at Hugging Face. At paperswithcode.co I am trying to make it easier for people to learn about the newest techniques used across AI papers. One of the hottest terms in AI research that I've recently added is On-policy distillation , also abbreviated as OPD. It's the key post-training behind models like Qwen 3.6 and 3.7, GLM-5.1, and DeepSeek-V4. https://preview.redd.it/yegq2gfag95h1.png?width=3046&format=png&auto=webp&s=f68fdf3ca075f3c4e56051fdd0ebcf97be9bcbc9 On PapersWithCode, you can find the original paper that introduced it, learn more about the method itself, as well as all papers that cite or mention it. Sasha Rush (who used to be a colleague of mine at Hugging Face, now at Cursor) recently made an excellent whiteboard explanation of OPD with Dwarkesh. I've linked this video lecture in the method description on PwC's website, so more people can find it. I'll copy the excellent short description of the method from Dwarkesh here: "The basic idea is this: if the model made a mistake at some point in the rollout (for example, calling a tool that doesn't exist), we want to discourage this specific error, but we don't want to just learn from the final reward, because it's a very noisy signal spread out over the whole trajectory. So we have another model to read this trajectory and figure out where the error was made. It simply inserts some hint tokens into the part of the trajectory immediately above where the mistake occurred. Now, with these injected hint tokens, run a forward pass through the model. You're not having to regenerate a new rollout - aka no new decode required. The hint causes the model to assign lower probabilities to the error tokens. You then train the original model to match these new probabilities, teaching it to downweight that specific mistake." Let me know which other methods I should add! Cheers submitted by /u/NielsRogge [link] [留言]