There exists a particular species of product demonstration, beloved of pitch decks and doomed start-ups in roughly equal measure, in which one feeds a user's medical history to a large language model, requests a week of meals, and receives back something that has every outward appearance of expertise. It is a magnificent illusion. It is also, on occasion, a scenic route to the nephrology ward.
I say this with feeling, because the first version of our own recommender did something adjacent to it, and I would like to spend the next several thousand words explaining what was wrong, what we are building instead, and why the interesting parts of this problem are precisely the parts that nobody puts on a slide.
The product, so that we are all standing in the same place: a nutritionist that does not merely lecture you about what to eat, but plans it, portions it, sources it, and delivers it to your door, every day, adjusting as your life adjusts. One platform, many masters. The powerlifter mid-bulk, the gentleman managing his prediabetes, the woman who declared herself vegan on Tuesday and expects the system to have noticed by Wednesday, the harried soul who simply wishes to stop inhaling crisps at nine in the evening. Same machine, different constraints. The promise is a single sentence. The engineering is the rest of this essay.
First, a confession about the current implementation
Let me be candid, since candour is a good deal cheaper than litigation: the recommender, as it presently stands, is bad. Not catastrophically, not negligently, but bad in the quiet, respectable way that a great many production systems are bad, which is to say it does something reasonable-looking and stops thinking.
It chooses your macronutrients rather in the manner of a horoscope choosing your fortune. It consults a formula devised for the average man of some decades ago, applies an activity multiplier plucked from a dropdown menu, splits the result into protein, carbohydrate and fat by a rule of thumb, and presents the outcome with the unearned confidence of a fortune-teller who has never once had to reconcile a prediction against reality. And then, for the actual meals, it leans far too heavily on a language model to assemble the plate, which is the computational equivalent of asking a very well-read parrot to do your accounts.
The trouble is not that any single piece is indefensible. The trouble is that the whole thing treats a hard problem as though it were an easy one. Choosing what a specific human being should eat, given their goals and their ailments and their appetites and their tediously specific dislikes, is not a text-generation problem. Nor is it a single prediction problem. It is at least three problems in a trench coat, and they want three different tools.
Choosing the macros: the part everyone skips
Before a single ingredient is selected, something has to decide what the meal is even trying to achieve. How many calories. How much protein, and how it is spread across the day. How much sodium a hypertensive user may have before we do him a mischief. How much potassium and phosphorus a stage-four kidney patient can tolerate before the meal becomes, in the most literal sense, hazardous. How large the portions should be for someone whose GLP-1 medication has quietly reduced their appetite to that of a small bird.
The naive approach, the one we shipped, is a static formula: estimate basal metabolic rate, multiply by an activity guess, subtract a deficit for weight loss or add a surplus for muscle gain, apply a macro split, and be done. This is fine as a starting hypothesis and disastrous as a permanent belief, because it assumes the formula was right about you in the first place, and formulas are right about populations, not people. Two men of identical height, weight and age can have genuinely different energy expenditures, and the formula, serenely, does not care.
The better approach treats target-setting as a small but real modelling problem in its own right, with three ideas stacked on top of one another.
The first idea is a sensible baseline. Established equations for basal metabolic rate, activity multipliers informed by actual wearable data rather than a self-reported guess (people, it turns out, are magnificent liars about how much they exercise), and goal-driven adjustments grounded in the literature: something in the region of 1.6 to 2.2 grams of protein per kilogram for hypertrophy, a restriction toward 0.6 to 0.8 for compromised kidneys, sodium ceilings for the cardiovascular set, carbohydrate distribution for glycaemic control. This gives us a defensible first prescription.
The second idea, and the one that separates a nutrition product from a spreadsheet, is that the targets adapt to observed reality. This is a closed-loop control problem, not a one-time calculation. We predict that a given calorie target will produce a given rate of weight change; we then watch what actually happens; and we correct. If the deficit we prescribed is producing no movement on the scale over a fortnight, the deficit was wrong, or the intake estimate was, and the target engine adjusts accordingly, taking care to filter out the daily theatre of water weight and other noise rather than lurching about in response to it. Certain fitness applications already do a version of this, and do it well; the principle is that a target you never revise is a target you have simply decided to be wrong about slowly.
The third idea is that the hard medical bounds are not suggestions. Whatever the model prefers, whatever the user requests, the potassium ceiling for the renal patient is a wall, not a nudge. This is the recurring theme of the entire architecture, so I shall repeat it until you are sick of it: the things that can hospitalise a person are enforced as guarantees, never as probabilities.
Here is roughly how the various inputs translate into the numbers, before a recipe is ever considered:
| What the user brings | What it does to the targets |
|---|---|
| Goal (cut, bulk, recomposition, glycaemic control, renal) | Sets the calorie delta and the macro emphasis; a protein floor for muscle, a deficit for fat loss, a carbohydrate ceiling for glucose |
| Dietary restriction (vegan, kosher, halal, and the rest) | Reshapes which ingredients can supply those macros, which is a supply-side matter as much as a nutritional one |
| Medical conditions and medications | Impose hard upper and lower bounds; encode drug and nutrient collisions such as warfarin against vitamin K, or ACE inhibitors against potassium |
| Quantity and appetite | Governs portion size and meal frequency; a suppressed appetite means smaller, denser, more frequent plates rather than three intimidating ones |
| Wearables and track record | Personalise the expenditure estimate and, over time, the adaptive correction |
Only once the machine knows what it is aiming for does the question of actual food arise. Which brings us to the plate.
Composing the plate, and the tyranny of doing it at scale
Given a set of nutritional targets and a wall of hard constraints, the task is to assemble real meals from real ingredients that hit the numbers, respect every restriction, and, ideally, taste of something. This is where the constrained optimiser lives, and it is the beating heart of the system, the language model's protestations notwithstanding.
There are, pleasingly, two nested problems here. The first is selection: choosing which dishes or components go on the plate such that their totals land within the target bands. This has the flavour of a constrained knapsack, and it is naturally expressed as a mixed-integer program. The second, more delicate, is portioning: given a chosen set of ingredients, scaling their quantities so that the macros come out precisely right. This is a continuous optimisation, a tidy little linear program over ingredient amounts subject to nutritional equalities and inequalities, and it is precisely where the notion of quantity earns its place. The optimiser is not choosing a vague “chicken and rice”; it is deciding on one hundred and seventy grams of the former and ninety of the latter because that is what closes the gap to your protein floor without breaching your calorie ceiling.
The virtue of an optimiser over a predictive model, here, is not intelligence. It is that a constraint you instruct it to satisfy is satisfied, provably, every single time. No shellfish means no shellfish, with the finality of arithmetic. A language model, by contrast, will inform you with the untroubled serenity of a man who has never been held accountable because he has never been wrong that this dish contains no shellfish, and it will be mistaken, and you will discover this at the hospital.
The genuinely hard part is not writing the optimiser. It is running it for millions of people without the whole apparatus grinding to a halt. You do not, at Uber Eats scale, solve an enormous integer program from scratch for every user on every request; that way lies bankruptcy and a very warm data centre. The industry solved this shape of problem long ago, and the answer is a funnel. First, cheap and fast candidate generation narrows a vast catalogue down to a plausible few hundred. Then constraint filtering removes anything that violates a hard rule. Then the comparatively expensive optimiser does its precise portioning work on the shortlist rather than the universe. Then ranking decides the final order. Two stages, sometimes three: retrieve broadly and cheaply, then reason narrowly and expensively. It is the same architecture that serves you videos and shopping and, apparently, potential spouses, repurposed for the humbler business of dinner.
Drag to pan · Ctrl/⌘+scroll to zoom · % resets to fit · Full for fullscreen
Read that from the top, because that is the order in which decisions are made, and note where the nutritionist stands: guarding the door to anything with medical consequences, which is the one place a human being is not optional.
At scale, the neural networks stop being a luxury
I was previously rather dismissive about neural networks, on the grounds that a young system without data has no business reaching for a hungry model it cannot feed. That advice holds on day one and expires shortly thereafter. Once you are operating at anything resembling serious scale, the neural networks stop being an indulgence and start being the obvious answer, and it would be a peculiar sort of stubbornness to pretend otherwise.
Consider what “will this person like this meal” actually requires. Gradient-boosted trees, the honest workhorses of tabular prediction, will get you a very long way on features you can name: cuisine affinity, past ratings, the meals that got swapped out in a huff, the time of day, the day of the week. They are cheap, they are fast, they are interpretable, and for the first stretch of a company's life they are frankly the correct choice. But taste is not merely tabular. It is relational and it is temporal, and those are exactly the properties that deep learning was invented to exploit.
Relational, because dishes and ingredients and users form a great sprawling graph, and a graph neural network can learn that a person who adores one thing will probably tolerate its neighbours in flavour-space, even ones they have never tried. Temporal, because appetite has a memory: serve someone grilled chicken for five consecutive evenings and their enthusiasm will decline in a manner no static model anticipates, whereas a sequence model, a transformer over their eating history in the mould of the sequential recommenders that now underpin most large platforms, captures satiety and variety and the slow drift of preference as a matter of course. And representationally, embeddings let you retrieve candidates by learned similarity at a speed that brute-force filtering could never touch, which is what makes the funnel's first stage viable at all.
The most elegant part is that you need not train a separate model for each thing you wish to predict. A single deep architecture with a shared trunk and several heads, the multi-task arrangement that the large recommendation systems have converged upon, can predict at once whether a meal will be rated well, whether it will be reordered, whether it will be finished rather than binned, and even its likely effect on the user's glucose. The tasks share what they have in common and specialise where they differ, and the whole is a good deal more sample-efficient than a drawer full of single-purpose models.
There is a subtler point, and it is the one that most distinguishes a nutrition recommender from a system that suggests you another video. If you only ever recommend what the model is confident a person will enjoy, you will never learn what else they might enjoy, and you will never introduce the variety that a decent diet requires. So you must explore deliberately, and the tool for exploring without wrecking the experience is a contextual bandit, Thompson sampling and its relatives, which balances showing people what you know they like against occasionally taking a considered gamble. It is also, incidentally, how you handle a brand-new user about whom you know nothing, and how you keep the menu from calcifying into the same joyless rotation of six meals. Exploration is not a nicety here. It is a nutritional obligation dressed as a statistics technique.
The feedback loop, or how the system learns you are not, in fact, average
Here is the omission I am least proud of, and the one my more attentive readers rightly seized upon: none of the above matters unless the thing learns from what happens next. A recommender that never updates is merely an opinion with a database. The entire value of the apparatus is that every meal produces evidence, and the evidence flows back and makes the next meal cleverer.
The signals arrive from several directions and at several speeds, and the discipline lies in routing each to the place it belongs rather than dumping them all into one indiscriminate heap.
There are the taste signals, immediate and plentiful: the ratings, the thumbs, the meals swapped out in irritation, the ones finished versus the ones that came back in the box untouched. These are the raw material of the preference ranker, and they update it continuously, or near enough.
There are the constraint changes, which arrive most often not through a settings page but through conversation. Someone mentions, in passing, that they have gone vegan, or that shellfish has lately begun to disagree with them, or that they started semaglutide last week. These are not chit-chat; they are amendments to the user's profile, and they must be written back into it and made to re-trigger the whole optimisation, with the important caveat that a medical or medication change routes through a human nutritionist before it is permitted to alter what actually turns up at the door.
There are the outcome signals, slower but far more truthful than any rating: the trajectory of weight, the glucose response where a monitor is worn, the plain adherence data of whether the person is eating the plan at all. This is the ground truth of whether the whole endeavour is working, and it closes the loop not on taste but on the target engine, feeding the adaptive control I described earlier. A plan that people love and that produces no results is a failure, however many stars it collects.
And then there are the expert corrections, which are gold, because they are the rarest and most valuable label of all. When a nutritionist reviews a plan and edits it, or overrides a recommendation, or rewrites a chatbot's answer, that correction is a labelled example of expertise, and it deserves to be treasured accordingly. It fixes the immediate case; it feeds the ranker; and, as we shall see in a moment, it becomes the raw material for teaching the language model to be less of an amateur.
Drag to pan · Ctrl/⌘+scroll to zoom · % resets to fit · Full for fullscreen
Now, a warning, because feedback loops are not an unalloyed good and anyone who tells you otherwise has not run one. A recommender that optimises purely for what you will happily eat will, with the grim inevitability of gravity, discover that you will happily eat chips. Every day. Forever. This is a triumph of engagement and a catastrophe of nutrition, and it is precisely the trap into which content-recommendation systems fall before congratulating themselves on their click-through rates. The feedback loop, left to its own devices, produces a filter bubble; the filter bubble, in a nutrition product, produces a diet of monotonous comfort food that is very often exactly what got the person into difficulty in the first place.
The defence is threefold. You optimise for the correct objective, which is health outcome and adherence together rather than mere enjoyment, because a system that maximises what people will eat has simply automated the problem it was hired to solve. You impose diversity as a constraint, not a hope, so that variety is enforced rather than left to chance. And you keep exploring, so the model's picture of a person is continually refreshed rather than ossifying into a caricature assembled from their weakest moments. The reward function is the soul of the machine, and if you point it at the wrong quantity you will get a system that is superbly optimised for making everyone slightly worse.
Teaching the chatbot to sound like it went to school for this
The language model, throughout all of this, has a job, and it is emphatically not to decide what is safe to eat. Its job is to be the part of the system that listens and speaks: to conduct the intake, to answer the questions, to explain why the plan is what it is, to coach and cajole and occasionally console. The whole difference between a chatbot and an actual nutritionist is that a nutritionist listens, remembers, and adjusts, and so the model must be wired into the machine rather than bolted on beside it as a decorative oracle.
For now, and I want to be honest about the “for now,” this is achieved with prompt engineering and grounding, which is a respectable place to start and a foolish place to stop. The model reads the user's assembled context, their profile and constraints and recent meals and the drift of their wearables, so that when asked why this week is so aggressively poultry-based it can answer from what it already knows rather than inventing something plausible. It answers nutritional questions not from the swirling contents of its own training but from a curated, retrievable body of evidence: clinical guidelines, the established dietary frameworks, our own food and nutrient data, with citations, and when the grounding does not cover the question the correct answer is “I do not know, let me fetch a human,” rather than a confident fabrication delivered in an authoritative tone. And it stays in its lane, refusing to diagnose, declining to overrule a safety constraint, escalating anything clinical to a person who is qualified to own it.
But prompt engineering has a ceiling, and the way through it is fine-tuning, driven by exactly the human interactions and expert corrections the feedback loop is already collecting. This is where the nutritionists' edits stop being mere fixes and start being a training set. When a nutritionist rewrites a poor answer into a good one, you have a pair: the flawed response and the corrected one, which is precisely the raw material of supervised fine-tuning. When nutritionists rank competing responses, or when the accumulated thumbs tell you which answers people trusted, you have preferences, which you can distil into an aligned model through direct preference optimisation, the pragmatic and considerably less temperamental cousin of full reinforcement learning from human feedback. And once you know what good looks like, you can distil a large, expensive model's behaviour into a smaller, cheaper one that you can actually afford to serve at scale, which is a happy convergence of alignment and economics.
Drag to pan · Ctrl/⌘+scroll to zoom · % resets to fit · Full for fullscreen
Two things about this deserve emphasis, lest anyone get carried away. The first is that a fine-tuned model is still not permitted to own a safety decision; all the training in the world improves how it converses and how reliably it extracts a constraint change from a rambling message, but the allergen wall and the potassium ceiling remain the optimiser's inviolable business. The second is that none of this fine-tuning is worth attempting until you have volume, because you cannot align a model on a handful of anecdotes, and pretending otherwise merely overfits to the opinions of whichever three nutritionists you happened to have on staff in the first month.
Which is why the evaluation apparatus matters as much as the models, and why it, too, leans on the humans. The scalable backbone is a strong model acting as judge, scoring every response for whether it is grounded, whether it is safe, whether it stayed in scope, whether it was actually useful, whether the numbers are right. But an automated judge has its own well-catalogued vices, a fondness for verbosity, a sensitivity to ordering, a tendency to wander from human judgement, and so the nutritionists design the rubric in the first place, defining what “clinically acceptable” even means for a renal answer as against a bulking one; they label the reference set against which the judge is calibrated, so we know how faithfully the judge tracks real expertise before we trust it at volume; and for anything touching medication or allergens or a diagnosis, they audit the live output continuously. Humans define how we grade and patrol the dangerous tail; the model does the tireless middle. The nutritionist in the loop is not a stopgap awaiting a cleverer model. She is the reason anyone should trust the cleverer model at all.
The architecture, concretely
Enough narrative. For the reader who would like the whole contraption on a single page, with the actual techniques named and the hand-waving held to a decent minimum, here it is, component by component.
| Component | What it actually is | What trains or drives it | Why this, and not something cleverer |
|---|---|---|---|
| Target engine | A formula baseline (basal metabolic rate plus an activity term), graduating to a learned regressor and then a closed-loop controller that revises the numbers against measured weight and glucose | Outcome data: the weight trajectory, the glucose response, the plain fact of adherence | A static equation is a confident guess; a controller corrects itself. The medical bounds sit on top as hard clips, whatever the model prefers |
| Candidate generation | A two-tower retrieval model, the user tower matched against the dish tower, with an approximate-nearest-neighbour index over learned dish embeddings | Interaction history, trained with a retrieval objective | You cannot run a fresh optimisation over the entire catalogue for every user on every request without setting fire to the budget; you retrieve a few hundred candidates cheaply, then reason over those |
| Constraint filter | A deterministic rule engine over hard exclusion sets | Encoded clinical and dietary rules, emphatically not learned | Allergens and drug interactions are guarantees, not predictions. A rule that must hold is not a job you hand to a probabilistic model and hope |
| Portion optimiser | A linear or mixed-integer program over ingredient quantities (OR-Tools, HiGHS) | Nutrient targets expressed as constraints; an objective that trades macro error against cost and variety | This is where quantity is settled to the gram. Optimisation gives provable satisfaction of the targets; a model gives a plausible-looking approximation |
| Ranker | Gradient-boosted trees first (LightGBM), then a deep ranker with several heads (predicted rating, reorder, completion, glucose response), the tasks balanced by a mixture-of-experts | Explicit and implicit feedback, retrained on a schedule with fresh online features | Trees are the honest first tool on tabular data; the deep multi-task model earns its keep only once the data is genuinely large |
| Sequence model | A self-attentive transformer over the eating history, in the SASRec and BERT4Rec lineage | The ordered record of what was eaten, finished, and quietly abandoned | It captures satiety and the slow drift of taste that no static model sees, and it is what spares the user five consecutive evenings of chicken |
| Graph model | A graph neural network over the user, dish and ingredient graph | The relational structure of who ate what, and what shares ingredients with what | It generalises preference to dishes a person has never tried, and it rescues the cold-start case |
| Exploration | A contextual bandit, Thompson sampling and its relatives, sitting above the ranker | Reward drawn from downstream engagement and, more to the point, adherence | Pure exploitation collapses into monotony; deliberate exploration is, in a nutrition product, an obligation wearing the costume of a statistics technique |
| Conversational layer | A large language model with retrieval-augmented generation over a curated knowledge base and a drug-interaction rule set, function-calling to write profile changes back, behind a guardrail classifier | Prompt engineering and grounding now; supervised fine-tuning on nutritionist corrections and preference tuning later | The only tool fit for open language, and the only one that fabricates, so it advises, explains and converses but is never permitted to guard safety |
| Evaluation | A language model acting as judge, scored against a human-calibrated rubric, with continuous human audit of the dangerous tail | Nutritionist-authored rubrics and labelled reference sets | Automated judging scales to volumes no human could review; human calibration is what keeps it honest about precisely the cases that can hurt someone |
And the whole apparatus, wired together, so you can see how the pieces actually talk to one another:
Drag to pan · Ctrl/⌘+scroll to zoom · % resets to fit · Full for fullscreen
Where one begins
None of this arrives fully formed, and it would be dishonest to imply it should. The first honest version is the optimiser over a curated catalogue, a modest gradient-boosted ranker, and a nutritionist signing off on anything with medical stakes, with the language model kept a respectful distance from the safety-critical path. The neural networks and the sequence models and the graph embeddings arrive when the data has grown large enough to justify their appetites. The fine-tuning arrives when the conversations and corrections have accumulated into something worth learning from. And the whole thing compounds, because every reorder sharpens the ranker, every corrected plan enriches the rules, and the localised map of real cuisines to real nutrition, painstaking and unglamorous and tied to dishes you can genuinely produce, is exactly the sort of asset that is miserable to build and therefore rather difficult to steal. The models, in the end, are mostly a commodity. The proprietary preference data, the localised nutrition graph, and the accumulated trust of a profession are not.
Conclusion
If a single thesis has survived all this verbiage, let it be this: do not ask one model to be the entire nutritionist. The problem only looks like a text-generation task from a comfortable distance; up close it is at least four problems with entirely different temperaments, and the whole art is in giving each one the tool it deserves. Let constrained optimisation guarantee the things that must never go wrong, the allergens and the drugs and the potassium ceilings, because those are matters of arithmetic and not of vibes. Let gradient-boosted trees, and then the neural networks once the data has earned them, learn what a particular human will actually eat and reorder. Let the language model do the talking it is genuinely good at, grounded and fenced and made steadily less amateurish by the corrections of real nutritionists rather than by wishful prompting. And keep a qualified human standing at the one door where being wrong is not an available option.
The feedback loop is what turns this from a clever prototype into a system that compounds, and it is simultaneously the thing most likely to ruin you quietly, because a recommender pointed at the wrong objective will lovingly optimise your users into a contented, monotonous decline. Point it at outcomes, enforce variety, keep exploring, and it becomes a genuine asset that is thoroughly miserable for anyone else to reproduce. That misery, incidentally, is the moat: the models are a commodity, but the localised map of real food to real nutrition, the accumulated preference data, and the trust of a licensed profession are not.
Begin small. The optimiser, a modest ranker, and a nutritionist with a veto. Let the data pull in the heavier machinery as it arrives, rather than importing a graph transformer to serve four hundred users and calling it sophistication. The alternative, the single confident model that plans, portions and reassures all by itself, will feel like progress right up until the telephone rings from the hospital. Build the boring, layered, auditable thing instead. Your users, and their kidneys, will thank you for it.
References
The load-bearing empirical and technical claims above, with the canonical machine-learning papers included for anyone who wants the primary sources rather than my paraphrase of them. Page ranges use plain hyphens by preference.
Large language models and the safety of AI-generated nutrition
- “From bytes to bites: application of large language models to enhance nutritional recommendations.” Clinical Kidney Journal 18(4), sfaf082 (2025). The ChatGPT-4 dialysis meal-plan analysis that found systematic underestimation of calories, protein, phosphorus, potassium and sodium against USDA reference values. https://doi.org/10.1093/ckj/sfaf082
- “Assessment of large language model chatbots for hemodialysis meal planning: a descriptive study.” BMC Nephrology (2026). Every model tested underestimated the potassium and phosphorus content of its own meal plans, a direct route to hyperkalaemia and hyperphosphataemia. https://doi.org/10.1186/s12882-026-04936-8
- Kaya Kaçar, H., Kaçar, Ö. F., and Avery, A. “Diet Quality and Caloric Accuracy in AI-Generated Diet Plans: A Comparative Study Across Chatbots.” Nutrients 17(2), 206 (2025). Over half of one model's plans deviated from the requested calorie target by more than 20%. https://doi.org/10.3390/nu17020206
- Niszczota, P., and Rybicka, I. “The credibility of dietary advice formulated by ChatGPT: Robo-diets for people with food allergies.” Nutrition 112, 112076 (2023). ChatGPT can generate diets that include the very allergens it was instructed to avoid. PMID 37269717.
Nutrition science
- Jäger, R., et al. “International Society of Sports Nutrition Position Stand: protein and exercise.” Journal of the International Society of Sports Nutrition 14, 20 (2017). https://doi.org/10.1186/s12970-017-0177-8
- Morton, R. W., et al. “A systematic review, meta-analysis and meta-regression of the effect of protein supplementation on resistance training-induced gains in muscle mass and strength in healthy adults.” British Journal of Sports Medicine 52(6), 376-384 (2018). Identifies roughly 1.6 g/kg/day as the point of diminishing returns.
- Ikizler, T. A., et al. “KDOQI Clinical Practice Guideline for Nutrition in CKD: 2020 Update.” American Journal of Kidney Diseases 76(3, Suppl. 1), S1-S107 (2020). Source of the protein-restriction figures for chronic kidney disease.
- Hall, K. D., et al. “Quantification of the effect of energy imbalance on bodyweight.” The Lancet 378(9793), 826-837 (2011). The dynamic energy-balance model that underpins adaptive, self-correcting calorie targets.
Optimisation and the diet problem
- Stigler, G. J. “The Cost of Subsistence.” Journal of Farm Economics 27(2), 303-314 (1945). The original least-cost-diet formulation.
- Dantzig, G. B. “The Diet Problem.” Interfaces 20(4), 43-47 (1990). How the simplex method solved Stigler's problem, landing within 24 cents a year of his hand-computed answer.
Recommender systems and deep learning at scale
- Covington, P., Adams, J., and Sargin, E. “Deep Neural Networks for YouTube Recommendations.” RecSys (2016). The canonical two-stage candidate-generation-then-ranking architecture.
- Cheng, H.-T., et al. “Wide & Deep Learning for Recommender Systems.” DLRS at RecSys (2016).
- Naumov, M., et al. “Deep Learning Recommendation Model for Personalization and Recommendation Systems” (DLRM). arXiv:1906.00091 (2019).
- Kang, W.-C., and McAuley, J. “Self-Attentive Sequential Recommendation” (SASRec). ICDM (2018).
- Sun, F., et al. “BERT4Rec: Sequential Recommendation with Bidirectional Encoder Representations from Transformer.” CIKM (2019).
- Ma, J., et al. “Modeling Task Relationships in Multi-task Learning with Multi-gate Mixture-of-Experts” (MMoE). KDD (2018).
- Li, L., Chu, W., Langford, J., and Schapire, R. E. “A Contextual-Bandit Approach to Personalized News Article Recommendation” (LinUCB). WWW (2010).
- Jiang, R., Chiappa, S., Lattimore, T., György, A., and Kohli, P. “Degenerate Feedback Loops in Recommender Systems.” AAAI/ACM AIES (2019). arXiv:1902.10730.
- Mansoury, M., et al. “Feedback Loop and Bias Amplification in Recommender Systems.” CIKM (2020).
- Pariser, E. The Filter Bubble: What the Internet Is Hiding from You. Penguin Press (2011).
LLM alignment, retrieval and evaluation
- Lewis, P., et al. “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.” NeurIPS (2020). arXiv:2005.11401.
- Ouyang, L., et al. “Training language models to follow instructions with human feedback” (InstructGPT). NeurIPS (2022). arXiv:2203.02155.
- Rafailov, R., et al. “Direct Preference Optimization: Your Language Model is Secretly a Reward Model.” NeurIPS (2023). arXiv:2305.18290.
- Zheng, L., et al. “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.” NeurIPS (2023). arXiv:2306.05685. Documents judge biases including the fondness for verbosity and sensitivity to ordering.

