Posted by minsufficient 5 days ago
1. Give "strong" LLM the task formulation and some labeled examples. Ask it to generate a prompt for the "weak" LLM.
2. Run "weak" LLM on the training set with generated prompt from 1, use replies as features for a smaller ML model (logreg, decision tree etc).
3. Pick examples from the training set that your small model is most wrong about and ask "strong" LLM to generate one more prompt (like in 1), except this time you are using the misclassified examples instead of random.
4. Run "weak" LLM on generated prompt from 3, add results as one more feature for your model.
5. Repeat 2 - 4 until your token budget for this task is exhausted or required score on cross validation set is reached.
I was thinking about creating an open source library that implements this, but I'm not sure if anyone really needs it. I suspect that people who need something like this already made their own implementation.
2 cooperating bodies thinking or acting as one moving force just makes sense, or so much more sense than a system that is one single approach but single minded, or even 2 regular LLMs working in tandem. It’s still not the same as them being fully cooperative or working hyper-cooperatively, and what you suggest technically forces that cooperation to some degree. It’s just ideal to have these aims view themselves as a “single body” like the system 1 and 2 concept works within our heads.
For this reason it’s why I feel the current loony approach where chatgpt mails Claude and refers to it by name or anything where 2 Standard (‘Selfish’) LLMs interact is generally ineffective or inefficient. They’re coerced to cooperate and naturally wouldn’t or have no natural imperative to do so.
They (‘Large’ LLMs atleast) have their own inherent preconceived views and idea of ‘self’ programmed in, but beyond this will naturally not always have the same ideas or shared perspective on what to do, which will naturally lead to issues within cooperation towards a shared goal. This would naturally impact the final product of the prompts or otherwise diminish returns on efforts made there. It’s all natural.
https://softwaredoug.com/blog/2025/01/21/llm-judge-decision-...
FWIW I also liked this (very different) post of yours: https://softwaredoug.com/blog/2026/07/13/who-want-to-be
It's very often (always?) the case that something general also solves particular problems.
A sorting algorithm is an implementation of min()
A parser also is a syntax checker.
A route planner is a reachability checker.
A computer algebra system is a basic arithmetic calculator.
A general constraint solver is a Soduku hint maker.
Fundamentally I read this article as: We want to build a simpler, dumbed down clone of Mathematica, so we cobbled together the following pieces... We also needed a way to do arithmetic, so we also include a copy of Mathematica to do basic arithmetic.
What I'm not sure about is how stable those features are when you switch the underlying LLM or model version.
This is a bit of an outdated take as of two days ago. Dear lord things move fast these last few years. Some of this is still relevant. Fine tuning Jev once available could address certain concerns.
(Very excited as I got an invite email for TypeSafe today! I don’t have time for all the little experiments I want to run with Jev and Astra combined!)
I see a bunch of people saying that there were already similar solutions in this space. Maybe true but it definitely feels like the missing primitive for working with llms. Can immediately see how it can be deployed in real applications in a way that the autoregressive chat approach can’t.
Also, I think that’s what you’d like the article to be about. Not that you’re unfounded, I’m sure others are thinking the same.
But to further dissect that, having any article be just about the cons and not including pros is in its nature, reductive. There certainly are pros (I have no stake in this race for the record) and model use choice should be seen as situational. To seek a silver bullet is itself reductive and thus, something we should avoid as it’s ultimately a fools errand imo.
Anyways, this article is plenty good. Thanks for the writeup OP.
Maybe these are well understood terms in some field? Maybe I'm just lost?
The point about beta (which I think the equation doesn't actually reflect) is just to indicate that this approach risks nothing because, worst case scenario, the weights you assign to the model can simply return the original LLM prediction. Keep in mind that 0*inf=0 and that LLM(x) only returns 0 or 1, so it's not accurate to say that the sigmoid would always return 1.
The function I() is the indicator function [1] which, in this case, returns 1 if the argument is true and 0 otherwise. It's only there to convert booleans to integers because summing booleans is not defined.
Having said that, if
- y is a binary "ironic"(1), "not ironic"(0) label and
- x is the content of a tweet and
- LLM(x) is meant to represent some probability range [0,1] representing p(y=1|x)
Why bother with p(y=1|x) = σ( α + β*LLM(x) ) as in the article? You are right that I missed the case where LLM(x) = 0, but that just means that p(y=1|x) has exactly 2 values when defined as above and β -> inf.
- when LLM(x) = 0 then p(y=1|x) = 1/(1+e^-α)
- when LLM(x) = (0,1] then p(y=1|x) = 1/(1+e^-inf) = 1
My point is that when math is used to justify something or communicate something, it should be explained or very apparently right. If when someone goes to try to understand the math it doesn't match the claims being made in the article ("recovering the LLM") then it throws the rest of the article into doubt.
For example you could freeze most of the layers of the embedder but let the final ones learn. Then you wouldn’t need to do either feature or prompt engineering?
Use binary questions rather than multi-class. Then you can use the consistency as another signal of your pipeline working or not, on top of accuracy.