AI Engineer World's Fair 2026
ALPHALAB: Autonomous Multi-Agent Research Across Optimization Domains with Frontier LLMs — Brendan Rappazzo
Read the talk
AlphaLab: From Automated Quant Research to Optimizing the Research Harness
AlphaLab turns prediction tasks into parallel research campaigns, then uses the failures of that approach to make evaluation environments the foundation for improving the system itself.
From a talk by Brendan Rappazzo
Before you start: Familiarity with model training, held-out validation and coding agents will help; no quantitative-finance background is required.
Where more research cycles could help
Given a time-series dataset, can you predict future values while keeping the model well calibrated? That is the shape of many applied problems facing Brendan Rappazzo’s team at Morgan Stanley. He describes a group of about 30 PhD AI researchers whose work spans academic publishing, open-source releases and internal applications. Some of those applications resemble Kaggle tasks: the input, prediction target and constraints are sufficiently explicit to support repeated experimentation. Rappazzo also suggests that the sell-side setting involves less adversarial selection, making these problems a promising place to automate research.
The opportunity starts with algorithms already in production. More hyperparameter tuning or better combinations of existing methods might produce improvements that a small team lacks time to pursue. It extends across trading desks: a model built for credit bonds might transfer to municipal bonds, provided someone does the adaptation and testing. Other desks have little existing machine learning, so even a reasonably trained first model could be useful. These are different research starting points, but all benefit from sustained cycles of implementation and evaluation.
Rappazzo dates the practical turning point to December 2025. With Opus 4.5 and coding harnesses such as Claude Code and Codex, long-horizon work began to feel feasible enough for the team to make autonomous research a major effort. The enabling combination was a capable model and an execution environment that let it continue working through a substantial task.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
One harness, different starting points
The business goals are increased P&L and more algorithms reaching production. To contribute to those goals, the system has to integrate with existing data access, backtesting and evaluation infrastructure while supporting two ends of the research spectrum.
| Starting point | Work delegated to the system |
|---|---|
| Data path and a natural-language prediction goal | Research the problem, build an evaluation and begin experiments |
| Data scripts, an evaluation and good existing models | Run additional experiments to seek improvements |
The second case matters as much as the first: autonomous research can be useful without inventing a modeling pipeline from scratch.
The harness also needs to work with different frontier providers and increasingly with open-source models. Its design should benefit as those models improve, rather than depend on elaborate machinery that stronger models make obsolete. A further requirement is harder to express as an interface: how should Morgan Stanley’s enterprise knowledge and its researchers’ expertise enter the system? That question eventually changes where the team concentrates its engineering effort.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From a prediction request to trained models
The first public system, AlphaLab 1.0, came with a technical report and publicly released code. Rappazzo recalls an early-April release. That version establishes the research workflow; the failures encountered afterward motivate the richer evaluations and environments behind AlphaLab 2.0.
Consider an exchange-rate dataset. A user supplies either a file path or API access with the API specification, then asks the system to predict the exchange rate one day ahead. AlphaLab turns that request into three phases:
- Research: understand the data and relevant modeling approaches.
- Evaluation building: construct the evaluation or backtest against which experiments will be judged.
- Mass experimentation: implement and evaluate candidate approaches.
The output is a suite of trained machine-learning models for the requested prediction task, rather than just a written research recommendation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Tools for research and cluster execution
AlphaLab uses a custom harness rather than an off-the-shelf agent framework. Rappazzo credits Claude with writing the implementation and values the freedom to change any part of it. Function-based tool calling provides the boundary between models and actions, allowing the harness to accommodate OpenAI, Anthropic and open-source providers.
Three tools supply most of the practical capability:
- Shell access: agents write Bash commands, create Python environments, edit code and run it.
- Web search: agents consult arXiv papers, technical blogs and other public material to identify relevant methods.
- Slurm submission: agents describe the hardware a training job needs and submit it to the GPU cluster.
The Slurm boundary lets an agent request resources without managing the underlying hardware orchestration. For example, a worker’s Bash submission for four H100s can take this form:
bash
sbatch --gpus=h100:4 --wrap='python train.py'
The worker still needs to prepare the training code and job configuration. The scheduler handles allocation; CPU requirements can be included in that configuration as well.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Research context that survives a handoff
The research phase serves as an expanded CLAUDE.md or /init: its purpose is to gather enough context for agents to form useful hypotheses and test them. AlphaLab runs on the server, with a lightweight UI exposing its progress. The first substantial artifact is a to-do list whose completion should leave the system ready to experiment.
That list also gives the harness a way to detect unfinished work. If an agent tries to exit early, outstanding items provide a reason to prompt it again. Tasks include setting up the Python environment, loading data and performing statistical tests. Each item produces Markdown notes, so later agents can query the relevant findings dynamically instead of needing the entire research history in context. Most web search happens here, adding public research to the local understanding of the dataset.
Rappazzo estimates that the research phase takes roughly three to four hours, with substantial variation. Its lasting output is the accumulated context that evaluation builders and experiment workers can reuse.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Building an evaluation, then trying to break it
Optimizing against a faulty evaluation undermines the entire research campaign. An LLM does not need malicious intent to introduce a mistake that makes a model look better than it is. AlphaLab 1.0 therefore assigns evaluation construction and review to separate agents; this is also the phase that changes most in the next version.
The original review loop divides responsibility into three roles:
| Role | Responsibility |
|---|---|
| Builder | Write the evaluation code and repair reported issues |
| Conceptual critic | Check the evaluation’s logic and forward information leakage |
| Tester | Write unit and integration tests |
The two reviewers write up issues for the builder. Repairs return through the review loop, which continues until all agents accept the evaluation. This separates questions about whether the experiment measures the right thing from questions about whether its code behaves as intended.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A research campaign on a Kanban board
Mass experimentation is organized as a Jira-style Kanban board. A strategist agent queries the context gathered in earlier phases, proposes experiments and places cards in a to implement column. Worker agents pick up those cards and carry each proposal through execution.
A worker’s responsibility extends beyond generating code:
- Implement the proposed strategy.
- Write the Slurm configuration, including its hardware requirements.
- Submit the training job and wait for completion.
- Inspect training curves for underfitting or overfitting and examine evaluation results.
- Write a postmortem and return it to the strategist.
The postmortem closes the loop. A completed experiment changes what the strategist knows, which should change what it proposes next. Rappazzo gives the example of three disappointing transformer variants alongside strong XGBoost results: the next useful move may be to explore more tree methods. That is a decision about where to spend further experiments, not merely which finished model ranks highest.
The board is also a human steering interface. Researchers can cancel cards, add their own experiments or chat with the strategist to supply domain intuition and encourage different approaches. Meanwhile, a growing leaderboard shows model performance against the evaluation and a held-out private validation set. Researchers can drill down from an idea’s inception to its implementation and extract the code for further work.
The later UI demonstration makes the worker lifecycle visible as experiments move through building, deployment and analysis. It is sped up; the animation illustrates how work flows through the system, not how quickly training jobs finish.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Results from public tasks and internal models
The initial paper explores CUDA kernels, an academic traffic time-series dataset and Karpathy-style LLM training speedrunning. Rappazzo reports that AlphaLab found a better LLM training configuration than a single-agent loop, while acknowledging the difficulty of benchmarking the system. The comparison concerns the research process’s ability to find a training configuration, rather than the general intelligence of the model running that process.
Rappazzo reports a top-12% finish among submissions in an NVIDIA Kaggle competition to fine-tune Nemotron for reasoning, after only about ten iterations because the team entered late. He expects more iterations to help AlphaLab explore further, but additional improvement in that competition is a hope rather than a measured outcome.
Internally, he describes a handful of useful improvements to already decent models. Those improvements are working through risk review toward production; he does not report quantified internal gains or say that the review process is complete. This is the more constrained starting point from the original design: give AlphaLab a working approach and let it search for improvements.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
What the failures left unanswered
Successful experiments did not resolve failures on harder problems. Those failures raised a measurement question: how could the team distinguish dependable research capability from a collection of encouraging outcomes? They also exposed uncertainty about the harness itself. A research phase followed by a strategist and workers sounds plausible, but plausibility does not establish that this is the best arrangement.
Harness design could itself be a verifiable optimization problem. If alternative arrangements can be measured, an LLM could help improve those arrangements. At the same time, the original data-plus-goal interface leaves much of the enterprise’s knowledge and the researchers’ expertise outside the system. Rappazzo locates the answer to all three concerns—capability measurement, harness design and expert knowledge—in deliberately constructed evaluations and environments. He describes the original approach as overeager to treat the agent like a human researcher before establishing a clear way to measure its work.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A stricter contract for AlphaLab 2.0
AlphaLab 2.0 makes the evaluation boundary much more explicit. The arrangement resembles Kaggle: data and a task description enter the system, the harness submits containerized models, and the environment returns a public leaderboard score. The user separately sees performance on a private, held-out validation set. This makes a submission’s task performance measurable while separating the feedback available to the harness from the private results available to its operators.
Once tasks share this strict format, they can support both evaluation and learning. Rappazzo reports building roughly ten to twenty carefully designed environments to supply a reinforcement-learning signal. In this formulation, an evaluation becomes an environment when the system uses it to train and improve, rather than only to report a result.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Using AlphaLab to improve AlphaLab
A stable measurement setup makes manual harness tuning more informative. Should there be two strategists? Should they debate? Those proposals can become experiments rather than permanent architectural commitments justified only by intuition. Rappazzo calls the next step “AlphaLab-ing AlphaLab”: an LLM examines execution traces and evaluation results, then modifies the harness itself. The object being optimized has moved from a prediction model to the machinery that conducts the research.
Weight training provides another route. The team is collecting good traces from open-source models and working with GRPO and on-policy distillation methods to improve model behavior. Rappazzo anticipates that the best system may combine open- and closed-source models. Orchestration and model training are therefore related optimization choices: the aim is to improve the performance of the complete research system, not to assume one fixed agent arrangement or model provider.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Encoding expertise in the environment
Building a useful environment requires more than proprietary data and a numerical metric. The team also develops qualitative rubrics that examine rollout traces: what constitutes good research, how should a researcher reason through a problem, and how closely does the agent follow the team’s research process? Grading those traces turns expert judgments about method into a learning signal alongside the measurable task outcome.
The durable investment is the environment that defines and recognizes good research. With a strict evaluation setup, the orchestration in the middle can change. AlphaLab 1.0 supplies an initial implementation, but the longer-term aim is a system capable of improving that implementation itself. Rappazzo forecasts that general automated research will become a commodity, citing GLM 5.2 as an example informing that expectation. Manual tuning remains part of the team’s current work; a fully self-improving research process is the destination.
That distinction also explains the plan to continue releasing the system publicly. AlphaLab 1.0’s code and research are already public, and Rappazzo intends further releases because he places the enterprise-specific value in the environments: the data, evaluation criteria and research rubrics that make improvement meaningful for the organization.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
The original report details the research harness, evaluation construction, experimental results and ablations across optimization domains.
A workflow overview with a sped-up dashboard demonstration, benchmark summaries, and links to the paper and code.
Further reading
Morgan Stanley's public research repository indexes publications and projects, including an AlphaLab code link.
Read the complete timestamped transcript
- 0:00
[upbeat music] Well, thank you everyone for coming. Um, today I'll be presenting what we've been building at Morgan Stanley, uh, sort of auto research agent to try and automate quant research.
- 0:24
Um, and I wanted to just take the, the first couple of minutes to sort of explain, you know, give some context on our team and also, um, you know, why we're even pursuing trying to build this, this auto research agent.
- 0:37
And so our group, we're relatively small. We're about thirty, uh, PhD AI researchers, and we kind of operate both, like, kinda half academic, so we're encouraged to, um, you know, publish papers, open source code, share our research.
- 0:52
And then the other half is sort of more applied internal work. And, you know, I think a lot of our problems or, or, you know, at least some of them are, are-- can be fairly well-posed.
- 1:02
They kind of have a similar shape to Kaggle, where we have, you know, an input time series dataset, and our task is to just, you know, predict future values and maybe with some other constraints of wanting the model to be well-calibrated.
- 1:17
Um, and so I think, you know, being on the sell side, we kind of have maybe less sort of adversarial selection, and so it, it kinda lends itself naturally to this auto research framework.
- 1:27
Um, and, you know, also I think there's-- we have a lot of sort of algorithms in production where we c-- have a feeling if we could just put in more cycles, there might be some improvements to kind of squeeze out, whether it's just better hyperparameter tuning or exploring a lot of different kind of ensembling these different methods
- 1:45
together. Also, you know, we have-- we work with a lot of different desks, and there's a feeling that, like, something we have built for, say, credit bonds could really transfer well to, like, muni bonds, and that kind of translation process should be something that can be automatable with, with agents.
- 2:03
And even, like, going to new trading desks and trying to build them new algorithms, there's sort of a lot of low-hanging fruit where, uh, they're not really using a lot of machine learning or, or AI automation.
- 2:14
And so, you know, even, like, a reasonably trained model should be able to have a big impact. And so sort of in the last year and a half where these, these agents became, you know, able to do long-horizon tasks, we've been interested in trying to do this automation.
- 2:30
Um, but it wasn't really until December of twenty twenty-five, and I think this is a pretty common sentiment now that, um, it really felt possible for the first time with, like, with Opus 4.5 and with, you know, these harnesses like Cloud Code and Codex, where it really felt like the models were at a point where they could
- 2:47
do these long-horizon tasks and also kind of the idea of putting them in these harnesses that, that allow them to do so. And so, you know, really starting this year, we kinda made it a big effort to build this, this auto research agent.
- 3:01
And of course, sort of the, the top line goal is just maximizing P&L and maximizing the, the number of new algorithms we can put in production. Um, but, you know, we also had these design concerns.
- 3:13
Like, of course, we want it to play nicely and integrate with all of our data and sort of the pre-built scaffolding we have around back testing and evals. We also wanted it to be able to run the full spectrum.
- 3:25
So, like, you know, on one side, maybe it's a new dataset and we just wanna say, like, "Here's the path to the data," a natural language description of what we hope to predict, and the thing should go off and do research, build its own eval, and start doing experimentation.
- 3:43
And then sort of on the other side of the spectrum, maybe it's like, "No, we have our data scripts, we have our eval, we actually have a few good models we've already produced," and we just want it to kind of churn and do more cycles and see if it can find an improvement.
- 3:57
Um, also, we wanted to build this to be really model agnostic, so we could use any of the frontier providers or increasingly, uh, you know, any open source model.
- 4:07
And also, we wanted to build it in a way that, you know, as these models get better and better, it's not sort of consuming what we've built. Like, we kind of rise with the tide of the models.
- 4:19
And lastly, you know, really carefully think about, um, how do we encode sort of like our enterprise knowledge as Morgan Stanley and then our human expertise as, as quant researchers.
- 4:30
And so for, for the rest of the talk, I wanna start with sort of what I'm calling AlphaLab 1.0, which is our first version we released, I think it was early April, and we put out a full, like, forty-page tech report going through all the details and results.
- 4:46
We also open sourced all the code on GitHub. So I, I kinda wanna cover that more at a high level because all the details are so public, but I'm happy to talk afterwards in, in depth about any part.
- 4:58
Um, but then I really wanna cover, you know, sort of what's happened since then. So what were the initial results? What were the kinda failure cases since then? Because we, we have encountered a lot of failures.
- 5:11
And then talk about how we're really addressing those by building, uh, kind of our own rich set of evals and environments and how that's sort of allowing us to
- 5:21
improve the harness and climb towards this sort of self-recursive improvement and sort of our grand vision now for AlphaLab 2.0.
- 5:30
And so to start, you know, AlphaLab is an agentic harness and kind of going towards that, that first side of the spectrum. The, the goal is you have some dataset, you know, let's say it's like a, a exchange rate dataset or something, and you can just provide the path to the file, or maybe it lives on an
- 5:50
API, and you can just say, "Here's the API acce-access and the API spec." And then just in natural language, say what you wanna predict. So maybe it's as simple as, you know, the simple exchange rate.
- 6:02
I would-- just I'm curious in predicting one day out what the, the rate will be. And the harness then works in these, these three phases. So the first phase is research, and I'll cover these all more in depth.
- 6:13
The second phase is then actually building its own evaluation or back testing. And the third phase is sort of the mass experimentation, which is really the heart of the, the harness.
- 6:24
And then as output, you get a suite of trained machine learning models that are trying to, you know, do the, the prediction you care about.
- 6:34
And one design choice we made, so the harness is actually all our own code, so we decided not to use any off-the-shelf agent framework. Um, we wrote it all, and really Claude wrote it all.
- 6:48
And I think like in the era of, of Claude code, I, I, I like this approach of kind of building your own from scratch because you get sort of max freedom and max like, you know, you're, you're free to kind of tweak anything you care about.
- 7:03
Um, and so, you know, all the tool calls are done with these like functional tool calling, and that also allows us to nicely really be provider agnostic. So OpenAI, Anthropic, or open source providers, it's very easy to, to adapt the, the harness to any, any of those.
- 7:21
As far as the actual tools, there, there's a-- there's several, but the sort of three main ones are, one, full shell access, so it can write any bash command.
- 7:31
So this is how it's writing code, setting up its Python environment, editing code, running code. Um, another important one is web search, and this allows it to go read, you know, archive or technical blogs or anything like that and get sort of up to speed at, um, you know, at least in the public domain, like sort of
- 7:50
what's the state-of-the-art methods. And then the third one is, um, we use Slurm to manage our GPU cluster, but the, the higher level idea is just a, a nice abstraction where the model can say like, "I'm training a, a fairly big model.
- 8:06
I need four H100s and this many CPUs," and just kind of write the config and submit the job and not have to worry about like, doing hardware orchestration.
- 8:17
Uh, yeah. And to go into the, the actual phases. So again, the first phase is this, this research phase. And the idea here is kind of like almost like a super Claude MD file or a super init where we just want the system to go off and kind of build enough context such that it can start meaningfully,
- 8:36
uh, you know, forming hypotheses and testing them. Um, and we built, you know, AlphaLab is kind of this server-side running thing, but we built this lightweight UI on top.
- 8:46
And so sort of how we've done this is build this, this scaffolding of the to-do list. So it's first, you know, prompted to, to build the to-do list such that if it completed every item, it'd be able to start experimenting.
- 8:59
And this allows us to kind of keep re-prompting should it try to exit early. And so you can see, you know, it's talking about setting up its Python environment, um, doing different data loading, doing different kind of statistical testing.
- 9:14
And each item of the list it's instructed to build a, like take notes in a markdown file. And this also allows feature agents to smartly query that and kind of manage their context dynamically.
- 9:27
A-and this is really where web search is used most because it will go off and read archive and, and get kind of good context from the public domain as well.
- 9:36
And so this can vary a lot, but, um, it takes, you know, roughly around three to four hours.
- 9:43
The second phase and what, um, is most different in 2.0 is the eval building. But just to say sort of our first implementation, you know, of course, the evaluation is the most important piece, and LLMs aren't malicious, but they can make, you know, very silly mistakes.
- 9:59
And if you're optimizing against a ba- a bad eval, the whole thing kind of falls apart. So our attempt to be more robust is have this sort of multi-agent framework.
- 10:10
So one is tasked with first building the eval, like actually writing all the code. And then that goes off to two critic agents, one that's told to be more high level, like are there conceptual errors in our evaluation or any kind of forward leakage of information, and then one that's more programmatic.
- 10:28
So it's like writing unit tests and integration tests. Um, and they write up any issues they find. If there are issues, it goes back to the builder to fix, and this loop doesn't end until sort of all of them are happy that the eval is good.
- 10:43
And then the third phase, and really the heart of everything, is this mass experimentation. And so we've, we've chosen, you know, both in the code and in our UI, this is kind of formulated as a Jira board or a Kanban board.
- 10:57
And so there's this sort of strategist agent that gets to look and query all the context from the previous steps. And it's just supposed to keep coming up with experiments it wants to try, and it submits them to this like to implement column.
- 11:12
And then as new cards come in, those get pawned off to worker agents that are tasked with actually writing the code to implement the strategy, writing the Slurm config, you know, what hardware does it need, submitting it to our cluster, waiting for the job to finish, and then look at, you know, the, the machine learn- learning training
- 11:30
curves, like did it underfit, overfit, and then also looking at the eval results. And then it sort of writes this postmortem analysis, which goes back to the strategist as each job finishes.
- 11:41
So the strategist hopefully can do this kind of self-evolution. So it can see like I suggested, you know, three variants of transformers that actually didn't work too well, but, uh, XGBoost is, is working really well, so I wanna explore more tree methods or something like that.
- 11:58
Um, and also in this step is where we as users can steer. So you can, you know, s- another reason we picked sort of this Jira formation is- Uh, you can cancel cards, you can add your own cards.
- 12:11
There's also a chat feature that's sort of cut off here, but you can chat with a strategist and kind of steer it towards more creative or kind of give it intuition of different methods it should try.
- 12:23
Um, and then we keep this, you know, ever-growing leaderboard where you can see, like, given your eval and given a held-out private validation set, like what are the best performing models?
- 12:34
And you can click in and see like, you know, from inception of the idea to the code, and you can pull it out and play with it.
- 12:41
And then this is just sort of our UI 2.0, which is really just optimized to look cool. But you can see like, you know, it's suggesting experiments, and this is really sped up, but how each worker kinda pulls it through, um, you know, building, deploying, and then analyzing the results.
- 12:59
And, um, you know, in our paper, we did more sort of academic datasets. So we looked at CUDA kernels, we looked at, uh, an academic traffic time series dataset, and we did the kinda classic, like, Karpathy-style LLM speed running.
- 13:16
Um, and it's sort of hard to benchmark AlphaLab, but we compare it to more of a Karpathy style, like single agent in a loop going, and it did find a better, uh, training config for training an LLM.
- 13:30
We also put this on a Kaggle competition, which was to-- for-- it was, uh, hosted by NVIDIA to fine-tune their Nemotron model to be a reasoning model. Uh, and it got in the top twelve percent of submissions, which, yeah, I think is decent, and also it only had sort of ten iterations to work with because we joined
- 13:50
late, and I think, you know, AlphaLab works best the more iterations it can explore. So presumably or hopefully it would've done better had it, uh, had more time. And then I can say at a high level internally, there's been a handful of, of models, all sort of the flavor where we had a decent model already, but we
- 14:09
just turn it over to AlphaLab to keep kind of churning on it, uh, where it's found meaningful improvements that are now working their way through risk and going into production.
- 14:20
And so with the-- my last couple minutes, I, I wanna talk about, um... You know, we, we ran into surreal issues and hard questions. Uh, I think the first was, you know, okay, so we had some, some good results, but we've also had cases where it's really failed.
- 14:36
And so it's kind of always in our head like, how real is, is any of this? You know, if it, if it's failing on these hardest problems, how do we measure how, you know, how real this is?
- 14:47
And the second was, and I'm sure a lot of you might be thinking like, okay, a research phase sounds reasonable. Having a strategist and worker sounds reasonable. But isn't it sort of arbitrary?
- 14:58
You know, like, how do you motivate these design choices? And how we feel now is like, and I think a big theme of this conference is, you know, should we be making these dec-decisions at all?
- 15:08
Like this itself is a verifiable loop. Like an LLM should be doing this, this meta optimization itself. And then lastly, you know, on this, this 1.0 formulation, it's sort of like we give the data, we give the goal, and the LLM just goes off and does it.
- 15:25
So like how does that exactly encode our, you know, Morgan Stanley's enterprise knowledge, but just our expertise as, as quants, like sort of missing from the picture. And so the answer to all three we feel is really in building our own evals and environments.
- 15:42
And so to just sort of go one by one through the questions, you know, to the first point, and this is a lesson I learned over and over, like monthly working with these models, you have to start with good eval.
- 15:54
Like it's such an obvious thing. I think we were kind of overeager and wanted to treat it more like a, a human researcher, but you of course need like a very clear way to measure.
- 16:04
And so the, the biggest kind of change is now we're, we're very opinionated about the eval. It's very much like Kaggle. And so, you know, we treat it as data and description in.
- 16:17
The harness lives in the middle, and its only job is to submit containerized models, and it gets sort of the, the feedback of like a public leaderboard score. But you as a user get to see a private leaderboard, like held-out validation, how is the model performing.
- 16:31
And so, you know, in this case you can measure like just for any given task, how well does your model do? But of course, once you have this strict kind of format, you can think, okay, you know, to me, evals and environments are the same thing.
- 16:46
It's just you train in environments. So now what we've done is built on the order of like ten to twenty really careful environments, and that becomes a reinforcement learning signal.
- 16:57
And so we're, you know, quote-unquote, "AlphaLab-ing AlphaLab." So once you have that way to measure, you know you can do human tuning of the, the harness. So like maybe there should be two strategists and maybe they should debate or maybe they're, you know, whatever kind of ideas you have, you at least have a way to measure and
- 17:14
kinda manually hill climb. But what we're doing now is really this meta harness optimization, where the LLM is looking at the traces, looking at the val-- you know, the results, and improving the harness itself.
- 17:27
And also sort of a, a tangential axis is we're now collecting good traces from open source model and really touching weights and doing like GRPO or, or other, you know, on-policy distillation methods.
- 17:40
And so we see like the, the best performing thing might be an orchestration of open source and closed source models, but we're kind of optimizing the whole thing together.
- 17:50
And to the last point, you know, how do we as, as experts encode our expertise? We again think it's through environments. Like building environments or at least good environments is really, really hard work.
- 18:03
You, you know, it's-- You have to be-- There's of course like the data that goes in that's proprietary, but, you know, designing the, the verifiable metrics is maybe the easy part.
- 18:12
But then we're also doing these qualitative rubrics where we kind of look at the traces and say, you know, "What makes a good researcher? What's the thought process?" And we can grade each rollout on, you know, how well it's following our research process.
- 18:27
And so having these good rubrics that become the signal for the model to learn, we feel is really how we're, we're building our own expertise into the system. And so just to kind of conclude the, the 2.0 version is really having this strict environment and eval setup and, you know, whatever lives in the middle, we almost in
- 18:47
the limit kind of don't care about. We can initialize it to AlphaLab 1.0, but this-- it should really be this self-improving system. Um, and just to leave kind of the, the bigger picture headline result and my feeling is, you know, this ability to do general auto research I think will kind of become a commodity.
- 19:07
Like I think we're already seeing it with GLM 5.2, and so I really think all of your value as like an enterprise or human expert comes from building environments.
- 19:17
And so like, you know, temporarily for us that we're still doing like manual tuning against the environment, but I think in the limit, the, the auto research can research itself and just be this self-improving, um, process.
- 19:32
And so, um, my site's on there and then also the, the project page, again, the 1.0 version, we released everything and our plan is to keep just releasing because again, we think the environments encodes all of the, the value.
- 19:47
Uh, so thank you. [clapping] [upbeat music]