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

[Mauro Carvalho Chehab <mchehab+huawei@kernel.org>]

On Fri, 17 Jul 2026 16:21:19 -0400
"Theodore Tso" <tytso@mit.edu> wrote:

> 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.

As the models it current using are just picking everything, if the
distilled model is fine-tuned with unstructured text, I would expect
a similar result to what Sashiko currently produces.

Sure if someone or some code could manually weight multiple patch
series version with their merge status and reviews, the trained
model will probably work better.

As models are usually trained multiple times with the same database,
perhaps we can start with unfiltered lore data.


Thanks,
Mauro