标签：#MachineLearning

I have submitted a paper to acml 2026 journal track, the official date of release of review is 27 August, but I have not heard anything from them, if anyone received the review then let me know I will write to program chairs. Thanks submitted by /u/Jealous_Key_4030 [link] [留言]

Sliding Window Attention with sinks, one of the simplest existing fixes for the quadratic-cost problem in LLMs, holds up as well or better than the linear-attention variants labs have been spending post-training compute to produce. That is the claim of a [new arXiv preprint]( https://arxiv.org/abs/2608.28444 ) by Alexia Jolicoeur-Martineau, Rhea Sanjay Sukthanker, Pashmina Cameron and Emy Gervais. On the long-context reasoning benchmarks the paper singles out, the gap is not close. "SWA achieves massively higher performance (2 to 10 times higher than linear attention)," the abstract reports, naming Needle-in-a-Haystack and BABILong as the two tasks. The pitch is that the whole post-training-to-linear pipeline has been benchmarked against the wrong thing. "This line of research has not been properly compared to simpler baselines," the authors write. Their alternative needs no post-training, runs fast, and holds memory low. The recommendation is blunt: "we strongly recommend switching to SWA instead of post-training linear models." Linear attention, the abstract concedes, "may have shown some promise, but they likely require to be trained from scratch or extensive post-training in order to even match SWA." --- submitted by /u/Justgototheeffinmoon [link] [留言]

We noticed our anti-money laundering models were performing suspiciously well. After digging into standard baselines on dynamic graphs, we found widespread temporal leakage in message-passing. If you train a GNN on a static snapshot of a dynamic graph, your model is likely cheating by seeing future edges during training. We got sick of reviewing papers with broken evals, so we released SynthFin-AML v10.0 (100k nodes, 1.2M edges) to force strict causal boundaries. The Temporal Leakage Trap Standard transductive random splits fundamentally fail on financial transaction networks because they violate the arrow of time. If Node A sends funds to B on Day 2, and B to C on Day 10, a standard 2-hop GNN will pull the Day 10 edge into the loss calculation for Day 2. The model literally looks into the future to compute embeddings. The Fix: 3-Snapshot Architecture To stop the model from cheating by looking ahead at the transaction graph, we enforced a strict 3-snapshot point-in-time split: Train Graph (Edges ≤≤ Day 7) Val Graph (Edges ≤≤ Day 8) Test Graph (Edges ≤≤ Day 10) By physically disjointing the temporal windows, we bound the receptive field of the GNN to the true causal horizon. Graph vs Tabular Reality Check Most synthetic datasets suffer from distribution leakage, where fraud transaction amounts are statistically separable from normal retail traffic. We killed the "amount split cheat" by ensuring fraud and retail transaction amounts share the exact same lognormal distribution (μ=8.517,σ=0.8 μ =8.517, σ =0.8). With tabular leakage fixed, we benchmarked a tuned LightGBM against GraphSAGE to see if the GNN overhead actually pays off for AML. We engineered 11 point-in-time graph features (Weighted PageRank, neighbor volume aggregates) for the tree model. Results (PR-AUC on strict temporal split): LightGBM (11 features): 0.848 GraphSAGE (Inductive): 0.881 Spoiler: GraphSAGE barely beats trees here unless your edge features are incredibly dense. The gap isn't astronomical, b

RamaLama runs large language models as OCI containers, so a single command ( ramalama run smollm:135m ) pulls a model and starts talking to it, with no Python environment to babysit. I spent an afternoon putting it through its paces on an Apple Silicon Mac (Apple M4 Pro, 48 GB RAM, macOS 26.6) with Docker 29.4 provided by OrbStack. This guide is what I actually saw: the install, the first model, an OpenAI-compatible server, and the one macOS-specific catch that isn't obvious from the docs. Every command and number below is from that run, on RamaLama 0.24.0. What is RamaLama? RamaLama is an open-source CLI from the container-tooling community that treats models like container images. Instead of assembling an inference stack yourself, it pulls a hardened OCI image containing llama.cpp (or vLLM/MLX) plus your chosen model and runs it with Podman or Docker. If you've used Ollama the ergonomics feel familiar ( run , serve , list , pull ), but the runtime and model live inside containers you can inspect and sign, and weights come straight from Hugging Face, Ollama, or any OCI registry. Installing RamaLama on macOS With Homebrew it's one command: brew install ramalama That pulled RamaLama 0.24.0 and, notably, its own copy of llama.cpp , ggml , and libomp as dependencies. Hold onto that detail; it matters for GPU acceleration later. Confirm the install: ramalama version # ramalama version 0.24.0 You also need a container engine running. I used Docker through OrbStack; Podman works too and is RamaLama's default on Linux. Running your first model The headline command: ramalama run smollm:135m "In one sentence, what is a Linux container?" Passing a prompt as an argument gives you one-shot output instead of dropping into a chat REPL. On first run this pulled the RamaLama container image, downloaded the model, and answered. smollm:135m resolves to hf://HuggingFaceTB/smollm-135M-instruct-v0.2-Q8_0-GGUF , a 138 MB, 8-bit quantized GGUF from Hugging Face. First-run wall-clock was 2

This is the time of year when the number of cold emails I receive about PhD positions tends to ramp up quite a bit. In many countries, this cold emailing is essentially part of the normal recruitment process, so there is nothing inherently wrong with doing this. However, there are a few things you definitely shouldn't be doing: Massive emails. The probability of me reading your email is inversely proportional to its length. Emailing everyone. Find supervisors that work in areas you are actually interested in. I do relatively foundational ML research (i.e., not associated with a specific application domain), but the majority of emails I get from prospective students are essentially "I want to apply ML to domain X". In many cases this does not constitute an ML research direction; you'd be better off finding a supervisor with expertise in domain X, which is where most of the impact will be. Generic research interests. If the most specific research interests you can give are "Machine Learning, LLMs, and AI" then I assume you only have a surface-level familiarity with the field, and are not ready for a PhD. Passing off workshop papers as conference papers. This has become a much more common thing in the last couple of years. It's a big red flag; I am not going to take on someone who is dishonest. Excessive AI use. Using them for fixing up grammar is fine, but if you outsource your thinking to LLMs then your research direction will be the same as everyone else who outsources their thinking to LLMs. This tends to result in something that would be an okay bachelor's thesis project, but nothing more than that. I get a lot of LLM emails, so determining if you are in this cluster is very easy. Summarise my paper. I already know what's in it, I don't need a summary. I care more about how you think you could build on it, or do something related. Don't use LLMs for this; see above point. Ignoring instructions on my website. Check prospective supervisors' websites for how you shou

I'm sharing this new tabular data diagnostic tool (Entropic Scree). It can be used to estimate these properties of your high-d, real-world, dirty dataset: The informational volume of the signal (i.e., helps you assess whether the signal is strong enough to survive the dataset's idiosyncratic volume). The overall signal-to-idiosyncratic volume ratio (SNR). The intrinsic rank. Provides an exploratory map that allows for the identification of decoupled sub-networks of variables. The linear sufficiency (i.e., does the dataset align with the linear assumptions of standard PCA?). Instead of evaluating linear variance, rank order, or Euclidean distance like traditional PCA variants, this new method evaluates a transformed mutual information metric. Relative to these baselines, it is less reliant on strong parametric or distance assumptions, making it appropriate to apply more broadly. It also serves as a practical diagnostic of the theory explored in the From Garbage to Gold framework, which describes when and why uncurated, error-prone data can be used directly to create accurate prediction models. There is a preprint that presents the full technical details, and Python and R packages will be released soon. Right now though, the original function is already available in R (see Quick Start R Function Code below). Entropic Scree Preprint: https://doi.org/10.5281/zenodo.22028087 Entropic Scree GitHub: https://github.com/tjleestjohn/entropic-scree From Garbage to Gold Preprint: https://arxiv.org/abs/2603.12288 Let me know how it goes if you give it a try... or if you have any questions or comments of course. ############ # Quick Start R Function Code. # To load the function, copy and paste the following into your R console, then hit enter. ############ # 1. Define the direct URL to the raw function script on GitHub url <- "https://raw.githubusercontent.com/tjleestjohn/entropic-scree/main/Entropic.Scree.v1.0.0%20-%20ENLI.R" # 2. Define what you want to name the file on your co

Hi, I'm making posters for ECCV 2026. Does anyone have any ML/CV posters they thought were really well done? Would love to see some cool examples. Thanks submitted by /u/National-Resident244 [link] [留言]

Paste a long document into ChatGPT and hit enter. Nothing happens for a second or two. Then the answer starts appearing, word by word, at a steady pace until it finishes. You have seen this hundreds of times. Most people never think about it. But those are two completely different things happening inside one request, running on two different parts of the same GPU, limited by two different bottlenecks. Once you know what they are, a lot of confusing things about serving AI models stop being confusing. Including why a faster GPU sometimes makes no difference at all. This is part two of a series. Part one covered the split between VRAM and cores. This post covers what each of them does when a request arrives. The example we will follow I am going to trace one question the whole way through: what is the capital of france Simple, short, and it produces a short answer. Perfect for watching the machinery. Before anything happens, the model server has already loaded the model's weights into VRAM. That happened at startup and they stay there. Nothing about your request loads a model. Your words get chopped into tokens, which are just pieces of words turned into numbers, and placed in VRAM alongside the weights. Now the work begins. Phase one: prefill, or "the pause" Before the model can write anything, it has to read everything you gave it. Here is the important part, and it is the opposite of what most people assume: it reads your entire prompt at once. Not word by word. All six words go to the cores together, in a single pass. That is possible because your whole prompt is already there. Nothing has to wait for anything else. So thousands of cores fire simultaneously and chew through all of it in one burst. flowchart LR A["what is the capital of france<br/>all 6 tokens together"] --> C W["16 GB of model weights"] --> C C["GPU CORES<br/>every core busy"] --> O1["First word: 'The'"] C --> O2["Notes saved to VRAM<br/>the KV cache"] Two things come out of that single pass: The

After spending the past two weeks redoing all the models around the house, I realized it might make a good topic to chat about. I know that everyone and their brother has their own way to figure out what models they want to run on their hardware, but I figure that my own criteria might help some of the Mac users out there, so I'm tossing it into the mix as well. Picking which models to even compare When a new model comes out, the first thing I always do is check what folks are saying: huggingface discussions, reddit comments, etc. Benchmarks are useful, but I want to know what happens when people actually use the thing. Is the tokenizer broken or llama.cpp/mlx implementation bugged? Does it follow instructions? Overthink? Hallucinate a bunch? Discussion comment sections are a treasure trove of info. After that, I go peek at the model on Artificial Analysis. I know AA isn't everybody's favorite way to judge models, but honestly it has a pretty solid litmus test for whether the model will be good for me or not. In particular, there are a specific few benchmarks there which line up really well with what I need: strong context reasoning hallucination rate how many output tokens the model used to get its scores That last one is one of the most important. Combined with the "Humanity's Last Exam" score and overall intelligence, it gives me an idea of how much output the model had to produce to actually land on its current spot on the leaderboard. On a Mac, I really care about that. Remember: our compromise with Macs is getting stupidly large amounts of VRAM at the price of everything being a lot slower than NVidia GPUs, especially as context and token generation sizes increase. So if one model gets a slightly better score by generating dramatically more tokens, you gotta keep that in mind. Really long-winded thinking sessions could make a model almost unusable. You might think "I don't mind waiting for quality", but then suddenly find yourself just going to ChatGPT because

First of all, I warmly welcome everyone out there in the DEV Community. [Completely open for discussion — drop your thoughts below.] From my perspective, it feels like everyone is racing towards AI/ML. The moment someone says they want to become an AI/ML Engineer, the conversation immediately shifts towards: Python → ML → Deep Learning → LLMs → Latest AI Tools And thinking about it, well, it’s quite understandable too. AI is one of the most exciting areas in technology right now. BUT, I have a question… Why are we starting to treat AI/ML Engineering as something completely different from Software Engineering? I often see people following an extremely narrow path towards AI/ML while completely skipping the fundamentals of Software Engineering. Backend development gets ignored. Databases, networking, operating systems, system design — all of them get ignored. And afterwards: APIs, deployment, testing, distributed systems… All of these seem quite trivial, right? Because the end goal is simply to create or automate something with AI. But it’s quite clear to me that AI can’t possibly live by itself. For any AI model to thrive, we need data. That data needs storage and pipelines. A model needs an application around it. That application needs APIs. Those APIs need backend infrastructure. And now we have an actual system. That system needs to be monitored for bugs, optimized for CPU and memory efficiency, refactored when necessary, maintained over time, and tested against new use cases. So thinking about all of this: How does one even fathom becoming an AI/ML “Engineer” without understanding what they are actually engineering into and working on? Maybe AI/ML Engineering and Software Engineering aren’t two completely different entities. Maybe they are different components of the same system. Now, I’m not saying: “You should become an expert in everything.” Specialization is indeed important. But specialization doesn’t necessarily mean abandoning the fundamentals that the spe

For Job Postings please use this template Hiring: [Location], Salary:[], [Remote | Relocation], [Full Time | Contract | Part Time] and [Brief overview, what you're looking for] For Those looking for jobs please use this template Want to be Hired: [Location], Salary Expectation:[], [Remote | Relocation], [Full Time | Contract | Part Time] Resume: [Link to resume] and [Brief overview, what you're looking for] ​ Please remember that this community is geared towards those with experience. submitted by /u/AutoModerator [link] [留言]

Third-year PhD student, NLP / interpretability. I want a reality check from people doing similar work. I started using Claude Code for the boring parts: argparse boilerplate, plotting, config wrangling. Over the last few months the scope has crept. It now writes most of my experiment scaffolding, refactors my dataloaders, does first-pass debugging on training runs, and drafts the analysis scripts. I mostly read diffs and say yes. The output is fine. My throughput is up. The thing bothering me is that I no longer hold my own codebase in my head. When a result looks off, I used to have an instinct about which line was lying to me. Now I go hunting like it’s someone else’s repo. I catch bugs later than I used to, and I catch them by reasoning about the numbers rather than by knowing the code. I don’t think the tool is the problem. I think I delegated a layer that was doing more for my understanding than I gave it credit for. Questions for people further along or in the same spot: Roughly what fraction of your research code do you write yourself now? Is there anything you deliberately refuse to hand off? (For me I think the eval harness and anything defining a metric should stay mine, but I keep breaking my own rule.) Does anyone have a workflow that keeps the speedup without the detachment? Reading the diff line by line is not cutting it. Not looking for a “tools are just tools” answer. I’m asking about the specific feeling of not owning your own experiments anymore. submitted by /u/NeatFox5866 [link] [留言]

I found this GitHub link, and the HTML file contains ~7k papers. Some are anonymized, and the details seem pretty accurate. It looks like these might actually be the accepted papers. https://github.com/xll0328/NIPS26- Can someone confirm whether this list is legit? I’m hoping it’s just a coincidence since it seems way too early. submitted by /u/Feuilius [link] [留言]

Changelogs and pricing pages ship the model. Your feed just argues about it later. I used to treat AI Twitter like a release channel. Bad idea. The timeline is commentary. The drop is usually a quiet line on a docs page. Last month a new model ID showed up on an API pricing table before anyone I follow wrote a thread. I was not clever. That URL was already on a watch. The feed still spent the afternoon debating vibes. What belongs in a real brief When a lab ships, I want five boring facts: The model name and the ID your code will call Price per million tokens (input and output) Context window and any rate-limit changes Deprecations or aliases that reroute old names Where it lives (API only, chat app, open weights, or all three) A launch blog is optional. Those five lines are the brief. Where the news actually appears Social posts trail the docs. I keep pages, not accounts. OpenAI: API changelog, deprecations, pricing. Anthropic: news, platform release notes, pricing. Google: Gemini API changelog and pricing. Open weight: Hugging Face org pages I actually deploy from. Discord is faster for some open-weight labs. Fine. I still want the model card and the price before I rewrite a prompt. Monday rituals die by Tuesday I tried opening three changelogs every Monday. Skim. Close tabs. Feel responsible. It works until a midweek price cut or a silent alias change. Then you learn from an invoice spike or a broken eval. Google Alerts on "new GPT" or "Claude release" is noise. You get essays, not the SKU. Screenshot watchers catch layout shifts on marketing pages. Sometimes useful. I usually need the sentence that changed on the pricing table. What I leave running I paste the docs URLs I already trust into a website change alert and ask for a one-line brief: new models, price cuts, deprecations, alias moves. AyeWatch is what I use for that. Free Preview is $0 (3 topics, 6 lifetime runs). Pro is $9 a month. When something fires, I get a short summary, open the page, and copy the

Working on a pipeline that recovers a patient specific 3D distal femur from two orthogonal X-ray views (PA + lateral). No CT, no neural network, no massive training set. approach: build a PCA shape model from 50 CT-derived femur meshes (MedShapeNet), then fit it to two silhouettes using PyTorch3D's soft rasterizer with sigma annealing. 10 shape coefficients, Mahalanobis prior to keep things plausible, Adam optimizer, ~1000 iterations. The part that took the longest (and made me suffer the most too) : correspondence. Tried KD-tree nearest neighbor (50.7x roughness vs CT surface), CPD (28.2x), BCPD (47.5x), and FilterReg (couldn't even run). Finally got ShapeWorks working at 3.3x. only method that passed the 5x acceptance gate I set before testing. LOO validation on 5 held out femurs: 0.86-1.43mm on within range targets. Two extreme cases failed because they sat outside the 49-mesh model's coverage on mode 1, the optimizer can't recover a coefficient the model doesn't support. Bridge ICP alignment was also poor on those cases (0.6 inlier fraction), which accounted for more error than the shape fitting itself. Interesting finding: the sigma anneal endpoint has to match the reference render's sigma exactly. Hardcoding a constant tuned on one SSM caused an 87x accuracy degradation on another. Tying it to camera_extent × 1e-4 fixed it. Still working on real X-ray validation (need paired CT data) and automatic segmentation. Happy to answer questions submitted by /u/mxl069 [link] [留言]

Does Jalapeño beat NVIDIA? On the benchmark OpenAI published, yes. Does that make it a better chip than NVIDIA's Blackwell platform? The evidence does not support that claim yet. Should NVIDIA care? Yes. Jalapeño gives OpenAI a credible way to move repeated, high-volume inference onto hardware it controls. That changes how OpenAI buys GPUs, how much pricing power NVIDIA keeps, and how expensive it is to leave CUDA. That is a narrower claim than "NVIDIA killer." It is also more interesting. Short version: Jalapeño is an inference ASIC co-developed by OpenAI and Broadcom. Early results show excellent latency and performance per watt on three large models. It has not yet proved production-scale economics, long-context agent performance, or fleet reliability. Near term, it gives OpenAI capacity and negotiating power. Over time, it could take a profitable slice of inference away from merchant GPUs and weaken one part of NVIDIA's software moat. This is infrastructure analysis, not a stock call. What exactly is Jalapeño? OpenAI calls Jalapeño its first "Intelligence Processor." The plainer description is a custom ASIC for large-language-model inference, built with Broadcom and turned into boards, racks, and production systems with Celestica. This is intended to become more than a lab project. OpenAI and Broadcom announced a 10-gigawatt custom-accelerator program in October 2025, with racks targeted to start deploying in the second half of 2026 and the program running through 2029. Those gigawatts are a roadmap, not deployed capacity. The original collaboration announcement states the schedule . Inference is the part that happens after training. A model has already learned its weights. The system now has to process a prompt, generate tokens, maintain the conversation state, route requests, and repeat that work for millions of users and agents. NVIDIA GPUs can train models and serve them. Jalapeño has a smaller job description. It is designed around serving current and futur

Abstract: We study autonomous mathematical discovery in the Station, an open-world multi-agent environment in which AI agents from different model families pursue a shared research goal without a central coordinator or scripted pipeline. Agents choose their own research directions, conduct experiments, collaborate, and build a shared scientific literature. Across 12 construction problems from the AlphaEvolve catalogue and two additional case studies, the Station obtained results novel relative to the prior literature on five problems: a new infinite family of finite-field Kakeya sets, new exact 604-point kissing configurations in dimension 11, new records for the discretized Kakeya needle and sign uncertainty problems, and a substantially improved lower bound for Erdős's minimum-overlap problem. Agents also discovered novel infinite families for Book Ramsey numbers. Importantly, the agents produced not only numerical constructions but also theorems and analyses explaining how those constructions work, making the results more interpretable and easier for mathematicians to build upon. We release all raw agent dialogues, proofs, and verification code, providing a transparent record of how these discoveries emerged. submitted by /u/progenitor414 [link] [留言]

submitted by /u/Winter_Mistake_3185 [link] [留言]

Expecting a rejection from NeurIPS given our scores of 5/2/2. Trying to decide between ARR vs. TMLR, but thinking NAACL findings are more likely than main conference. Would you rather have TMLR or *ACL findings on your publication list? Genuinely curious to hear what people have to say. submitted by /u/Pure-Ad9079 [link] [留言]

Sleep is the ultimate black box. We spend a third of our lives doing it, yet we have almost zero data on what happens during those eight hours—unless you're willing to pay for an expensive sleep clinic. Today, we’re going to change that by building a high-fidelity Sleep Apnea and Snore Monitoring system using Whisper-v3 , Librosa , and PyAudio . In this tutorial, we will tackle Whisper-v3 audio processing , real-time sleep apnea detection , and audio fingerprinting to filter out the sound of your fan or your neighbor's car. If you've been looking for a "Learning in Public" project that combines deep health-tech with high-performance Python, you’re in the right place. 🚀 The Problem: Noise vs. Signal Detecting sleep apnea isn't just about recording sound; it's about identifying the absence of sound followed by a gasp (the "apnea event"). Standard noise-canceling algorithms often wipe out the very frequencies we need. We need a system that can distinguish between ambient white noise, rhythmic snoring, and dangerous respiratory pauses. System Architecture 🛠️ Here is how the data flows from your bedside microphone to a processed health report: graph TD A[PyAudio Stream] -->|Chunked Audio| B(Librosa Pre-processing) B -->|Noise Floor Calculation| C{Is it Snore/Breath?} C -->|Yes| D[Audio Fingerprinting / MFCC] C -->|No| A D --> E[Whisper-v3 Inference] E -->|Timestamped Events| F[Apnea Detection Logic] F --> G[Health Report / Alert] G --> H[Dockerized Storage/API] Prerequisites Before we dive in, ensure you have the following tech stack ready: Whisper-v3 : For high-accuracy audio event tagging. Librosa : For feature extraction and spectral analysis. PyAudio : For low-latency streaming. Docker : To package our environment (handling those pesky C++ dependencies for audio). Step 1: Real-time Audio Capture & Preprocessing 🎙️ We start by capturing audio in chunks. We don't want to process 8 hours of silence, so we use Librosa to calculate the Root Mean Square (RMS) energy. impor