Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

"Theodore Tso" <[email protected]> Fri, 17 Jul 2026 16:21:19 -0400
Newsgroups dev.linux.lists.ksummit
Message-ID <[email protected]>
On Fri, Jul 17, 2026 at 09:55:02AM -0500, Konstantin Ryabitsev wrote:
> I'd go so far as to say that we DON'T want to feed unfiltered LKML archives
> into the model -- we probably want to lean on the work done by the cregit
> folks to identify patch sets that were actually accepted and then work
> backwards, creating a subset of LKML that resulted in accepted contributions.

I agree that we can do better by tagging various e-mails from the LKML
archives as "this commit was rejected" or "the patch or e-mail was
ignored because it was obviously AI SLOP" or "this is a review by
someone who is known to be a bad reviewer such that maintiners have
stock e-mails explaining to new contributors that it's OK to ignore
reviews from that reviewer".

> (Not that any other AI companies are bothered with this detail, as they are
> scraping everything as fast as they can.)

Yeah, precisely.

The frontier models are trained by grabbing everything, and that's
what the kernel review prompts use.  If we use one of the smaller
models that can fit in smaller machines, those smaller models won't
have as much of the "knowledge" that was gained by the training that
was done by scraping everything, since the smaller models were created
by distilling the larger models.  Detailed knowledge about Linux kenel
would be diminished along with the distillation process --- along with
all other bits of knowledge, including internal combustion engines,
how to create meth, etc.  So we could add it back via the fine tuning
process.  More information can be found here[1].

[1] https://unsloth.ai/docs/get-started/fine-tuning-llms-guide/datasets-guide

If we do this, it's probably not the patches which are the most
interesting, it would be the review comments, since that would inform
the model about what maintainers worry about when they are reviewing
code.

Note that there are multiple kinds of fine-tuning.  One approach just
simply sends unstructured text in small chunks.  There are more
powerful ways which require a lot more structuring where we give it
instruction and answer pairs[2].

[2] https://wandb.ai/capecape/alpaca_ft/reports/How-to-Fine-Tune-an-LLM-Part-1-Preparing-a-Dataset-for-Instruction-Tuning--Vmlldzo1NTcxNzE2

So there are many different ways that we could feed data when we do
the fine tuning, and I think we'd need to experiment a bit to see what
works.

Of course, we can also do this by enhancing the prompts that we give
to the review bot, but this chews up context window space, and
information in the review prompts have to be processed for every
single patch being reviewed.  (Possibly multiple times if the review
bot using multiple passes.)

						- Ted