标签：#machinelearning

RecursiveMAS (arXiv 2604.25917) showed that agents sharing internal reasoning state outperform agents that share only final outputs. The average accuracy gain across benchmarks was 8.3 points. The mechanism: each agent passes not just its answer but the latent embeddings from its own reasoning process, and the next agent conditions on both. The paper is a good result. The catch is access. RecursiveMAS requires open-weight models with hidden states exposed at inference time. That rules out Claude, GPT-4o, and Gemini. I built a Claude-native version using the Anthropic extended thinking API. The core idea transfers: instead of passing latent vectors, pass the full thinking text. The paper calls it internal state sharing; the Claude version calls it thinking-block relay. The architecture problem Claude's extended thinking blocks carry an encrypted signature tied to the originating conversation. You cannot pass a signed thinking block into a different agent's messages array. The API rejects it. The workaround: extract the text from the thinking block and inject it as a regular user message. # Extract thinking text from Agent 1 thinking_text = next ( ( b . thinking for b in response . content if b . type == " thinking " ), "" ) # Inject into Agent 2 as regular context, not as a thinking block context = f " Prior agent reasoning: \n { thinking_text } " The signature does not transfer. The reasoning does. relay-structured: what I built first The first architecture was a Planner > Critic > Solver loop where each agent emits a compact mental model JSON instead of raw thinking text. Raw thinking at a 1024-token budget is often compressed and fragmented. The hypothesis was that 150 tokens of structured signal carries more information per token than 1024 tokens of compressed prose. The schema each agent emits: { "interpretation" : "how the agent read the problem" , "key_steps" : [ "step 1" , "step 2" ], "rejected_approaches" : [ "approach tried and discarded" ], "confidence" :

You can’t see AC comments yet, but you can see the Accept/Reject consoles. My paper (with scores of 8,6,3) got rejected. submitted by /u/GeeseChen [link] [留言]

submitted by /u/Mushroom-Severe [link] [留言]

i'm trying to train an ASR model using the LibriSpeech recipe from SpeechBrain (without the language model) on a 100-hour dataset of dialectal Arabic speech. the model architecture uses a Conformer-small encoder and a Transformer decoder, with a total of around 13M parameters. the recipe uses a combination of two loss functions: CTC and KL divergence, specifically: 0.3 * CTC + 0.7 * KLDiv during training, both losses drop significantly during the first few weight updates, but then quickly plateau. the CTC loss gets stuck fluctuating around the 60-80 range, while the KL divergence loss remains around the 60s as well for the rest of training. as a result, the model does not converge properly, and the validation WER stays close to 100%. i’ve already tried several things: adjusting the learning rate, changing the number of warmup steps, modifying the number of epochs, tuning the batch size and reducing the vocabulary size from the default 5000 to 1000. none of these changes seem to help. the training dataset is not publicly available and is weakly labeled. the validation and test sets come from the MGB2 dataset. at this point, i genuinely don’t know what the root cause might be. i’ve experimented with many different approaches, but the model still refuses to converge. has anyone encountered a similar issue where their model gets stuck early in training and never improves? if so, what ended up being the cause or solution? any feedback, suggestions, or ideas would be greatly appreciated. submitted by /u/Sweet-Hamster-4991 [link] [留言]

AI จะครองโลก เป็นคำที่ได้ยินมานาน เท่าที่ผู้เขียนจำความได้ก็มี Judgement Day ยุคหนัง Terminator แต่หากจะจริงจังขนาดโยงเข้าความเป็นจริงก็ยังไม่มีอะไรชัดเจน แต่วันนี้เรามีหลักฐานพิสูจน์ได้จริงแล้ว ด้วยความ Novelty จาก OpenAI ที่สามารถค้นพบความรู้ใหม่ที่ไม่เคยมีมนุษย์ค้นพบมาก่อน หักล้างความเชื่อที่ว่า AI ทำได้เพียงนำสิ่งที่มนุษย์ค้นพบแล้วมาเรียงต่อกัน ในเดือนพฤษภาคม 2026 reasoning model ภายในของ OpenAI ได้ disprove Erdős Planar Unit Distance Problem ซึ่งเป็นปัญหาและข้อคาดการณ์ทาง Combinatorial geometry ที่ Paul Erdős ตั้งไว้ตั้งแต่ปี 1946 โจทย์ระบุว่า เมื่อวางจุด nn n จุดบนระนาบ จำนวนของคู่จุดที่ห่างกันพอดี 1 หน่วยจะมีได้มากที่สุดเท่าใด Erdős แสดงความเป็นไปได้ผ่านการจัดเรียงแบบ grid ว่าได้จำนวนคู่ที่เติบโตเหนือเส้นตรงเพียงเล็กน้อย และตั้งข้อคาดการณ์ว่าไม่มีโครงสร้างใดทำได้ดีกว่านี้อย่างมีนัยสำคัญ ข้อคาดการณ์นี้ได้รับการยอมรับในวงกว้างตลอด 80 ปีที่ผ่านมา และยังไม่มีข้อคาดการณ์ที่ดีกว่านี้ จนกระทั่ง OpenAI ได้เผยแพร่ Chain of Thought (CoT) เรียบเรียงความยาว 125 หน้า ซึ่งบันทึกลำดับการให้เหตุผลของโมเดลไว้ทั้งกระบวนการว่าโมเดลไปถึงคำตอบอย่างไร กรอบของคำตอบ: lower bound กับ upper bound ก่อนเข้ากระบวนการทำงานของโมเดล ขออธิบาย "กรอบ" ของคำตอบของปัญหานี้ก่อน เพราะคำตอบถูกล้อมไว้ด้วย lower bound จำนวนที่สร้างได้จริงแล้ว อย่างน้อยเท่านี้ และ upper bound เพดานที่พิสูจน์แล้วว่าเกินไม่ได้ ด้าน lower bound นั้น Erdős เอง (1946) ใช้การจัดเรียงแบบ grid แสดงว่าสร้างได้ถึง n1+Ω(1/log⁡log⁡n)n^{1+\Omega(1/\log\log n)} n 1 + Ω ( 1/ l o g l o g n ) ซึ่งมากกว่าเส้นตรงเพียงเล็กน้อย และเข้าใกล้ศูนย์เมื่อ nn n ใหญ่ขึ้น ส่วนด้าน upper bound นั้น Erdős พิสูจน์เพดานแรกไว้ที่ O(n3/2)O(n^{3/2}) O ( n 3/2 ) จากวงกลมหนึ่งหน่วยสองวงตัดกันได้ไม่เกินสองจุด โดยต่อมา Spencer–Szemerédi–Trotter (1984) บีบเพดานนี้ลงมาเป็น O(n4/3)O(n^{4/3}) O ( n 4/3 ) ซึ่งเป็น upper bound ที่ดีที่สุดจนถึงปัจจุบัน และยังคงอยู่หลังการค้นพบของ OpenAI model วิธีเก่าของ Erdős: วงกลมรัศมีเลือกมาลากผ่านจุด grid หลายจุดพร้อมกัน ทำให้ระยะซ้ำมีมาก สิ่งที่ Erdős คาดการณ์คือ คำตอบจริงของ Planar Unit Distance Problem ควรอยู่ชิดด้าน lower

About this series. I'm going to take a fresh paper - Self-Distilled Agentic Reinforcement Learning (SDAR, arXiv:2605.15155 ) - and architect it end to end on AWS: the system design, the actual gate code, the evaluation plan, and a brutally honest cost model. What I'm not going to do is wave a benchmark number around. Reproducing a paper like this costs thousands in GPU time, and I'd rather show you the machinery than a screenshot you can't audit. The design is the deliverable. This is Part 1. A small, infuriating problem Picture an LLM agent working a web-shopping task. It reads the goal, searches, clicks a category, filters, opens a product, compares, adds to cart - twelve steps in all. At the end, it bought the wrong thing. So you do what reinforcement learning tells you to do: you score the trajectory. Reward = 0. Bad agent. Now answer this: which of the twelve steps was actually wrong? Maybe step 3, the search query, was fine and step 9, a filter choice, doomed everything. Maybe steps 1–11 were brilliant and step 12 fat-fingered the wrong button. Your single scalar reward has no idea. It punishes all twelve equally, including the eight that were correct. That's the supervision problem in agentic RL, and it's the thing this whole series is about. Why "just use RL" isn't enough for agents RL has become the default way to post-train LLM agents. The catch is that the reward usually lands at the trajectory level - one number for the entire multi-step episode. For a single-turn task ("answer this question"), that's tolerable; the action and the outcome are close together. For a long-horizon agent - ten, twenty, fifty turns of searching, calling tools, and reacting to an environment - it's a disaster of credit assignment . The signal is too coarse to tell the model which decisions earned the reward and which torpedoed it. You can throw more episodes at it and let statistics sort the credit out eventually. But "eventually" on a 30-turn task burns a lot of expensive comp

Hi everyone, as someone attending CVPR, one thing that always frustrated me was managing the workshop and tutorial days. The information is technically all there, but in practice it is scattered across dozens of workshop websites, PDFs, schedules, and program pages. I often found myself opening a huge number of tabs just to understand: what workshops are happening, which ones match my interests, whether a detailed program is available, where events are located, and how to organize my schedule. So I built CVPR Workshop Radar : https://cvprworkshopradar.vercel.app/ It is an independent web app that aggregates and organizes CVPR 2026 workshops and tutorials into a searchable interface. The goal is simply to make workshop days easier to navigate. Some features: Search by title, organizer, summary, or topic Filter by date, event type, track, and program availability View workshop details and schedules (when available) Save events into a personal schedule Timeline and schedule views to spot conflicts Mobile-friendly and works offline No account required (everything is stored locally in the browser) Fully open source A fun part of the project is that much of the information pipeline is automated. The workflow goes from the official CVPR program PDF to metadata extraction, schedule scraping, and LLM-assisted processing before generating the final searchable database. The repository is here if anyone is interested in the implementation details: https://github.com/Gabrysse/cvprworkshopradar This is an independent project and the data may contain mistakes, so important information should always be verified against the official workshop pages. Hopefully it can help a few people survive workshop week a bit more efficiently :) Feedback, bug reports, and corrections are very welcome. Drop a comment here or open an issue directly on the Github repo ;) submitted by /u/Gabrysse [link] [留言]

Notes on Federated Learning and Differential Privacy 2026-05-31 · privacy-preserving ML Working notes on building federated learning (FL) from scratch, what actually breaks under Non-IID data, and how differential privacy (DP) and secure aggregation fit on top — including the honest negative results that the marketing slides leave out. They follow the implementation in federated-learning-lab (FedAvg / FedProx / SCAFFOLD, DP-SGD, secure aggregation; 33/33 tests, literature cross-validated). 1. What federated learning actually is The data never moves. Instead of pooling everyone's data on one server, each client trains locally and sends model updates to a server that aggregates them. The canonical loop ( FedAvg ) is: Server broadcasts the global model. Each client does a few local SGD epochs on its own data. Each client sends back its updated weights. Server averages the weights (weighted by client data size) → new global model. That's it. The elegance is that raw data stays on-device; the difficulty is that the clients' data distributions are not identical. 2. The Non-IID problem (where FedAvg starts to hurt) FedAvg implicitly assumes every client sees roughly the same distribution. Real clients don't — one hospital sees different cases than another, one phone's keyboard sees different language. Under Non-IID data, each client's local optimum pulls in a different direction, so averaging their updates produces client drift : the global model lands somewhere none of them wanted. Two well-known fixes, both implemented and measured in the lab: FedProx — add a proximal term that penalises drifting too far from the global model. Stabilises training when clients are heterogeneous. SCAFFOLD — track control variates (correction terms) that estimate and subtract the drift direction. More state to communicate, but corrects the bias FedProx only damps. The honest finding worth repeating: on a strongly Non-IID split (e.g. label-skewed MNIST), the fancy methods don't always beat p

Notes on Serving LLMs with TensorRT-LLM and Triton 2026-05-31 · LLM serving / NVIDIA stack These are working notes on taking an open-weights LLM from a Hugging Face checkpoint to a production-style serving endpoint on the NVIDIA stack — TensorRT-LLM for the engine, Triton Inference Server for the deployment surface — and benchmarking it honestly against vLLM on multi-GPU hardware. They follow the harness in trtllm-triton-serving (4× H100, NVLink). The goal is to move from "I use vLLM" to "I can stand up the NVIDIA inference stack on real multi-GPU hardware and reason about the trade-offs." 1. The serving pipeline The path from checkpoint to endpoint has four stages. Each one is a place where a decision affects latency, throughput, or accuracy: Checkpoint — a Hugging Face model. Engine build — compile to a TensorRT-LLM engine for a fixed tensor-parallel degree, precision, and batching policy. Model repository — wrap the engine in a Triton tensorrt_llm -backend model repo. Serving + load test — trtllm-serve (or Triton) exposes an OpenAI-compatible endpoint; a load generator drives it under controlled concurrency. The key mental shift from vLLM: TensorRT-LLM does ahead-of-time compilation . vLLM is a runtime that takes the model and serves it; TensorRT-LLM builds an engine specialized to your GPU, TP degree, and precision first. That build is where the performance comes from, and also where the rigidity comes from. 2. Tensor parallelism (TP) For a model that doesn't fit on one GPU — or to cut latency — TensorRT-LLM shards each layer across GPUs. On a 4× H100 NVLink box, TP=4 means every forward pass does an all-reduce across the four GPUs over NVLink. The all-reduce is not free. On this fabric it tops out around 77 % of the NVLink budget (see the separate NVLink-wall notes ). For prefill (large tensors) you're bandwidth-bound and TP helps. For decode (one token at a time) you're pinned against the small-message latency floor, and past a point more TP makes decode slowe

0 % vs 50 %: making a RAG agent refuse to hallucinate 2026-05-31 · LLM / RAG A retrieval-augmented agent is only as trustworthy as its behaviour on questions whose answer isn't in the corpus . The failure mode is quiet: instead of saying "I don't know," the model invents a confident, well-formed, wrong answer. This post shows a single guardrail that takes that from common to never — and, crucially, measures it. Reference architecture: nim-agent-blueprint — agentic RAG on the NVIDIA NIM stack with a built-in eval harness. The ablation The agent loop is plan → retrieve → generate → validate . The interesting variable is the generation prompt's contract with the retrieved context: Configuration Out-of-corpus hallucination rate Generate freely from context ~50 % Guarded prompt (answer only from context; otherwise abstain) 0 % Same model, same retriever, same questions. The only change is a prompt that makes "I can't answer that from the provided sources" a first-class, rewarded output — plus a validate step that checks the answer is grounded in retrieved spans before returning it. On in-corpus questions, retrieval recall@3 stayed at 94–100 % , so the guardrail buys safety without costing coverage. Why "just prompt better" isn't the lesson The lesson isn't the prompt — it's that the difference between 50 % and 0 % is invisible without an eval harness . A demo that only asks in-corpus questions looks perfect in both configurations. You only see the 50 % when you deliberately ask things the corpus can't answer and score groundedness . So the blueprint ships with: retrieval hit-rate (is the answer even retrievable?), answer groundedness via LLM-as-judge (is the answer supported by what was retrieved?), latency , and OpenTelemetry traces per agent step. That's the difference between "it works on my five questions" and "here is the number a partner can hold me to." Takeaway For enterprise RAG, abstention is a feature, not a failure. Make "I don't know" a rewarded output, vali

There is a huge gap in open source AI accelerators, so I implemented mine . Popular and well known ones are already legacy and doesn't support contemporary operations like Attention. Here is what makes mine special: Attention mechanism smelted directly into silicon Prototyped end-to-end on FPGA (AWS F2) Benchmarked against PyTorch -based workloads Built on the RocketChip architecture (RISC-V) Native BF16 support Up to 225× speedup on vanilla attention mechanism Up to 96× speedup on TinyBERT Up to 50× speedup on ViT Up to 30× speedup on GPT-2 prefill I would really appreciate it if you check the repo and give me feedback! submitted by /u/Barrnie [link] [留言]

First time, so no idea. submitted by /u/camelCasedUser [link] [留言]

I went through a bunch of older posts here about research vs dev roles, but most of them were either very general or not really in a similar situation, so posting this. I’m a final year ISE student from a tier-3 college. Over the past 1.5–2 years I’ve been focusing quite a bit on ML research instead of just the usual DSA + dev route. Current situation: 1 paper in EMSE 1 in JAIR 1 under production still but hopefully going to a Q1 journal 1 I’m trying for NeurIPS main track (I know this one’s a long shot) -> Already under review and didn't get bench rejected 2 month internship at Accenture in 3rd year Some ML projects apart from the research work I know not everything will land. But assuming a realistic outcome where maybe 1–2 of these get accepted at a decent level (Q1/A* types), I’m trying to figure out what that actually changes. A few things I’m confused about: For jobs in India: Does this actually help with shortlisting for ML/SDE roles, or after a point does it not matter much and it just comes down to DSA + interviews anyway? Also, being from a tier-3 college, does this help offset that at all? Or do companies still filter heavily based on college first ? I've seen a lot of people from IIT/NIT get into research/MLE roles in big MNC's rather than preferring those in Tier-3 colleges. For higher studies: Does having papers like this make a noticeable difference for PhD abroad (US/EU), or is it just a “nice to have”? Do colleges really care about the difference between something like NeurIPS vs a Q1 journal vs IEEE Access, or is it all seen more or less similarly? And finally, I'm planning to do my M.tech in India itself by writing GATE 2027, do you recon the value of these paper will actually help me in these colleges (say IIT's/IISC/NIT ?) And one thing I’m seriously unsure about: If I’m leaning towards industry (ML/AI roles), is continuing research actually worth the time, or would that effort be better spent on DSA, systems, etc? Also, is it even realistic to

https://preview.redd.it/llqlupnwng4h1.png?width=2188&format=png&auto=webp&s=7fae5860babaffa1c8bfdcb1468b374eb38ac55d I'm currently building a computer vision application. I've managed to successfully train a YOLO model to detect the object I'm interested in for my videos. The image above shows some visualisations of the YOLO model outputs for some of the videos. I want to essentially cluster these strands in the image into groups based on their separation distance and return a string telling me the number of strands in each group from left to right (e.g. 1-2-3). The target value for each column in the image (where each column corresponds to a video) is 1-2-3, 1-2-3-2-3, 1-1-2-3-3-3-3 and don't worry about the fourth column for now 😄. The rows show the x vs t, y vs t and x vs y vs t for all the detections and the points are sized based on the detection box area. In the fourth column I have some background object detections which I want to ignore hence why I've also visualised detection box area. I've managed to train a XGBoost classification model that gives 70ish% accuracy however Bayes error is making me think I should be able to do much better than this. How would you approach trying to predict these strand clusterings? Some extra info that might help; there are at max 8 groups and each group can have only at max 3 strands. submitted by /u/mitbull420 [link] [留言]

Stacking, Bidirectionality, the Encoder-Decoder, and LSTMs Last post ended with a simple RNN and three promises: LSTMs, bidirectional RNNs, and attention. This post delivers the first two, plus the refinements that turn a working-on-paper RNN into something you'd actually deploy. By the end, you'll know how to stack RNNs for depth, why reading a sentence backward as well as forward (bidirectionality) makes representations sharper, how the encoder-decoder turns one sequence into a different one for machine translation, and exactly what breaks in a simple RNN that LSTMs and GRUs were invented to fix. Attention, the fix for the last problem we'll hit, gets its own home in the transformer post, so we'll stop right at the edge of it. The simple RNN was the idea. This post is the engineering. A vanilla RNN carries a thread of hidden state through time, but in practice, that thread frays on long sequences, only sees the past, and bottlenecks everything through one final vector. Each section here is a fix for one of those problems. Put them together, and the path from "RNN" to "transformer" looks less like a leap and more like a series of obvious next steps. Stacking RNNs for Depth The first refinement is the easy one. Nothing says an RNN's output has to go straight to a prediction. You can feed the entire output sequence of one RNN as the input sequence to another. Then another. These are stacked RNNs (also called deep RNNs), and they usually outperform a single layer. Why does depth help? The same reason it helps in vision. Each layer learns representations at a different level of abstraction. The lower layers pick up fundamental, local properties; in language, that's roughly the level of parts of speech and named entities. The higher layers compose those into bigger groupings: descriptive phrases, "this is the answer to a question," and so on. We can't point at layer 3 and say "this one does coreference." But the theory holds up well enough that researchers have probed m

Hey! I'm a CS student and I got tired of not being able to compare MLX inference engines properly — every benchmark out there is either made by the engine's own developers, runs on an M3 Ultra nobody has, or just shows tok/s with zero context. So I built mlx-Chronos — a small open source CLI tool that runs a standardized benchmark protocol on your Mac and lets you submit your results to a shared community leaderboard. What it measures: Cold and cached TTFT (Time to First Token), with a proper methodology — unique prompts per trial, cache priming, no interleaved phases Throughput (tok/s), with mean/stddev/min/max across repeated trials Engine process RSS and system RAM peak, sampled continuously during inference Thermal state and hardware info Supported engines: oMLX, Rapid-MLX, mlx-lm, Ollama (MLX backend) The leaderboard is basically empty right now since I only have an M2 8GB. Would love results from M3 Max, M4, M4 Ultra, or anything with more RAM — that's where things get actually interesting. → Leaderboard: https://igurss.github.io/mlx-chronos → GitHub: https://github.com/igurss/mlx-chronos → Install: pip install mlx-chronos It's early, the methodology is documented (there's a methodology.md if you want to pick it apart), and I'm 100% open to feedback, contributions, and getting told what I'm doing wrong. The goal is just to have one place where you can compare engines on your specific hardware instead of trusting someone else's numbers. submitted by /u/igor__004 [link] [留言]

174 million smart TVs, most of which run Linux. 3.9 billion Android phones. Zero marketing. Tonight, somewhere around the world, a person will press the power button on their Samsung TV. A proprietary Samsung logo will appear. A polished menu will load. They will open Netflix, scroll through recommendations, and pick a movie. They will never know that every frame they see is being scheduled, managed, and rendered by a Linux kernel, the invisible engine that sits between apps and hardware. They will then reach for their Android phone to check something on social media. Another Linux kernel. If they are sitting in a Tesla, the touchscreen showing their charging status is running yet another Linux kernel. The “year of the Linux desktop” debate has been running for two decades. Entire forums exist to argue about whether 2025, 2026, or 2027 will finally be the year Linux takes over the PC market.

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] [留言]

Hi, Relatively new to deep learning. I wanted some opinions on which of these approaches might be best for time series data and spectral analysis. I currently use a GP and it works pretty well, but I’m wondering what the computational tradeoffs and so forth might be. Any ideas? submitted by /u/InevitableCut1243 [link] [留言]

It’s hard to believe how quickly the tech landscape is evolving, especially with AI/ML at the forefront. Just the other day, I had the chance to attend the Mistral AI Now Summit, and wow, what an experience! I walked in with a notebook full of questions and a mind buzzing with curiosity. I left with a treasure trove of insights, a few new friends, and even more questions. Ever wondered what it’s like to dive deep into the world of AI with some of the brightest minds? Let me take you on a journey through my day at the summit and the lessons I picked up along the way. A New Era of AI Walking into the venue felt electric. The air was thick with excitement, and the buzz was palpable. I’ve been exploring AI for a few years now, and it feels like we’re at the cusp of something monumental. Mistral’s focus on open-weight models really got me thinking. What if we could democratize AI further? Imagine a world where innovation isn't locked behind corporate walls but accessible to everyone. I remember a speaker discussing how open models can help small startups compete against big players. It hit home because I’ve been that small developer trying to fight the good fight. Real-World Applications One of the discussions that resonated with me was about real-world applications of large language models (LLMs). I’ve dabbled in a few projects where I used Hugging Face's Transformers library to create chatbots, but hearing actual use cases from businesses was enlightening. For instance, a startup shared how they used a fine-tuned model to improve customer service response times by 50%. Can you imagine the time and money saved? It got me thinking about how I could implement something similar in my own projects. Here’s a quick code snippet that I’ve found useful when fine-tuning a model for a chatbot: from transformers import Trainer , TrainingArguments training_args = TrainingArguments ( output_dir = " ./results " , evaluation_strategy = " epoch " , learning_rate = 2e-5 , per_device_tra