Neev Parikh

A few random observations on using modern LLMs* to do research: (*) not mentioning specific models because I think they all currently suffer from the same issues. 1. The sycophancy problem, in research, could be extended to the "helpfulness problem" or the "results-oriented" problem. The goal of research is to determine whether an approach works or not. In contrast, models are trained to produce working code. Checking if it works and making it work are not the same task. Example: I asked a model to run an experiment to compare a new approach with a reference approach that is known to work. The model reported success. On examination, what it did was re-implement the reference approach inside the interface of the new approach, totally subverting the experiment. Makes sense for a model that is trained to "make it work", but useless for research. 2. Preference to keep writing code and tweaking to gain a fractional percentage point improvement in performance rather than attending to the overall research agenda. Probably related to the above, but models tend to start writing code and running experiments, and as the context window grows, they become more influenced by the code they have written and the experiments they have done, so, left unattended, they tend to revert to the mean, using standard techniques or endlessly tweaking hyperparameters to squeeze extra performance, rather than sticking to a research agenda. 3. Models fundamentally distrust new research directions. This is the big one. Repeatedly, the models I use will make an implementation mistake, get a negative result on an experiment, and then justify the negative result in terms of the conventional wisdom, falling back to "The standard approach works because of [standard explanation], while our approach failed because of [hallucinated nonsense]." This makes sense, because the prior art and the arguments for it are in the training set, and the innovation that we're doing isn't. That's what it means to be doing research. It definitely doesn't know why the experiment didn't work, because if it did, then it would have fixed the mistake, so the attribution of the negative result is just something it makes up. But then I'll get it to dig into the negative result and uncover the implementation mistake and it will re-run the experiment and discover that it actually does work. This is the flip side of 1 above. Basically, you can't trust a positive result without verifying that it didn't cheat, and you can't trust the attribution of a negative result because it's already biased to distrust anything that is new. TL;DR: Doing maths and physics and ML research with LLMs is just starting to become practical. I feel like it's a huge accelerant but these are early days and we're just figuring out how to do it. Curious to hear from folks doing research with LLMs if these points align with your experience.

7

2 Comments

LLM inference simulation is getting increasingly important. For big organizations, such as AI labs or inference providers, measuring the real performance of their inference system, for even a subset of system configurations, takes a lot of time and resources. This reduces both deployment and R&D speed. For academia, it might even become prohibitively expensive. In our experiments, Revati makes it 5-17x faster to measure latency distributions on selected inference systems with <5% prediction error and no GPUs. There really aren't a lot of places in which you can work with folks of this caliber!

7

A few months ago our team at Dria was training Mem Agent, a 4B parameter model designed to give any LLM persistent memory through an Obsidian style markdown system. We tried a dozen combinations of base models and RL algorithms before landing on GSPO, a variant of the reinforcement learning methods that are quietly reshaping how every reasoning model gets built today. That experience gave me a deep appreciation for how much the RL training stack for LLMs has evolved in just two years, and how most of the gains came from places nobody expected. The field started with PPO, an algorithm borrowed from robotics that required four separate neural networks in memory just to train one model. Then DeepSeek had a deceptively simple idea: instead of training an entire “critic” model to judge responses, just sample multiple answers to the same question and compare them against each other. That single change (called GRPO) cut memory usage roughly in half and became the backbone of nearly every reasoning model since. But here is what I find most fascinating. The biggest improvements after GRPO were not new algorithms at all. They were subtle bugs hiding inside normalizations that everyone assumed were harmless. One team found that dividing loss by sequence length was secretly rewarding longer wrong answers. Another discovered that normalizing by standard deviation was making models obsess over problems they had already solved. A third noticed that less than 0.5% of gradient updates were causing all the training instability, and blocking just those was enough to fix everything. The pattern is clear: we went from “we need bigger, more complex algorithms” to “we need to understand what our existing algorithms are actually doing at the token level.” This is exactly the philosophy we have been building on at Dria. With Agent Alpha we showed that a 3B model trained with the right synthetic data and RL recipe can match GPT-4o on function calling benchmarks. With Mem Agent we used GSPO to teach a 4B model to read, write and reason over structured memory, rivaling models 50x its size. And with Kai Evolve we took the idea further: instead of a single RL loop, we run evolutionary optimization across hundreds of autonomous iterations, using verification as the fitness function, achieving a 192x speedup on NVIDIA B200 CUDA kernels across 540 generations. The common thread across all of this is that the bottleneck is rarely the absence of a sophisticated solution. It is almost always a subtle misunderstanding hiding inside something that already works. Alexander Weers wrote an excellent technical walkthrough of the full RL evolution from REINFORCE through GRPO and everything that followed. If you work anywhere near LLM training, it is one of the clearest overviews out there: https://lnkd.in/e_ysV-UD

11

Plot twist: LLMs can understand rocket science. They just can't code it without breaking everything. New paper tests LLMs on GTOC 12, where the world's best aerospace engineers compete on "nearly impossible" trajectory optimization problems. The findings are more nuanced than "AI good" or "AI bad." Here's what they found: The Good News: LLMs get the physics. They understand motherships, gravity assists, objective functions. One model scored 18/26 points, double the score from 18 months ago. They've conquered the conceptual barrier. The Bad News: They fail on execution. Not because they don't understand orbital mechanics, but because they: • Mix up km and meters • Make syntax errors   • Format outputs that crash validators • Fall into debugging death spirals (fix 1 bug, create 2 new ones) They act like a good architect who can design a perfect building but breaks the bricks when trying to build it. This isn't about "can LLMs reason?" They clearly can. The question is: can they execute with the precision engineering demands? Not yet. We're at a weird inflection point: AI that understands rocket science but can't reliably convert kilometers to meters. That's either hilarious or terrifying depending on your use case. The gap between conceptual understanding and flawless implementation might be the last major barrier to fully autonomous engineering. Full paper: https://lnkd.in/dhYKQ9yu #LLM #AI #Reasoning #Aerospace #Benchmarks

9

2 Comments

Video models don't just generate. They reason. And now we know exactly how. New research from UC Berkeley, UC San Diego, CMU and SenseTime just overturned a core assumption about how diffusion-based video models think. The old theory: reasoning unfolds frame by frame across a video. The reality: it happens across the denoising steps instead. Early steps explore multiple candidate solutions in parallel. Later steps narrow down to a single answer. When the authors disrupted specific denoising steps, performance collapsed. Disrupting individual frames barely mattered. Three emergent behaviors also showed up:  1. Working memory: Holding onto information even when objects disappear from view  2. Self-correction: Catching and reversing wrong answers mid-process  3. Perception before action: First figure out what and where, then figure out how The practical payoff: a simple, training-free method that ensembles outputs from multiple runs at the right internal layers. No fine-tuning. It outperformed Runway Gen-4 and Kling 2.6 on the VBVR-Bench. Really grateful to Ruisi Wang, Zhongang Cai, and all co-authors for this genuinely illuminating work. Link to Paper: https://lnkd.in/gUwR378V #GenerativeAI #VideoAI #DiffusionModels #AIResearch #DeepLearning

18

⚙️Anyone can prompt an LLM. Only the 1% can engineer its context. ❓What is “Context Engineering”? 🔸Designing the right input scaffolding around LLMs, not just prompts. 🔸Injecting strategic memory, rules, data, APIs, and persona into context 🔸windows. Treating the model like a reasoning engine, not a text autocomplete tool. 💡Why it matters? 🔸80% of output quality = structure of inputs 🔸models are now strong enough — our 🔸bottleneck is how we orchestrate them. 🔸better context → less hallucination → more consistency. 🎯How it makes AI systems better? 🔸reduces retries + drastically cuts inference cost. 🔸improves reasoning depth without retraining models. 🔸transforms “prompt hacking” into a reproducible engineering discipline. 🌐How it is different from today’s prompt-centric mindset? 🔸prompt = copywriting → context engineering = system design. 🔸prompt is one line → context engineering is full pipeline scaffolding. 🔸prompt is per request → context engineering is per system / per workflow. 🔑this is the meta-skill that will separate “AI users” from “AI architects”. 🎓 if you’re building agents / automation / RAG, learn context engineering now. #AI #ContextEngineering #AIEngineering #LLM #Agents #RAG #AIForBuilders #GenAI #FutureOfWork #SystemsDesign #MLOps #PromptEngineeringEvolved

10

1 Comment

The TurboQuant research (ICLR 2026) just dropped, and as an AI engineer, it’s one of those rare moments where software optimization feels like a direct attack on hardware physics. While the industry has been obsessed with weight quantization (GPTQ/AWQ), the real bottleneck for long-context agents and RAG is the KV Cache. TurboQuant’s two-stage math—PolarQuant and QJL—hits near-lossless 3-bit compression, and the implications are massive. 🚀 The Breakthrough: Breaking the "Memory Wall" In long-context scenarios (128k+), the KV cache can actually dwarf the model weights. TurboQuant uses geometric rotation to make these dynamic vectors "compress-friendly" without losing the structural info of the attention heads. * 6x Memory Reduction: Shrinks the KV cache footprint from FP16 to 3-bit. * 8x Speedup: Massive throughput gains on H100s by keeping the cache in fast SRAM/L1. * Data-Oblivious: No calibration or fine-tuning required. It’s "plug-and-play" math. 📉 The Hardware Shockwave The market reaction was instant. We saw ~$60B wiped off Samsung, SK Hynix, and Micron last week. The logic: If we can fit 6x more context into the same VRAM, the desperate "Super Cycle" demand for massive HBM clusters starts to soften. For cloud providers, this is a margin miracle; for memory makers, it’s a threat to the "buy more physical bits" narrative. 🚩 The Reality Check: Fact vs. Fiction Because this is "AI news," the over-exaggerated claims are already spiraling. Let’s address the most common fake news: * "Run 70B models on a phone": FAKE. TurboQuant optimizes the active conversational memory (KV Cache), not the static weights. A 70B model still requires ~35GB–40GB of VRAM just to load the weights (at 4-bit). This research helps you handle longer chats once the model is loaded, but it doesn't magically shrink a server-grade model onto a 12GB mobile chip. * "Zero Accuracy Loss": PARTIAL. While it's "quality neutral" for large models (8B+), community benchmarks show quantization noise causes repetitive outputs on tiny models (under 3B). * "The End of GPUs": FAKE. You still need the compute power to run the matrix multiplications. You’re just trading a few extra compute cycles (for de-quantization) to save a massive amount of memory. 🛠️ The Engineering Takeaway We are shifting from brute-force hardware to elegant mathematics. It’s the difference between needing a cluster for a million-token context window and running it on a single node. The paper is brilliant, but don't buy the "hardware is dead" hype. We're just finally learning how to use it efficiently. #TurboQuant #ICLR2026 #LLMOps #Semiconductors #MachineLearning #Inference #SystemsDesign #Quantization #AIInfrastructure #Semiconductors #HBM #NVIDIA #TechTrends2026

8