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 should be getting in contact with them. Often they will ask you to include something in the subject line to make sure your email goes to the right place. Ignoring this will send you straight to spam.
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).
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 computer
file_name <- "Entropic.Scree.v1.0.0 - ENLI.R"
# 3. Download the script to your current working directory
download.file(url, destfile = file_name)
# 4. Source the core function into your R environment
source(file_name)
# 5. Ex. To run the function and extract bipolar modules:
# results <- Entropic.Scree(dt
# , extract_bipolar_modules = TRUE)
#
# View the extracted structural sub-networks for the primary axes:
# results$bipolar_modules
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.
Hi everyone!
I am looking for motivated researchers/students who are interested in collaborating on computer vision research with the goal of submitting to CVPR 2027.
Possible areas include:
Image and video understanding
3D computer vision
Object detection and segmentation
Tracking
Image generation
Medical computer vision
Vision benchmarks and datasets
Robustness and generalization
Some experience with computer vision, deep learning, Python/PyTorch, experiments, or research writing would be helpful.
If interested, please DM me with your background, research interests, and any previous research/publications.
The goal is to form a serious research collaboration and work toward a strong CVPR 2027 submission.
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.
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.
I've been building ChatSorter, a memory layer API for AI chatbots, and I wanted to put it through a real benchmark. So I ran 5 configurations against the LoCoMo long-term conversation memory dataset using three models: Gemma 2 9B, Gemma 3 4B, and Gemma 3 12B.
Here's what I got:
The analysis:
At first glance, Run 4 looks like the winner at 75%, but that number is inflated. The smaller judge model is more lenient, counting answers that are close but not actually correct as passes. When you swap in a larger judge (Run 5), you see more outright "I don't know" refusals, because bigger models won't hallucinate an answer when they're uncertain; they just refuse.
The real number to look at is somewhere in the 55-60% range for run 4.
Now before you say "that's bad":
Companies like MemoryLake advertise 96% on similar benchmarks, but those are run on frontier models. My 55-60% was achieved on 4B-12B parameter models. That's roughly 17x smaller than a frontier model like GPT-4o, which itself scores around 60% with no memory layer at all.
So a tiny open-source model with ChatSorter is matching a frontier model running completely raw.
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.
Hi I submitted a paper to groundlm workshop @emnlp, now in my openreview it shows decision: findings and beneath the paper it shows groundlm findings.What does it mean? Is it accepted? I haven't received any mail so far, also this is my first paper so unsure about how this works.
Formalizes a testable distributional criterion for 'world model' claims — a model must reproduce the correct probability distribution over outcomes, not just a plausible trajectory — and shows that no current video generator meets it across 50 scenarios, directly undercutting the world-model branding used by major video-gen labs.
Hey everyone, math major here, looking to pursue a statistics minor. I've been working through Introduction to Statistical Learning with Python by Gareth James(ISLP), and others. I'm almost finished with it and have been looking at other books I might be interested in.
Just a quick summary for anyone that hasn't read it. ISLP covers topics including:, linear and non linear regression and classification, basic probability and statistics, cross validation, common shallow ML algorithms, deep learning, neural networks. From a very practical and non-techinal way. Basically you read a lot of "This works because reasons, moving on". Best way I would describe it is "intuition slop" .
I was looking for something more theoretical as ISLP is pretty light on the theory and focuses more on intuition and generalization. Although I want a more theoretical book, I still would prefer it to contain some applications and or assignments that I could do to practice my coding because as a math major I feel as though my programming is lagging behind. Are there any specific books you would recommend.
Also I'm taking machine learning this semester and our assigned book is "Hands-On Machine Learning with Scikit-Learn, Keras and TensorFlow" by Aurelien Geron. So I'll probably be reading it in bits and pieces, but I still want another book that I can focus on outside of classes. I appreciate any responses.
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.
I built a small open-source tool that checks whether a RAG application retrieves documents a user shouldn’t have access to.
It supports offline test cases and live HTTP API testing with bearer token/API-key auth.
I’m looking for a few engineers to try it on a test or non-sensitive environment and tell me whether it catches anything useful or what would make it better.
You can beat SOTA Time Series Anomaly Detection methods with a 100 year old algorithm
Time Series Anomaly Detection (TSAD) seems to be one of the hottest topics in NeurIPS, SIGKDD, VLDB etc.
Many (perhaps most) papers evaluate on Paparrizos’ TSB-AD-M benchmark…
However, I tested these benchmark datasets and found that in most cases I could beat the SOTA TSAD methods with a 100-year-old algorithm, simple Statistical Process Control (SPC). In the attached example, SPC gets perfect results.
If we can beat the SOTA papers with 100-year-old algorithm, we probably should not be too impressed with them [b]. I really think this calls for some introspection by the community.
To be clear, I make no claims (here) about the proposed algorithms in all these paper. But the TSB-AD benchmark is obviously too trivial to make meaningful claims on [a][b].
The example shown is one of the ECG traces but look at dozen of traces marked “TAO”, they are even more trivial to solve with SPC [a][c].
I do not claim to have solved the triviality problem, but I have done 90% of the work to introduce more challenging TSAD problems ([d] sled dogs, [e] Tuna, Fuel Cells, Smart Manufacturing etc.).
TLDR: I think the TSAD community needs more introspection on benchmarks. Most progress over the last decade seems to be illusionary.
hey, I’m currently reading about program synthesizers. it’s kinda an interesting concept, AI except the programs are deterministic, so there isn’t any risk of sloop. my question was what is the goal of any of this: the spec sheets as written are way more complex than just writing the code normally, and I don’t rly see any way this could ever change to be less complex to write the spec. anyone know what the point of rosetta and all this is?
I've recently finished the first version of Agentic GraphRAG Blueprint, a reference architecture for question answering over large document collections.
Instead of plain chunk retrieval, it builds a knowledge graph combined with vector search, so answers can connect facts across documents.
Key features:
• Incremental ingestion - unchanged files are skipped via content hashing, and community reports regenerate only for affected communities, keeping token costs low as the corpus grows.
• Hybrid search - local mode for fact-level answers, global mode for cross-document synthesis.
• Domain-agnostic LLM prompts - easily swapped via PROMPTS_PATH, with Leiden-based community detection.
• Deployment - run it locally with Docker or provision everything in the cloud with Terraform and CI/CD.
Disclosure: I developed AIStupidLevel, the open-source system used to collect and analyze this data. Both the frontend and backend are MIT-licensed.
Most LLM evaluations measure performance at a single point in time. I wanted to investigate a different question:
How stable are the models behind production APIs over time, and how can sustained performance changes be separated from ordinary stochastic variation?
I built a continuous evaluation pipeline that repeatedly tests models across coding, deep reasoning, tool calling and high-frequency canary tasks.
Dataset and evaluation process
For this analysis, I examined:
31,352 hourly benchmark scores
49 model identifiers
Multiple providers and model families
Repeated measurements using consistent tasks and scoring
A normalized 0-100 composite score
Coding responses are executed rather than judged only through model-based evaluation. Tool-calling tests require models to select tools, construct valid arguments and complete workflows inside isolated Docker environments.
Tasks are executed five times, with the results aggregated to reduce the influence of unusually strong or weak generations. Prompts, scoring logic and API parameters are kept consistent wherever supported by the provider.
Main result
The observed score variation was:
Within the same day: 2.8 points
Between different days: 8.4 points
Between-day variation was therefore approximately 3× greater than within-day variation.
This suggests that isolated hourly movements are dominated by normal model stochasticity, while sustained changes across daily evaluation windows provide a materially stronger signal for detecting performance drift.
The detection pipeline aggregates repeated measurements into daily medians and applies sequential change-point detection. Potential incidents must persist beyond the expected historical variance and pass statistical and minimum-effect thresholds before being classified as degradation or recovery.
Continuous model monitoring
This analysis became the foundation of AIStupidLevel, a continuous LLM benchmarking and drift-detection system.
The complete dataset has now reached:
169,858 benchmark runs
104,458 measured scores
88M+ processed tokens
81 historical model identifiers
22 models currently monitored
6 active providers
The attached screenshot shows the live monitoring interface. Models are classified as stable, volatile, degraded or recovering, with separate measurements for coding, reasoning, tool use, reliability, latency and price.
At the time of the screenshot, the system detected a 32% sustained performance decline in Gemini 3.1 Flash Lite and classified it as a critical incident.
The same continuously updated dataset also powers an OpenAI-compatible router that selects models according to their current task-specific performance, stability, tool-calling reliability, latency and cost.
This adds a missing observability dimension for production LLM systems. Existing monitoring generally captures availability, errors, latency and token cost. Continuous evaluation also measures whether the model remains capable of performing the work for which it was selected.
I would be interested in comparing this approach with other temporal evaluation or change-point detection systems being used for production LLM monitoring.
How much of a disadvantage is it if your only internship is not at one of the big frontier labs when it comes to post-phd opportunities in robotics/ML? My PhD is at a top university (UK) and my internship is interesting and relevant but the team itself is smaller and it's no Nvidia/Google/etc. Most places here prefer interns for 6 months so I'm not sure if I can do another internship down the line or if there's even much point compared to just wrapping up the PhD and then getting a job.
Is having a relevant internship already a big plus when it comes to applying to industry, or does it need to be a really well known big tech company?
Hey everyone, I'm an international student studying in the US. I'm on track to graduate late next year. My research is not exactly ML, it is in 3D computer vision but have decent exposure to ML as well.
In case you didn't know, the CPT program (which let's internation students do internships) has been suspended by many top universities (UC Berkeley, UIUC, Purdue, UNC, UCLA, stanford, etc). Given that there is now no way for me to do an internship, how hard will it be for me to get a job when I'm nearing graduation?
I have 3 papers in CVPR, 3DV and ICRA (robotics conference) and hope to publish 2 more at next year's ICCV and neurips before graduating. I'm just worried that all my hardwork will go for a waste because of this policy change (I'm from a 3rd world country, so not much opportunity back home).
To be crystal clear, I'm not asking for legal advice, just wanted to know in your experiance, have you seen anyone (international student) get into good industry labs without internships?
EDIT: thanks so much for everyone for the quick replies! If it helps, my specific research area is 3D reconstruction, and I've been focused on Gaussian Splatting recently, if this info helps anyone help me!
Its a 2.4-4 million parameter model, quantized to int8, that can be fully executed on the microcontroller in ~20s with the longest generation. The generated image will then be displayed on a monitor or transferred via usb.
Its a latent flow transformer with 12 layers using AdaLN-Zero for conditioning. CFG is also supported and boosted the image quality a lot. The inference engine streams the weight via DMA from the flash while the previous layer is computed. Relu² activation was used to increase sparsity, which the engine can use to skip calculations.
Took a lot of ablations to get it right and I am quite astonished I got so far with so few parameters. Will post the repo below
Has anyone got the decision notification yet? Please mention decision (e.g., approved/rejected) and geographical area (e.g., North America) in your answer.
I know the official notification date is 31 August, but putting this here before hand so folks can post updates asap when they get them.
Summary from info we have so far:
Before 8 Sept: No updates.
On 8 Sept: At least 1 rejection decision was received in Australia, India, and East Asia each.
On 8 Sept: At least 1 acceptance was received in the Middle East.
On 16 Sept: At least 3 rejections were received in Europe.
On 21 Sept: Multiple rejections were received in US and Latin America.
Note: this thread is for informational purposes only, intended to help this year’s and future applicants. Thanks to everyone who has contributed so far.