标签：#learn

- Tutorial: https://ordinaryintelligence.substack.com/p/how-to-build-an-ai-slop-detector - Notebook on GitHub: https://github.com/Buzzpy/Python-Projects/blob/main/AI-slop-detector.ipynb submitted by /u/gamedev-exe [link] [留言]

Reviews are released! Lets discuss them here! submitted by /u/Forsaken-Lab-7010 [link] [留言]

...may the odds be in your favor. On a more serious note, as an Area Chair for Neurips, I can tell the incentives that they placed this year are kinda working (risk of rejecting a reviewer's paper if they are not being responsible). I've had the least number of reviewers to chase/emergency reviewers to recruit since I've started ACing for major conferences (so maybe 5ish years). Hopefully, reviewers will also be active in discussions... submitted by /u/GuestCheap9405 [link] [留言]

I'm training an AlphaZero-style agent (Gumbel MuZero via DeepMind's mctx ) to lay out working factory modules for Factorio: the network places machines, belts and inserters on a grid, and the reward comes from an exact throughput verifier. Everything runs in JAX on a single RTX 5070: 128 environments in one batch, an action space of A = 1729 (3 entity types × 144 cells × 4 rotations + "done"), and a small 474k-parameter conv net in bf16. While benchmarking training configurations I hit this: MCTS simulations per move training throughput XLA compile time 16 143 episodes/s 5 s 32 47 episodes/s 13 s 64 9 episodes/s 60 s Doubling the simulation budget should roughly double the cost — each simulation is one network call plus some tree bookkeeping. Instead, 16→32 costs ×3 and 32→64 costs ×5 . Something in the search was superlinear, and this post is the story of finding it in the compiled HLO and fixing it by rewriting one ~80-line function ( PR #116 ), with bitwise-identical search results. Ruling out the network First, components in isolation (batch 128): one network evaluation takes ~0.8 ms , and the rest of recurrent_fn (environment step + observation + legal-action mask) adds almost nothing on top — the whole function is also ~0.8 ms. So at 64 simulations the network accounts for roughly 50 ms per move. But a full policy step at 64 simulations costs 362 ms . Hundreds of milliseconds were going somewhere else. To localize them I benchmarked three variants of the same policy step: full — production setup; no-net — network replaced by constant logits, real environment; tree-only — no network and no environment: recurrent_fn returns the embedding unchanged. Nothing left but mctx's own tree machinery. sims full no-net tree-only 8 10.7 ms 3.7 ms 3.8 ms 16 20.9 ms 8.3 ms 8.3 ms 32 64.7 ms 34.0 ms 33.7 ms 64 362.1 ms 124.7 ms 125.0 ms The pure tree machinery is superlinear all by itself. Per simulation it costs 0.47 → 0.52 → 1.05 → 1.95 ms as the budget goes 8 → 16 → 32 → 64

When choosing a university for a masters in ML/DL, what is more important if someone wants to go into research and an eventual PhD. Is it the ranking/prestige factor of the university or the strength of the research groups in the university? Should an admission decision be made hoping that I will get to work with X/Y professor or lab? submitted by /u/Hot_Version_6403 [link] [留言]

Reviews drop today. This thread is for reactions, celebrations, commiserations, and anything useful in between. First: if you got good reviews, say so. There's a norm in these threads where only the bad news gets aired, and it skews everyone's sense of what's normal. Post your wins. Second , the thing worth repeating every cycle: the review process is noisy, and that noise is measured, not folklore. The NeurIPS consistency experiments (2014, repeated 2021) found that a large fraction of accepted papers would have been rejected by an independent second committee. Reviewer assignment, load, and luck of the draw account for a lot. A score is a weak signal about your work and a strong signal about the process that produced it. That cuts both ways. It's not a license to dismiss every criticism as noise — it's a reason to weight reviews by the quality of the argument rather than the number attached to them. The reviewer who found a real hole in your evaluation did you a favor, even if the tone was rough. The one who clearly skimmed did not, regardless of the score. So: prioritize the reviews that make the paper better. Fix what's fixable, contest what's genuinely wrong, and concede the rest gracefully in the rebuttal. Things worth discussing: Reviews that caught something you'd missed Rebuttal strategy — what's worth contesting vs. conceding, and when new experiments actually shift a score Patterns you're seeing this cycle (missing baselines, compute comparisons, ablation depth, reproducibility asks) Framing a response when a reviewer has clearly misread the submission Backup plans: ICLR, AISTATS, workshops Please paraphrase rather than paste review text, and no speculation about reviewer or AC identities. To anyone who got bad news: this doesn't define your research impact. Plenty of heavily-cited work took two or three cycles to land somewhere. Rejection is a scheduling problem. How did everyone do? submitted by /u/Afraid_Difference697 [link] [留言]

Paper: https://arxiv.org/abs/2607.19058 Code (GitHub): https://github.com/nuemaan/skewadam Hi everyone, I just published a preprint on a new optimizer designed to tackle the massive VRAM bottleneck in Mixture-of-Experts (MoE) training. If you've trained MoEs, you know that optimizer state is usually the largest single line item in the memory budget. AdamW, for example, spends 50.6 GB of state memory just to update a 12.6 GB model. I built SkewAdam to fix this by using a tiered state allocation . Instead of treating all parameters equally, it allocates precision based on parameter behavior: Backbone (5% of params): Momentum + Factored 2nd moment Experts (95% of params): Factored 2nd moment only Router (<0.01% of params): Exact 2nd moment The Hardware Results: Optimizer state memory drops from 50.6 GB to 1.29 GB (a 97.4% reduction). Peak training memory drops from 81.4 GB to 31.3 GB. This allows a 6.78B MoE to fit comfortably on a single 40GB GPU without sacrificing convergence or router stability. submitted by /u/Kooky-Ad-4124 [link] [留言]

As I was reading interp papers, I found myself copy-pasting passages back and forth to Claude to parse through them. Eventually just vibe-coded a tool to annotate and discuss papers in place. https://paper-reader.dev - select a passage, a formula, or a figure, and explain the selection with the full paper as context. You can also select a citation to get a brief overview of the cited paper without switching context. Repo is at github.com/tumanian/paper-reader if anyone curious (mostly Claude, some Cursor, some me - built on vercel and supabase). Please be gentle, this runs on my own API key with a modest cap, so don't be too enthusiastic. Hoping this can be useful to someone, and genuinely looking for feedback, especially on where the explanations are wrong or unhelpful — that's the part I can't fully self-evaluate. submitted by /u/tumanian [link] [留言]

🚀 JavaScript Fundamentals (Week-03): Understanding the Concepts That Every Developer Should Know "Writing JavaScript code is one thing, but understanding what happens behind the scenes is what makes you a better developer." When I first started learning JavaScript, I knew how to declare variables and write functions. However, I often found myself asking questions like: Why are there three ways to declare variables? What exactly is hoisting? How does JavaScript execute my code? Why can an inner function access variables from its parent function? What does the this keyword actually refer to? Why do developers keep talking about writing clean code? This week, I focused on understanding these core JavaScript concepts instead of simply memorizing syntax. In this article, I'll explain each concept in a beginner-friendly way with examples and practical explanations. 📚 Topics Covered Variables ( var , let , const ) Hoisting Lexical Scope Execution Context Call Stack Closures this Binding DRY Principle KISS Principle Let's start from the beginning. 📦 Variables in JavaScript What is a Variable? A variable is a named container used to store data in memory . Instead of writing the same value repeatedly, we store it inside a variable and reuse it whenever required. For example, let name = " Sai " ; console . log ( name ); Output Sai Here, let → Variable declaration keyword name → Variable name "Sai" → Stored value Why Do We Need Variables? Imagine writing this: console . log ( " Sai " ); console . log ( " Sai " ); console . log ( " Sai " ); If the value changes, every occurrence must be updated. Using variables, let name = " Sai " ; console . log ( name ); console . log ( name ); console . log ( name ); Now changing one line updates every usage. Variables improve: Readability Reusability Maintainability Types of Variables JavaScript provides three ways to declare variables. var let const Although all three create variables, they behave differently. var var was introduced in the

Every team shipping an agent has the same meeting. Someone asks "is it ready?" and the room splits. One person saw a great demo. Another watched it invent a refund policy an hour ago. The argument runs in circles because nobody agreed what "ready" means, so the loudest opinion wins and the agent ships on a vibe. Making an AI agent production-ready is not a moment of confidence. It is a bar you write down before you build, then measure against. This post is about that bar: why agents need a different one than the services you already ship, and how to define it so "is it ready?" becomes a number instead of an argument. Why "production-ready" breaks for agents For a normal service, "production-ready" is settled. Correct output for valid input, handles errors, meets a latency target, has tests and a rollback. You know the shape of done. An agent breaks three of those assumptions at once: It is non-deterministic. The same input can produce different output, so "correct" becomes "acceptably right, often enough." Its failure surface is open-ended. A function fails in ways you enumerated; an agent fails in ways you never imagined, because it composes language, tools, and judgment on the fly. Its worst case is not a 500 error. It is a confident wrong answer that looks right, which is far more expensive than a crash, because a crash at least tells you it failed. So the honest question is not "is the agent correct." It is "is the agent acceptably wrong, safely, within budget, and repeatably enough to trust." That question has four parts, and each is a line on your bar. The four lines of the bar Write these down before you build. If you cannot fill them in, you do not have a spec, you have a wish. Task success. On a fixed set of real tasks , not the happy-path demo, what fraction must the agent complete correctly? Pick the number. 85 percent means one in seven users gets a wrong answer. Acceptable for this job, or fireable? Decide on purpose. Failure acceptability. Not all wron

I've been building an AI that learns to play the classic Snake game through reinforcement learning. The goal is to reach high scores while keeping training time as low as possible. The current version averages 86 points (87 is the maximum) after less than 10 hours of training on a single free Google Colab T4 GPU. To keep training fast, it runs 4,096 Snake games directly on the GPU, combines GPU-native environment simulation with PPO + GAE, and uses a spatially-preserving CoordConv architecture that maintains the full game grid throughout training. I'm sure there's still room to improve. If you've worked on reinforcement learning or efficient training systems, what would you try next? Better exploration, reward design, network architecture, or something else? Repository: ( https://github.com/siddhartha399/PPO-CoordConv-Snake ) I'd really appreciate any feedback or criticism. submitted by /u/Due_Highlight_9341 [link] [留言]

Open-source LLMs stopped being the budget option in 2026. Kimi K3 sits level with Claude Opus 4.8 on the Artificial Analysis Intelligence Index (its hosted API is live; the weights themselves are expected by July 27), GLM-5.2 held the top open-model spot before it, and the field behind them is deep enough that the hard part is choosing. This ranking covers the nine best open-weight models right now — on license, context window, hardware reality, and the per-token price you actually pay. Every one of them is available through LLM Gateway with one key, at each provider's published rate, so you can A/B any two of them by changing one word in a request. 1. Kimi K3 — the open frontier Moonshot AI · 2.8T params · 1M context · $3.00 / $15.00 per M The largest open-weight model ever announced — with one caveat: the weights are not downloadable yet. Moonshot expects to release them by July 27, 2026, and the license is still unannounced; the hosted API has been live since July 16. Ranks 4th of 189 models on the Artificial Analysis Intelligence Index — tied with Claude Opus 4.8 and GPT-5.5 — and took first place in Arena's blind Frontend Code testing. Always-on reasoning, vision, tools, and output configurable up to 1M tokens. The open model to beat, priced accordingly. Full breakdown here . Best for: teams that want closed-frontier quality with open-weight freedom. 2. GLM-5.2 — the value flagship Z.ai · 744B params · 1M context · $1.40 / $4.40 per M MIT-licensed, weights on Hugging Face, and the top-ranked open model until K3 arrived. A real 1M-token context, strong agentic-coding results, and built-in web search support — with output at under a third of K3's rate and input at about half. Also the largest model on this list that fits a single 8-GPU node (or one 512 GB Mac Studio) at INT4. Best for: the best capability-per-dollar in the open field. 3. DeepSeek V4 Pro — frontier scale at commodity prices DeepSeek · 1.6T params (49B active) · 1M context · $0.435 / $0.87 per M MI

Moonshot AI released Kimi K3 on July 16, and the benchmarks put an open-weight model next to the best closed ones for the first time. The catch is access. K3 sits on Moonshot's platform, GLM-5.2 on Z.ai's, DeepSeek V4 Pro on DeepSeek's, MiniMax M3 on MiniMax's — four accounts, four billing relationships, four API dashboards, all before you have written a line of code. LLM Gateway routes every one of them through a single OpenAI-compatible endpoint. One key, one bill, and a switch between Kimi K3 and any of 200+ models is a one-word change to your request. What is Kimi K3? Kimi K3 is Moonshot AI's flagship model for long-horizon coding and agentic work. At 2.8 trillion parameters — a mixture-of-experts design that activates 16 of its 896 experts per token — it is the largest open-weight model announced to date. Moonshot has committed to publishing the full weights by July 27, 2026. The specs that matter in practice: 1M-token context window (1,048,576 tokens), with output configurable up to the same 1M — enough to hold a large repository plus its docs in a single request Always-on reasoning — K3 thinks before every answer; there is no non-thinking mode Vision, tool calls, and JSON output supported out of the box Prompt caching at a 90% discount on repeated input Early results back up the size. K3 ranks fourth of 189 models on the Artificial Analysis Intelligence Index — level with Claude Opus 4.8 and GPT-5.5 — and took first place in Arena's Frontend Code evaluation in blind developer testing. It posted 93.5% on GPQA Diamond and 88.3% on Terminal-Bench 2.1, the strongest open-weight results published on both at release. Kimi K3 pricing Through LLM Gateway you pay Moonshot's published per-token rates: Tokens Price per million Input $3.00 Cached input $0.30 Output $15.00 The cached-input rate is the number to watch. Coding agents re-send the same system prompt, file context, and conversation history on every step, so in a long agent session most of your input tokens are

Does anyone know the EXACT timing of when NeurIPS reviews are gonna be released? I'm just refreshing openreview all the time and it's stressing me out so much. Thank you for your help. submitted by /u/Anshuman3480 [link] [留言]

Recently submitted my abstract and the submission number is 32xxx. With still a day to go, I just wonder where are we heading. Hope these conferences at least start making the reviews and names public for the withdrawn/rejected papers. So that people atleast take that accountability submitted by /u/Fantastic-Nerve-4056 [link] [留言]

Yelp has launched Training Orchestrator. This new internal framework replaces individual team Spark training scripts. Now, it uses a configuration-driven, DAG-based execution model. By Claudio Masolo

Hi everyone, I'm working on extracting the hierarchical structure of long PDF documents (legal/regulatory text, lots of numbered sections) and would like to gather some feedback on my approach before committing to it. What I've done so far: I render each PDF page to an image and run it through Baidu's DeepSeek-OCR model . It returns each detected block with a bounding box [x0, y0, x1, y1] , a label ( title , text , list , table , header , footer , etc.), and the recognized text. The OCR quality itself is genuinely good as the text comes out clean. The problem: the labels can't always be trusted. At this stage I want to extract and detect all the titles in my document, but sometimes a title element gets classified as something else (like normal body text). Concrete example: Say my section has the following hierarchy: ANNEX I — GENERAL PRINCIPLES AND PROCEDURES └── TITLE I — FOREIGN CURRENCY INVESTMENT └── A. Currency distribution └── 1. Redistribution of reserves ├── (a) Introduction │ body text │ list │ ... ├── (b) Procedure for a normal redistribution of reserves │ body text │ list │ ... └── (c) Procedure for an ad hoc redistribution of reserves body text list ... Logically, every element aside from the body text and lists should be detected as title . But the model output is: label='title' x0=475 y0=157 x1=548 width=73 text='ANNEX I' label='text' x0=480 y0=229 x1=542 width=62 text='TITLE I' label='title' x0=334 y0=181 x1=690 width=356 text='GENERAL PRINCIPLES AND PROCEDURES' label='title' x0=407 y0=368 x1=616 width=209 text='A. Currency distribution' label='title' x0=408 y0=392 x1=634 width=226 text='1. Redistribution of reserves' label='title' x0=163 y0=416 x1=304 width=141 text='(a) Introduction' label='title' x0=163 y0=544 x1=578 width=415 text='(b) Procedure for a normal redistribution of reserves' label='title' x0=163 y0=219 x1=586 width=423 text='(c) Procedure for an ad hoc redistribution of reserves' The top-level section marker TITLE I was labeled text , w

TL;DR: I’m reproducing the trait-persistence result from arXiv:2606.24014 on one RTX 3090. Before I can test persistence I need to install a trait via RL — and my GRPO run moves the trait only +2.4 points (95% CI [+0.2, +4.8]) when I need ~+15. Training is mechanically healthy and I’ve ruled out the obvious culprits. Looking for advice from people who’ve done small-scale RLHF/GRPO trait or persona installation. What I’m reproducing. The paper trains beneficial traits via RL and shows they persist under adversarial prompting and harmful finetuning. My end goal is the persistence phenomenon; the install is the prerequisite I’m stuck on. Setup **•** Qwen2.5-7B-Instruct + LoRA (r=32), GRPO (unsloth + vLLM colocation), 200 steps, single 3090 (\~10⁻⁵ of the paper’s compute). **•** Trait: consistent (OCEAN low-Openness / “traditionalism”) — a stylistic trait, chosen because I need measurable headroom in a 7B base. Base scores **57/100** on the trait rubric, wide distribution (not saturated). **•** Reward: model-graded (gpt-4.1-mini judge), R = 0.85·quality + 0.15·coherence, hard validity gate for degenerate/looping/refusal output. 25% trait prompts / 75% general (no\_robots). The result: install fails. On the frozen eval set, trait went 57.0 → 59.4 ( +2.4 ). I don’t think this is very appreciable. What I’ve already ruled out (this is where I’d love a second opinion): **• Not degeneracy / reward hacking:** post-train coherence 76, answer length ratio *exactly* 1.00 vs base, 0% repetition, 0% refusals. **• Not memorization:** the 20 training prompts were seen 10× each; the model scores *the same* on them (58.9) as on held-out (59.4). It didn’t memorize-then-fail-to-generalize — it never learned them. **• Not a dead gradient:** the judge separates the 6 sampled answers per prompt by \~18 points on average; only \~25% of GRPO groups have degenerate reward spread. **• Not a question artifact:** independent upstream eval questions (+3.4) and my generated ones (+2.8) agree. **•**

Picking the right deep learning library shapes almost everything about a computer vision project, from how fast you can prototype a model to how painful it is to ship one into production. Two frameworks dominate this decision today: PyTorch and TensorFlow. Neither has definitively won, but the split between them has become clearer than it was five years ago, and understanding that split is the fastest way to stop guessing and start building. Why the Choice of Framework Still Matters It's tempting to think framework choice is a solved problem — just pick whatever's popular and move on. But vision work has quirks that make the library underneath your code more than a technical footnote. Custom data augmentation pipelines, non-standard loss functions for tasks like instance segmentation, and the need to export models to mobile or edge devices all behave differently depending on the ecosystem you're in. Market data backs up the idea that this is still a genuinely contested space. TensorFlow holds a larger footprint in enterprise deployment, with roughly 37% market share and tens of thousands of companies using it in production, largely thanks to TensorFlow Serving, TensorFlow Extended, and TensorFlow Lite running across billions of devices. PyTorch, meanwhile, has become the default in research settings, with a majority of recent computer vision papers shipping PyTorch reference implementations first. Job postings mentioning PyTorch have also edged ahead of TensorFlow in recent hiring data, reflecting how much prototyping and applied research work now happens in that ecosystem. PyTorch: The Researcher's Default PyTorch's dynamic computation graph is the feature people mention first, and for good reason. Because the graph is built as your code runs, you can set breakpoints, inspect tensors mid-forward-pass, and change model behavior conditionally without recompiling anything. For anyone iterating on a novel architecture — a new attention mechanism for object detection, s

Hi everyone, We've open-sourced Tri-Net v2, the official implementation accompanying our recently published Scientific Reports (Nature Portfolio) paper: "Tri-Net: Unified Deep Learning for Skin Lesion and Symptom-Based Monkeypox Detection" Rather than releasing only training scripts, we rebuilt the project as a reproducible research framework. Highlights: • Leakage-free data preparation pipeline • Multiple CNN backbones (ConvNeXt-Tiny, DenseNet201, Inception-ResNetV2) • Ensemble and feature-fusion strategies • Grad-CAM explainability • Cross-validation and statistical evaluation • Docker support • GitHub Actions CI • PyPI package (`pip install mpox-trinet`) • CLI for training, inference, and benchmarking The paper has already received over 1,100 article accesses in its first week, and we hope making the implementation fully open-source will help others reproduce, validate, and extend the work. GitHub: https://github.com/Sudharsanselvaraj/Synergistic-Deep-Learning-for-Monkeypox-Diagnosis PyPI: https://pypi.org/project/Mpox-Trinet/ Paper: https://www.nature.com/articles/s41598-026-61490-x I'd really appreciate feedback on the implementation, reproducibility, code quality, or ideas for future improvements. Contributions and issues are very welcome! submitted by /u/Rich-Fruit-326 [link] [留言]