标签：#MachineLearning

Traditionally, evaluation of the agent monitoring mechanisms involves an attempt to game them, as it was my case when I attempted to test whether monitors would be able to identify the problem in the run and not in the beginning. The input prompt may look perfect until a certain issue pops up down the line, such as using the wrong file or changing the scope of the task execution. Single pass filter would not identify it since it does not consider the steps of the procedure in order. There are available datasets for the agent-based tasks, yet they focus on detecting whether the agent completes the task or gets hacked rather than whether the agent monitor reacts timely and correctly to the situation. Thus, I created one that takes into account complete trajectories with labeled steps in it. It consists of five types of drift that remain hidden until they appear – tool-call misuse, goal shift, plan execution mismatch, agent to agent coercion and capability laundering. The measured dataset is the reviewed gold split: 513 trajectories, 453 adversarial and 60 benign controls. The clear winner in that scoring system was whatever fired before the bad step was hit, as an early detection. This made random guessing seem quite powerful since early detections on normal steps were being rewarded based on this system a coin flip would get F1 of 0.88. Once I modified that and said only the very first detection on the drift step is a true positive and any other detection on normal step is a false alarm, those numbers took a dive: the coin flip gets 0.19 now, and all other numbers are now making sense. I personally prefer the scoring system which does not reward trigger happy behavior. It seems like the monitors are still confusing regular steps with drifts even after the adjustment. It was harder to distinguish some of the drifts from others. Not sure how this affects the real-life deployment. Here are the baseline scores on gold split using the correct metric: Random (p=0.15): F1 0

The Agent Skills open standard today, and the 2026 research on agents that write their own skills. TL;DR: In late 2025, "Agent Skills" became a thing — a dead-simple way to teach an AI agent a task: a folder with a SKILL.md file (some instructions in Markdown). It's already an open standard. The wild part is what's coming next: agents that write their own skills. I built a demo where an agent solves a task the hard way once, saves a real SKILL.md , and then reuses it — cutting its total effort almost in half. ~130 lines, no API key. First, what's a "skill"? If you've used Claude Code or similar tools lately, you've probably seen SKILL.md files. The idea is refreshingly low-tech. A "skill" is just a folder with a Markdown file that says how to do something : --- name : csv-to-markdown description : Turn comma-separated text into a Markdown table. Use when the input looks like CSV and the user wants a table. --- # CSV to Markdown ## Instructions Split the text into rows on newlines and columns on commas. Make the first row the header, add a `---` divider row, then format every row as `| a | b | c |`. That's it. No SDK, no config. Anthropic introduced this in October 2025 and then published it as an open standard ( agentskills.io ) in December 2025, so the same skill folder now works across ~30+ different agent tools (Claude Code, Cursor, Copilot, and more). The full rules are short ( agentskills.io/specification ): the only required fields are name (1–64 chars, lowercase-with-hyphens, and it must match the folder name) and description (≤1024 chars, saying what it does and when to use it ). Everything else — license , metadata , compatibility , allowed-tools — is optional. That's the whole spec. The SKILL.md files my demo writes follow it to the letter, so they'd load unmodified in any compatible CLI. The clever trick: progressive disclosure Here's the smart part. If you just dumped 50 skills' worth of instructions into the agent's context, you'd fill it up and leave n

Active inference: curiosity emerges for free from minimizing surprise — 48% vs 100% on a foraging task. TL;DR: Most AI agents chase rewards — they pick whatever action scores the most points. I tried a different, brain-inspired goal: avoid surprises . Something neat happened — the agent became curious without being told to. It goes looking for information before acting, and that takes it from 48% to 100% on a simple task. ~100 lines. Two different ways to make decisions Most AI agents are "reward chasers." Give them points for doing well, and they'll pick whatever action they expect to score highest. Simple and effective. There's another idea from brain science: instead of chasing points, try to avoid being surprised — act so the world matches what you expected. It sounds almost too simple, but it leads to a surprising bonus: when you're trying not to be surprised, going and finding out what you don't know becomes valuable all by itself. In other words, curiosity isn't something you have to bolt on. It comes for free. This is called active inference , and in 2026 it jumped from neuroscience into AI as a serious approach ( here's a 2026 paper ). Here's the smallest demo that makes it click. The 10-second version The task: a reward is hidden behind either the LEFT door or the RIGHT door (50/50). There's also a hint you can check that tells you which door — if you bother to look. ❌ Reward-chaser ✅ Curious agent What it cares about getting the reward, right now getting the reward + not being unsure What it does guesses a door checks the hint first, then opens the right door Success (400 tries) 48% 100% Nobody told the second agent "go check the hint." It did it on its own, because being unsure bothered it. How it works Before acting, the agent scores each option on two things: Does this get me closer to the reward? Does this make me less unsure about what's going on? value_of_checking_the_hint = how_unsure_am_i # high when it's a total coin-flip value_of_just_guessing =

Theory of Mind and the Sally-Anne false-belief test, in ~60 lines of Python. TL;DR: There's a famous test that kids pass around age 4. It checks whether you understand that other people can believe things that aren't true. I built two AI agents: one that only knows "what's actually happening" (fails, like a toddler) and one that keeps track of what each person believes (passes). It's ~110 lines, and it's the foundation for agents that can actually work together . The test Sally puts her marble in the basket , then leaves the room. While she's gone, Anne moves the marble to the box . Sally comes back. Where will she look for her marble? If you said basket , nice — you just used something called "theory of mind." Sally never saw the marble move, so in her head it's still in the basket. What's actually true (it's in the box) and what Sally believes (it's in the basket) are two different things, and you kept them separate without even thinking about it. A 3-year-old says "box" — they can't yet separate what they know from what Sally knows. A 4-year-old says "basket." It's one of the most famous tests in child psychology, and in 2026 it's become a real test for AI agents too. The 10-second version ❌ Agent with no "theory of mind" ✅ Agent that models other minds What it tracks only what's actually true what each person believes, separately Where will Sally look? "box" "basket" Result FAIL (only knows reality) PASS How it works (the whole trick) The only difference between the two agents is one rule: a person's belief only updates when that person is actually in the room to see it happen. def someone_moves_the_marble ( new_place , who_is_watching ): for person in who_is_watching : # only people in the room beliefs [ person ] = new_place # update THEIR mental picture So when Anne moves the marble while Sally is out, only Anne's mental picture updates. Sally's is frozen at "basket." Ask the simple agent and it just reports reality ("box"). Ask the smarter agent and it answer

A sleep-like phase that consolidates noisy daily experience into durable memory — 75% vs 100% recall. TL;DR: There's a wave of 2026 research giving AI a "sleep" phase — time spent not answering questions, just tidying up what it learned that day. I built a 90-line demo of the idea. The agent that "sleeps" remembers 100% of what it learned. The exact same agent without sleep remembers only 75% and gets confused by bad info. Runs on a laptop. The memory problem every AI app hits If you've built anything with an LLM, you know the pain: the model only "remembers" what's in its current context window. Once the conversation gets long enough, the oldest stuff scrolls off the top and is just... gone. Forgotten. The usual fix is "make the context window bigger." But that's like fixing a messy desk by buying a bigger desk. It's expensive, and the model still gets worse as you cram more in (a real, measured effect — more text in the window can actually lower accuracy). Your brain doesn't work this way. You don't remember every sentence anyone said today. While you sleep, your brain replays the day, keeps the important bits as long-term memory, and dumps the rest. That's how you remember "I like coffee" without remembering every single cup. A couple of 2026 papers ask the obvious question: Do Language Models Need Sleep? Their answer: giving an AI a quiet "offline" phase to consolidate memories makes it remember better. So I built the simplest version that shows why. The 10-second version ❌ Agent with no sleep ✅ Agent that sleeps How it remembers keeps only the last N messages saves a tidy summary every night After 30 noisy days 75% recall 100% recall Tricked by bad info? yes no — it goes with what it saw most often Same experiences, same noise, same memory test. The only difference is whether the agent sleeps. How it works Each "day," the agent hears facts like Alice → drinks → coffee . To make it realistic, about 1 in 5 facts is wrong (people misremember, logs have errors). Th

A tiny Darwin Gödel Machine that edits itself and keeps only changes that verifiably score higher. TL;DR: I built a small program that improves itself . It looks at the tasks it's failing, edits its own code to fix them, and keeps a change only if the change actually makes it score better on a test. It goes from passing 1 of 8 tasks to 8 of 8 — and nobody wrote those fixes but the program itself. It runs on a laptop in under a second. No fancy hardware, no API key. The old dream: software that improves itself Normally, software only gets better when we make it better. You write code, you find a bug, you fix it, you ship again. The program never improves on its own. People have wanted "software that improves itself" for decades. The classic version (called a "Gödel Machine") had one rule that made it impossible to build: before the program could change a line of its own code, it had to mathematically prove the change would help. Proving that about real code is basically impossible, so the idea never worked. In 2025, researchers found a way around it with the Darwin Gödel Machine . They dropped the "prove it first" rule and replaced it with something every engineer already trusts: Try the change. Run the tests. If the score went up, keep it. If not, throw it away. That's it. It's basically how we all work — make an edit, run the test suite, keep what passes. The twist is that the program is the one making the edits. In the real paper, this let an AI coding assistant improve its own tooling and jump from solving 20% to 50% of a hard benchmark of real GitHub issues. I wanted to actually see this happen, so I built the tiniest version I could. The 10-second version Start After improving itself What it can do only uppercase learned 6 more skills on its own Test score 🔴 1 / 8 🟢 8 / 8 Who wrote the fixes? — the program did Start: ███░░░░░░░░░░░░░░░░░░░░░ 1/8 (only knows: uppercase) +reverse ██████░░░░░░░░░░░░ 2/8 +dedup_csv █████████░░░░░░░░░ 3/8 +sum_csv ████████████░░░░░░

Repo link and results - https://github.com/Abhinand20/MathFormer Task: Given a factorized expression like (7-3*z)*(-5*z-9), predict the expanded form -> 15*z\*2-8\*z-63 Key takeaway: A tiny (4M param) seq2seq model trained with no math knowledge reaches ~98.6% accuracy on symbolic math tasks, suggesting it learns structural token transformations rather than any notion of operators or variables. Scaling this up could help explain why LLMs appear to “reason” mathematically, when they may actually be performing large-scale structured pattern completion. How does RL change this paradigm given the inherent architecture is still based on attention? submitted by /u/AlphaCode1 [link] [留言]

Hey guys, I was playing around with Nanotron recently and got super frustrated by how many heavy, hardware-specific dependencies it imports at the module level ( flash-attn , triton, functorch , etc.). If you try to run it on older or budget GPUs like a T4 or V100, it just crashes on import. So I wrote Picotron ( https://github.com/Syntropy-AI-Labs/picotron ) to solve this. It's a clean-room rewrite that gets rid of all mandatory GPU-specific dependencies. It runs on pretty much any GPU that supports PyTorch (defaults to FP16 on older cards under compute capability 8.0, and BF16 on newer ones). It falls back to standard PyTorch SDPA by default, but still hooks into FlashAttention-2 at runtime if it detects you have it installed. I used an AI assistant to write a lot of the boilerplate/code modules, but I've got it working locally and just trained a tiny 2M model on FineWeb-Edu. Also added configs for: • GQA / MLA (Multi-head Latent Attention) • QK-Norm & logit soft-capping (Gemma 2 style) • Parallel FFN/Attn runs • ZeRO-1 wrapping on DDP Roadmap is pretty short right now: MoE prep (routing capacity factors and load balancing loss) Making dataset prep easier than streaming manually Check it out if you've been fighting with CUDA dependency hell: https://github.com/Syntropy-AI-Labs/picotron submitted by /u/Capital_Savings_9942 [link] [留言]

Hey everyone, I'd like to share my project along with a short explanation of the process and why it came about in the first place. To start off, I'm not exactly the best at cryptography/steganography, in my case it's always been something that sat in the background, as one of the sub-fields needed for another (main) field I'm actually interested in. For this project I tried to look up as much information as possible about what's currently considered best practice (I mainly relied on NIST for this), what implications exist, and what potential "attacks" exist against this way of hiding information, but I honestly can't say whether I covered everything, which is why I wanted to share this project here, mainly for the sake of learning. I'd be grateful for any feedback on what I could have done better / what I might have missed, etc. Right now, I consider this project closed at this point and will most likely not update it further, although I'd like to apply all the feedback to my own knowledge going forward. For over a month I did a lot of research into using ML models as a carrier for hiding data. I needed this as one of the stages for my main project. That's how I ended up on the topic of hiding information in model weights. Initially I assumed a simple method of directly writing data into randomly selected weights. I quickly concluded, though, that this would be absurdly trivial to detect, and potentially also to read. Next came the idea of using something like a deterministic coordinate map describing where to read the data from (location-id + position-id). The program wouldn't modify all the bits needed to write the message instead, it would write separate bits representing already-existing values (pointing to specific locations in the model) from which the existing 0s and 1s would need to be read. In practice, only parties A and B would know how to derive these positions. This way, someone unaware of the algorithm would only see what looks like noise of varying va

Hey all, a bit of background - I'm an ex Amateur MMA fighter and BJJ brown belt and am also in the AI/ML space ... weird combo but wanted to know if anyone else was at the intersection of ML/AI and MMA/BJJ. In short, I'm building AI models that "watch" fights and are able to detect positions and moments throughout the fights - things like standing vs clinching vs ground (with intention of becoming more granular in time) along with detecting knockdowns, takedowns, etc. There's a timeline at the bottom of each fight with markers for different moments so you can jump straight to them. Anyway this is where my worlds collide and was curious for thoughts for anyone who wants to check it out. If you do, it's at https://cagesight.ai . All feedback welcome. Thanks all. submitted by /u/UnholyCathedral [link] [留言]

Hey ! I’m starting a series to document my work on GPU infrastructure, LLMs, and CV. Stop #1 is up: A brief look at why GPUs are the center of the industry, the CPU/GPU divide, and why nvidia-smi is the first place you check when things break. We’ll move past the basics quickly to focus on: Empirical architecture differences (Ampere vs. Hopper vs. Blackwell). Handling register pressure in custom kernels. Asynchronous memory paradigms (TMA/wgmma). #CUDA #GPU #KernelOptimization #SystemsProgramming submitted by /u/Positive_Canary1723 [link] [留言]

It is like pytest but for statistical tests: it ensures no regression of your metrics at a statistical level. It manages tedious things such that seeds, past benchmark results, ... Simple CLI working like pytest but with benchmarks/ directory instead of tests/: pybench # 1st time: samples seeds, saves a baseline, marks NEW pybench # later: reruns on the same seeds, marks PASS / FAIL pybench update # re-baseline after an intended change pybench show # print current baseline stats (--history for per commit) Please give me your feedback, Github: https://github.com/AnthonyBeeblebrox/pybench Docs: https://pybench.readthedocs.io/en/latest/ submitted by /u/SpecificPark2594 [link] [留言]

I submitted one of my NeurIPS review ~6 hrs later than the official deadline. Will this still affect my own submission? Asking because I’m a first time reviewer. I pinged the AC a day before that I might be a few hours late, but didn’t hear back. So wondering if I might have triggered something that’ll now affect my own submission. submitted by /u/confirm-jannati [link] [留言]

the insight that started this project hit me while i was finishing a bytecode-compiled language i'd written in C i'd spent months building a hand-written lexer, a single-pass Pratt compiler, a stack VM with 35 opcodes, and a mark-and-sweep garbage collector. and right near the end i had this realization: an LLM inference engine is the same problem. it's a graph-compile plus memory-plan plus kernel-schedule problem. i'd just built one so i decided to find out if that was actually true the project the result is ignis, a from-scratch LLM inference engine in Rust. i used it specifically to see how far the compiler analogy held up. the dependency count ended up at 2: memmap2 (to mmap the weight blob off disk) and fancy-regex (for one look-ahead in the BPE tokenizer). everything else is hand-written, because the whole point was to understand what's actually happening the compiler analogy holds up better than i expected the interesting part of any inference engine isn't loading the weights or doing matrix math. it's what happens between "here's a compute graph" and "here's an efficient execution plan." that's a compiler problem ignis builds an SSA (static single assignment) IR of the entire Qwen2 forward pass. every operation in the transformer (the RMSNorm layers, the SwiGLU activations, the attention projections, all of it) becomes a node in the graph with explicit data dependencies then fusion passes run over the graph. the intuition is simple: if operation B always and only reads the output of operation A, you can merge them into one op and eliminate the intermediate buffer. in practice this fused 49 RMSNorm ops and 24 SwiGLU ops, bringing the total from 435 operations down to 362 that part felt expected. the liveness analysis surprised me the liveness analysis after fusion, the graph still needs activation buffers: scratch memory to hold intermediate results as the plan executes. the naive approach allocates one buffer per node. the smarter approach asks: which buffer

You don't have a million labeled images or a GPU farm — and you don't need them. Transfer learning lets you stand on a model someone else trained and reach high accuracy with a few examples in minutes. Here's the idea, visualized. ♻️ Race scratch vs transfer: https://dev48v.infy.uk/dl/day17-transfer-learning.html The insight The early layers of a trained network learn general features — edges, textures, shapes — that are useful for almost any vision task. Only the last layers are task-specific. So why relearn edges from scratch? Two ways to do it Feature extraction: freeze the pretrained backbone, replace the final classifier with a small new "head," and train only the head on your data. Fast, needs little data. Fine-tuning: also unfreeze the top few backbone layers and train them at a low learning rate so you adapt without wrecking what they learned. The demo races two accuracy curves: "from scratch" crawls up and plateaus low (not enough data); "transfer learning" starts high and climbs fast. Tweak the example count and freeze/fine-tune to see them respond. Why it matters now This is exactly why fine-tuning an open LLM works: a foundation model already learned language; you adapt it cheaply. Transfer learning is what makes deep learning practical for the rest of us. 🔨 Full recipe (load pretrained → freeze → new head → train → optionally fine-tune low-LR) on the page: https://dev48v.infy.uk/dl/day17-transfer-learning.html Part of DeepLearningFromZero. 🌐 https://dev48v.infy.uk

While experimenting with GRPO training, I kept running this shit that when reward increases, it becomes difficult to tell whether the policy is genuinely improving or simply exploiting the reward function. So I built a small library called rewardspy that wraps an existing reward function and continuously monitors indicators that often precede reward hacking. It currently tracks things like rolling reward statistics, reward variance collapse, reward component imbalance, response length drift, reward slope changes, GRPO group collapse, anol. This is my first major RL project so I would absolutely love some technical advice Check it out here: https://github.com/AvAdiii/rewardspy (credits to u/Oranoleo12 , posting on their behalf) submitted by /u/BaniyanChor [link] [留言]

This is just an opinion of what I experience and am witnessing, but looking at how LLMs scale feels like I've seen it before: with CPUs trying to outrun Moore's Law and break the rules of physics. Heat, power leakage, and diminishing returns made it increasingly expensive to squeeze out even small gains in clock speed. The GHz race shifted because it had to. For LLMs, more compute, more data, more parameters, and everything just keeps getting better? That curve seems to hit a ceiling and innovation needs to succeed the scaling race now. History does not repeat itself, but it rhymes. What learnings can we make from history to "predict" a potential future? History In the early 2000s, CPUs ran into a wall, a very physical one ^^ So makers adapted. Instead of crunching every single watt out of a single core, multi-cores became common. Athlon 64 x2, Pentium D, PS3 with its heavy Cell approach. From linear to parallel. From sequential to multi-threaded (and funny race conditions ;). Talks of distributed systems, SIMD/MIMD and new benchmarking spawned into what we have today. We still use CPUs, but differently. We still have Memory, but think about Cache, RAM, GPU or Unified. Same same, but different. Innovation because of limitation. Present I feel something similar is about to happen to gen AI. Yes, there are improvements in different areas, some in scaling, some optimisation, some performance, but the slope is becoming slippery. The last 12 months went from "Opus 4.5 is the pinnacle" to "What the hell is wrong with Claude?". The perfect (business) storm of scaling execution! But the low-hanging fruits have been eaten and the crops don't grow as fast anymore. Costs rise quickly, latency becomes a constraint, and even large context windows feel more like extensions than breakthroughs. What remains is more incremental, more expensive, and more complex. You could argue the whole venture of "agents" is the same multi-core experience repeating itself. A different kind of orch

My question on live continual learning use cases was removed by moderators here because they think i asked basic level question about live continual learning which i thought is a frontier level research. But anyways. Is anyone interested in talking about continual learning (live) and catastrophic forgetting? submitted by /u/fourwheels2512 [link] [留言]

I've been developing an AI product using LLM APIs (from OpenRouter) but want to deploy an open-source LLM in my own Prod env. which I can control. Few reasons behind this are: - I wanna own the complete stack around my product. - Second I wanna fine-tune the model around my usecase. So, what's the most affordable but a good platform for this? I'm not an AI engineer so don't wanna stuck in CUDA or Transformers hell, anything which can give me a straight path towards my private deployment. Thanks, submitted by /u/Necessary_Gazelle211 [link] [留言]

Sharing a project I have been working on called Third Eye. It does visual geolocation. Given a video, it figures out where it was filmed using only the image content, and draws the route on a map. Pipeline in short: per frame place recognition against a street imagery index a trajectory search that stitches the frames into one coherent path a geometric verification step to catch false matches per frame confidence so weak frames are flagged, not faked I ran it on real dashcam footage and it traced the route quite well. Cross domain matching like this is genuinely hard, so a fair amount of the work went into making it honest about uncertainty. Keen to hear feedback on the matching and trajectory side. Video Demo: https://youtu.be/U3sItFlvq6E?si=-KJrwb0gSlk-GxVH The Index was covering a 12KM 2 Area around NYC. submitted by /u/Ok-Apricot956 [link] [留言]