AlignEval: Building an App to Make Evals Easy, Fun, and Automated

eugeneyan

eugeneyan

Начните отсюда Тексты Выступления Прототипирование Обо мне

AlignEval: Building an App to Make Evals Easy, Fun, and Automated

AlignEval: создаём приложение, которое делает оценки простыми, увлекательными и автоматизированными

[ llm eval learning 🛠 🩷 ] · 14 min read

[ llm eval learning 🛠 🩷 ] · чтение на 14 мин

Go to aligneval.com to start building your own LLM-evaluator; sample data included.

Зайдите на aligneval.com, чтобы начать создавать собственный LLM-оценщик; примеры данных прилагаются.

Update: Now integrated with LangSmith and featured on VentureBeat! 🎉

Обновление: теперь интегрировано с LangSmith и упомянуто на VentureBeat! 🎉

Every AI-powered product needs evals. But let’s face it—they’re a pain to build, hard to scale, and most teams get them wrong. As a result, many AI-powered experiences are bottlenecked on evals, sometimes delaying launches by weeks or even months.

Любому продукту на базе ИИ нужны оценки. Но признаем честно — их мучительно строить, трудно масштабировать, и большинство команд делает их неправильно. В результате многие ИИ-продукты упираются в оценки как в узкое место, иногда задерживая запуски на недели или даже месяцы.

I’ve spent the past year or so wrestling with product/task-specific evals. Testing different ways to detect hallucinations, finetune evaluators, and evaluate LLM-based evaluators. There were dead ends. There were rabbit holes. But I learned what works and what doesn’t.

Примерно последний год я бьюсь над оценками, специфичными для продукта и задачи. Я пробовал разные способы обнаруживать галлюцинации, дообучать оценщиков и оценивать сами LLM-оценщики. Были тупики. Были кроличьи норы. Но я понял, что работает, а что нет.

And that’s why I’m excited to introduce AlignEval, an app that makes evals easy and… fun? (Okay, I’ll settle for less painful.) It also tries to automate part of the process. AlignEval makes building LLM-evaluators as straightforward as four simple steps:

Именно поэтому я рад представить AlignEval — приложение, которое делает оценки простыми и… увлекательными? (Ладно, я согласен хотя бы на «менее мучительными».) Оно также пытается частично автоматизировать процесс. AlignEval сводит создание LLM-оценщиков к четырём простым шагам:

Загрузите CSV-файл со столбцами для входа и выхода. Посмотрите на данные и разметьте примеры как pass или fail. Задайте критерии оценки, запустите LLM-оценщик, проверьте результаты. Оптимизируйте LLM-оценщик на разбиении dev-test.

By the way, if you want to learn more about evals, my friends Hamel and Shreya are hosting their final cohort of “AI Evals for Engineers and PMs” in July. Here’s a 35% discount code.

Кстати, если вы хотите больше узнать об оценках, мои друзья Hamel и Shreya в июле проводят последний поток курса «AI Evals for Engineers and PMs». Вот промокод на скидку 35%.

Align AI to human. Calibrate human to AI. Repeat.

Выравнивайте ИИ под человека. Калибруйте человека под ИИ. Повторяйте.

The key insight is that aligning AI to human preferences is only half the battle. To build effective evals, we must also calibrate human criteria to AI output.

Ключевая мысль в том, что выравнивание ИИ под человеческие предпочтения — это лишь половина дела. Чтобы построить эффективные оценки, нужно ещё калибровать человеческие критерии по выходам ИИ.

Many teams make the mistake of crafting elaborate eval criteria without first looking at the data. It’s like theorizing about user experience and defects from the ivory tower, without doing error analysis. From Who Validates the Validators: “It is impossible to completely determine evaluation criteria prior to human judging of LLM outputs.”

Многие команды совершают ошибку, разрабатывая изощрённые критерии оценки, не посмотрев сначала на данные. Это всё равно что теоретизировать о пользовательском опыте и дефектах из башни из слоновой кости, не делая разбор ошибок. Из работы Who Validates the Validators: «Невозможно полностью определить критерии оценки до того, как человек оценит выходы LLM.»

This leads to two types of bad criteria. First, irrelevant criteria that are a waste of time, such as generic metrics (e.g., helpfulness) or very low probability defects (e.g., grammar, spelling). Second, unrealistic, unattainable criteria that the technology isn’t ready for, such as autonomous agents back in 2023. Either way, teams squander effort that would have been better invested in evaluating actual defects that occur with moderate frequency.

Это ведёт к двум типам плохих критериев. Во-первых, нерелевантные критерии — пустая трата времени, например общие метрики (скажем, полезность) или дефекты с очень низкой вероятностью (например, грамматика, орфография). Во-вторых, нереалистичные, недостижимые критерии, к которым технология ещё не готова, — например, автономные агенты ещё в 2023 году. В любом случае команды растрачивают усилия, которые лучше было бы вложить в оценку настоящих дефектов, встречающихся с умеренной частотой.

(I think out-of-the-box eval solutions fuel this problem, pushing generic criteria that are easy to plug and play but ignore the idiosyncrasies of your domain, product, and data.)

(Я думаю, готовые «из коробки» решения для оценки подпитывают эту проблему, навязывая общие критерии, которые легко подключить, но которые игнорируют особенности вашего домена, продукта и данных.)

The way to solve this—and build useful evals—is to work backward from the data. That’s what AlignEval tries to do by putting data and metrics first, not preset criteria or LLMs.

Способ решить это — и построить полезные оценки — двигаться от данных назад. Именно это и пытается делать AlignEval, ставя на первое место данные и метрики, а не заранее заданные критерии или LLM.

Getting started: Upload some data

Начало работы: загрузите данные

To get started, upload a CSV file containing the following columns:

Чтобы начать, загрузите CSV-файл со следующими столбцами:

id: позволяет сопоставлять размеченные и оценённые примеры с вашими данными input: контекст, передаваемый LLM для генерации выхода (например, текст для классификации, новости для резюмирования, извлечённые документы для ответа на вопросы) output: то, что генерирует LLM (например, метка классификации, резюме, ответ) label: ваше суждение о том, проходит ли выход (0) или не проходит (1)

Instructions to upload a CSV file.

Инструкция по загрузке CSV-файла.

If you don’t have a CSV handy, download a sample based on the Factual Inconsistency Benchmark. It contains 50 news articles, each with two summaries. One is factually consistent while the other is not. Perfect for AlignEval’s binary labeling task.

Если у вас нет готового CSV, скачайте образец на основе Factual Inconsistency Benchmark. Он содержит 50 новостных статей, у каждой по два резюме. Одно фактологически согласованно, другое — нет. Идеально для задачи бинарной разметки в AlignEval.

After uploading the CSV, you’ll see the data in a flexible table view. Adjust the width of the browser to control how wide or narrow you want the table and columns to be.

После загрузки CSV вы увидите данные в гибком табличном представлении. Меняйте ширину браузера, чтобы регулировать, насколько широкой или узкой будет таблица и столбцы.

How the table view looks after uploading a CSV file.

Как выглядит табличное представление после загрузки CSV-файла.

Labeling mode: Look at the data

Режим разметки: смотрите на данные

In labeling mode, our only job is to look at the data. AlignEval simplifies the process to a comparison between input and output fields. And for each sample, we only have to make a binary decision—pass or fail.

В режиме разметки наша единственная задача — смотреть на данные. AlignEval сводит процесс к сравнению полей input и output. И для каждого примера нам нужно принять лишь бинарное решение — pass или fail.

Instructions for labeling mode.

Инструкция для режима разметки.

Why binary labels? It leads to more accurate data, takes less time, and keeps cognitive load low. DoorDash adopted a similar approach. Similarly, Llama2 focused on collecting binary human preferences. The Llama2 authors also shared at a meetup that collecting binary preferences was much faster than writing samples for supervised finetuning.

Почему бинарные метки? Это даёт более точные данные, занимает меньше времени и снижает когнитивную нагрузку. DoorDash применил похожий подход. Аналогично, Llama2 делал ставку на сбор бинарных человеческих предпочтений. Авторы Llama2 также рассказали на митапе, что собирать бинарные предпочтения было намного быстрее, чем писать примеры для обучения с учителем (supervised finetuning).

What’s important is that we look at the data with an open mind, and not write criteria based on our priors. We should also resist the urge to prematurely define criteria. We need to first immerse ourselves in the data. This reduces the risk of hunting for nonexistent defects or chasing unrealistic expectations. By understanding what the LLM actually generates, we can define more meaningful, better-calibrated criteria.

Важно смотреть на данные непредвзято и не писать критерии исходя из наших предположений. Нам также стоит сопротивляться искушению преждевременно определять критерии. Сначала нужно погрузиться в данные. Это снижает риск охоты за несуществующими дефектами или погони за нереалистичными ожиданиями. Понимая, что LLM на самом деле генерирует, мы можем задать более осмысленные и лучше откалиброванные критерии.

Look at your data remix, courtesy of Jason Liu. Sign up for his next RAG course here.

Ремикс «Смотрите на свои данные» — благодаря Jason Liu. Запишитесь на его следующий курс по RAG здесь.

After labeling 20 rows, we unlock evaluation mode. (While evaluation mode is available after 20 labels, I think it’s too little to understand the data well enough to define criteria, and too small a sample for evaluation. I suggest aiming for 50-100 before writing criteria and running evals. The more familiar you are with your data, the better your evals will be.)

После разметки 20 строк мы разблокируем режим оценки. (Хотя режим оценки доступен после 20 меток, я считаю, что этого слишком мало, чтобы понять данные достаточно хорошо для определения критериев, и слишком маленькая выборка для оценки. Я советую стремиться к 50–100, прежде чем писать критерии и запускать оценки. Чем лучше вы знакомы со своими данными, тем лучше будут ваши оценки.)

Evaluation mode: Write criteria, evaluate the evaluator

Режим оценки: пишем критерии, оцениваем оценщик

After unlocking evaluation mode, we can now write our task-specific evaluation criteria. Keep it simple: Evaluate on a single dimension and return either 0 (pass) or 1 (fail).

Разблокировав режим оценки, мы можем теперь написать наши критерии оценки, специфичные для задачи. Держите их простыми: оценивайте по одному измерению и возвращайте либо 0 (pass), либо 1 (fail).

Instructions for evaluation mode.

Инструкция для режима оценки.

Here’s the prompt I use for factual inconsistency classification. We start with only two sentences that define what a pass or fail looks like. We can refine it after running the LLM-evaluator and examining the explanations and predictions.

Вот промпт, который я использую для классификации фактологической несогласованности. Мы начинаем всего с двух предложений, определяющих, как выглядит pass и fail. Мы можем уточнить его после запуска LLM-оценщика и изучения объяснений и предсказаний.

Writing the prompt and selecting models and fields.

Написание промпта и выбор моделей и полей.

Next, we choose our model (gpt-4o-mini or claude-3-haiku) and input fields (both input and output, or output only). For most tasks, (e.g., classification, summarization, Q&A), we want to compare the output to the input. Nonetheless, for some tasks, like evaluating style guide adherence or tone of voice, we only need the output. Focusing solely on the output reduces token cost and latency while potentially improving performance.

Далее мы выбираем модель (gpt-4o-mini или claude-3-haiku) и поля входа (либо input и output вместе, либо только output). Для большинства задач (например, классификации, резюмирования, Q&A) мы хотим сравнивать output с input. Тем не менее для некоторых задач, например оценки соблюдения стайлгайда или тона речи, нам нужен только output. Сосредоточение только на output снижает стоимость токенов и задержку, потенциально повышая при этом качество.

It’s also crucial to evaluate our LLM-evaluators against the labeled data. Hit “Evaluate” and we’ll see metrics in the top right corner: sample size, recall, precision, F1, Cohen’s $\kappa$, and counts for true and false positives/negatives.

Также крайне важно оценивать наши LLM-оценщики против размеченных данных. Нажмите «Evaluate», и мы увидим метрики в правом верхнем углу: размер выборки, recall, precision, F1, каппу Коэна $\kappa$, а также счётчики истинных и ложных срабатываний/пропусков (true и false positives/negatives).

Metrics to evaluate the LLM-evaluator.

Метрики для оценки LLM-оценщика.

If our sample size is low (e.g., 20), the metrics can fluctuate a lot, even when we rerun the same LLM-evaluator. This is due to LLM stochasticity. We can improve stability by labeling more data. Aim for at least 50 labeled samples which also unlocks optimization mode.

Если размер нашей выборки мал (например, 20), метрики могут сильно колебаться, даже когда мы перезапускаем тот же самый LLM-оценщик. Это связано со стохастичностью LLM. Стабильность можно повысить, разметив больше данных. Стремитесь хотя бы к 50 размеченным примерам — это также разблокирует режим оптимизации.

Optimization mode: Semi-automated improvements 🤞

Режим оптимизации: полуавтоматические улучшения 🤞

Optimization mode is where the magic (hopefully) happens. Click “Optimize” and let AlignEval do its thing to improve your LLM-evaluator. While it’s still in early beta, it’s achieved decent improvements for several use cases. (And no, it’s not dspy.)

Режим оптимизации — это место, где (надеюсь) происходит магия. Нажмите «Optimize» и дайте AlignEval сделать своё дело, чтобы улучшить ваш LLM-оценщик. Хотя он всё ещё в раннем бета-тесте, для нескольких сценариев он добился неплохих улучшений. (И нет, это не dspy.)

Instructions for optimization mode.

Инструкция для режима оптимизации.

Under the hood, optimization splits the labeled data into dev and test sets. (Since we’re not training a model, we call it a development split instead of a training split.) It then runs $n$ trials on the dev set to improve F1, using the same LLM and fields from evaluation mode. After $n$ trials, the improved LLM-evaluator is evaled on the unseen test set. In the table below, F1 starts at 0.571, increases to 0.722 at trial 5 on dev, then gets F1=0.727 on test.

Под капотом оптимизация делит размеченные данные на наборы dev и test. (Поскольку мы не обучаем модель, мы называем это разбиением для разработки (development split), а не обучающим разбиением.) Затем она запускает $n$ испытаний на наборе dev, чтобы улучшить F1, используя ту же LLM и поля из режима оценки. После $n$ испытаний улучшенный LLM-оценщик оценивается на невиданном тестовом наборе. В таблице ниже F1 стартует с 0,571, поднимается до 0,722 на испытании 5 на dev, а затем даёт F1=0,727 на test.

Metrics from optimization trials on all, dev, and test splits.

Метрики из испытаний оптимизации на разбиениях all, dev и test.

Sometimes, the dev and test metrics diverge significantly. With the small sample size (25 per split, 50 in total), this likely stems from the dev split being unrepresentative of the full data distribution, including the test split. Thus, the LLM-evaluator may overfit on the dev set and fail to generalize to the test set.

Иногда метрики на dev и test значительно расходятся. При малом размере выборки (25 на разбиение, 50 в сумме) это, вероятно, связано с тем, что разбиение dev нерепрезентативно для всего распределения данных, включая разбиение test. Таким образом, LLM-оценщик может переобучиться на наборе dev и не обобщиться на набор test.

To improve generalization across the dev and test splits, we can label more data, ensuring that it’s diverse and representative. To be diverse is to be balanced in both 0 and 1 labels, and the variety of inputs and outputs. To be representative is to be similar to real-world examples. We can also run multiple LLM-evaluators in parallel and ensemble their scores. PoLL showed that an ensemble of three smaller LLM-evaluators outperformed gpt-4.

Чтобы улучшить обобщение между разбиениями dev и test, мы можем разметить больше данных, обеспечив их разнообразие и репрезентативность. Быть разнообразным — значит быть сбалансированным как по меткам 0 и 1, так и по разнообразию входов и выходов. Быть репрезентативным — значит быть похожим на реальные примеры. Мы также можем запускать несколько LLM-оценщиков параллельно и объединять их оценки в ансамбль. PoLL показал, что ансамбль из трёх меньших LLM-оценщиков превзошёл gpt-4.

For a visual walkthrough, here’s a demo where I look at and label 50 rows of data lol.

Для наглядного разбора — вот демо, где я смотрю и размечаю 50 строк данных, лол.

Behind the scenes: How AlignEval was built

За кулисами: как создавался AlignEval

As a frontend development newbie (this is my first TypeScript app), I relied on the wisdom of the crowd, polling Twitter and LinkedIn for advice. I also built the same app five times to get a feel for several frameworks. Specifically, I tried FastHTML, Next.js, SvelteKit, and FastAPI + HTML (my go-to for prototyping).

Будучи новичком во фронтенд-разработке (это моё первое TypeScript-приложение), я опирался на мудрость толпы, опрашивая Twitter и LinkedIn в поисках совета. Я также построил одно и то же приложение пять раз, чтобы прочувствовать несколько фреймворков. В частности, я попробовал FastHTML, Next.js, SvelteKit и FastAPI + HTML (мой основной выбор для прототипирования).

From early prototypes, Next.js seemed to be a good fit. Intuitive, scalable, and the perfect excuse to learn TypeScript. And thanks to Cursor, my beginner questions were answered easily: What’s the difference between const and let? What is a prop? It also made it easier to build UX components and fix bugs 2-3x faster, keeping velocity and motivation high.

По ранним прототипам Next.js показался хорошим выбором. Интуитивный, масштабируемый и идеальный повод выучить TypeScript. А благодаря Cursor на мои новичковые вопросы легко находились ответы: в чём разница между const и let? Что такое prop? Он также упростил создание UX-компонентов и исправление багов в 2–3 раза быстрее, поддерживая высокий темп и мотивацию.

For the backend, Python + FastAPI was the obvious choice. Python’s ecosystem of data analysis and machine learning made it easier to experiment with optimization mode.

Для бэкенда Python + FastAPI был очевидным выбором. Экосистема Python для анализа данных и машинного обучения упростила эксперименты с режимом оптимизации.

When it came to LLMs, I went with the smallest models from the biggest labs: gpt-4o-mini and claude-3-haiku (soon to be claude-3.5-haiku). They’re cheap, fast, and good enough for binary classification LLM-evaluators. It’s the perfect combo for a free app. And with each release, these small models just keep getting more and more capable.

Когда дело дошло до LLM, я выбрал самые маленькие модели от крупнейших лабораторий: gpt-4o-mini и claude-3-haiku (скоро claude-3.5-haiku). Они дешёвые, быстрые и достаточно хороши для LLM-оценщиков бинарной классификации. Идеальная комбинация для бесплатного приложения. И с каждым релизом эти маленькие модели становятся всё более и более способными.

For gpt-4o-mini, I used the structured output functionality that’s still in beta. It allows users to define the desired output schema using Zod (JavaScript) or Pydantic (Python). Here’s an example in Javascript and its equivalent in Python:

Для gpt-4o-mini я использовал функциональность структурированного вывода, которая пока в бете. Она позволяет пользователям задавать желаемую схему вывода с помощью Zod (JavaScript) или Pydantic (Python). Вот пример на JavaScript и его эквивалент на Python:

import { z } from "zod"; const EvaluationResponse = z.object({ explanation: z.string(), prediction: z.string().refine((val) => val === '0' || val === '1') });

import { z } from "zod"; const EvaluationResponse = z.object({ explanation: z.string(), prediction: z.string().refine((val) => val === '0' || val === '1') });

from pydantic import BaseModel class EvaluationResponse(BaseModel): explanation: str prediction: str

from pydantic import BaseModel class EvaluationResponse(BaseModel): explanation: str prediction: str

For claude-3-haiku, I defined the XML output via the prompt. From what I’ve seen on the job and in AlignEval, this works 99.9% of the time. Here’s the prompt I used for AlignEval.

Для claude-3-haiku я задавал XML-вывод через промпт. По моему опыту на работе и в AlignEval, это срабатывает в 99,9% случаев. Вот промпт, который я использовал для AlignEval.

Evaluate the output based on the provided criteria. First, in the <sketchpad> provided, think through your evaluation step by step. Then, provide a binary prediction (0 or 1) within <prediction>.

Evaluate the output based on the provided criteria. First, in the provided, think through your evaluation step by step. Then, provide a binary prediction (0 or 1) within .

To decide on hosting, I conducted a Twitter poll and consulted documentation for options like Dokku, Coolify, Vercel, etc. Hamel’s write-up on Dokku was particularly helpful. While I initially considered hosting the app on Hetzner with Dokku (another opportunity to learn something new), I ultimately decided to take the lazy path (read: prioritize ruthlessly) and start with hosting on Railway. It was a good decision.

Чтобы определиться с хостингом, я провёл опрос в Twitter и изучил документацию по таким вариантам, как Dokku, Coolify, Vercel и т. д. Особенно помог разбор Dokku от Hamel. Хотя поначалу я подумывал хостить приложение на Hetzner с Dokku (ещё одна возможность научиться чему-то новому), в итоге я выбрал ленивый путь (читай: безжалостно расставлять приоритеты) и начал с хостинга на Railway. Это было хорошее решение.

Hosting on Railway has been a breeze. After setting up the project via their web UI and linking it via the CLI (railway link), pushing new updates is as simple as railway up. Each update takes one to two minutes. Railway also comes with several database options, including Postgres and Redis. While a VPS might be cheaper in the long run, at this stage, YAGNI. Fiddling with a VPS would have been a distraction from improving the UX, implementing features, and figuring out optimization mode.

Хостинг на Railway оказался проще простого. После настройки проекта через их веб-интерфейс и привязки его через CLI (railway link) выкатка новых обновлений сводится к простому railway up. Каждое обновление занимает одну-две минуты. Railway также идёт с несколькими вариантами баз данных, включая Postgres и Redis. Хотя VPS в долгой перспективе может быть дешевле, на этом этапе действует YAGNI. Возня с VPS отвлекла бы от улучшения UX, реализации фич и проработки режима оптимизации.

My simple Railway setup

Моя простая настройка на Railway

If you’d like to get started with Railway, please use my affiliate code—it’ll help with hosting costs and keep AlignEval running!

Если вы хотите начать с Railway, пожалуйста, используйте мой партнёрский код — это поможет с расходами на хостинг и поддержит работу AlignEval!

Going from a laptop prototype to a public beta took some effort. The work included:

Путь от прототипа на ноутбуке до публичной беты потребовал некоторых усилий. Работа включала:

Разделение на фронтенд Next.js и бэкенд FastAPI, миграцию с SQLite на Postgres Реализацию обратной связи в реальном времени для разметки, оценки и оптимизации Добавление функций для упрощения разметки (кнопки pass/fail), кастомизации моделей и полей (выпадающие списки, интеграция с провайдерами моделей) и не только Улучшение UI (как бы грубо он ни выглядел сейчас, раньше было намного хуже, лол) Истребление множества багов (и, вероятно, упущение многих других)

Here’s the to-do list I had; there were many more tasks and bugs that I neglected to track. Because I timeboxed the effort to October, a few items were not completed. But if AlignEval gains traction and proves useful, I might revisit the list.

Вот список задач, который у меня был; было ещё много задач и багов, которые я не удосужился отслеживать. Поскольку я ограничил усилия временем до октября, несколько пунктов не были завершены. Но если AlignEval наберёт обороты и окажется полезным, я, возможно, вернусь к списку.

## Todos - [x] Split deployment into frontend and backend - https://help.railway.app/questions/how-to-expose-a-fast-api-backend-service-a1712631 - https://help.railway.app/questions/econnrefused-when-calling-another-servic-5662d969#p-1 - ~~[ ] Or consider something like this: https://vercel.com/templates/next.js/nextjs-fastapi-starter~~ (only works with Vercel) - [x] Add external database (Railway Postgres) - [x] Write interface to ensure compatibility between SQLite and Postgres - [x] Connect label-app to Railway Postgres - [x] Connect label-hpo to Railway Postgres - [x] Show feedback to users while optimization is running - [x] Update table names to use CSV file name - [x] Add support for multiple tables - [x] Replace tablename parameter with filename parameter - [x] Uploading a CSV file with an existing name should return the existing table - [x] Add llm-evaluator optimization to label-hpo - [x] Add dropdown to select evaluation fields - [x] Add ability to delete optimization table, with password - [x] Add progress bar to gamify labeling, evaluation and optimization - [x] Add buttons to click pass and fail - [x] Add usage count (upload (files, rows), evaluate (files, rows), optimize (files, trials)) - [x] Add info button intro next to header to explain the site - [x] Update favicon - [x] Add support for OpenAI models - [x] Add balanced val-test split for optimization - [x] Add columns to optimization metrics: split (dev, test), model, evaluation_fields - [x] Set max upload rows to env variable - [ ] Fix bug where alert pops up: "Failed to handle optimization: Unexpected token '<', "<!DOCTYPE "... is not valid JSON" - Still pops up every now and then - [x] Fix bug where evaluation alert pops up even when optimization is unlocked - [x] Add popup to see full prompt - [x] Add button to copy prompt - [x] Add completion bar to optimization sticky - [x] Make site look retro and like a game - [x] Prompt users to rename sample data before downloading - [x] Update delete optimization to reset optimization, and set password to Twitter handle - [x] Add "don't show me this again" checkbox - [ ] Improve how we poll for data - [ ] Add button to donate with Stripe payment - [ ] Add button to optimize more with Stripe payment ## Todos (OE) - [x] Separate data definitions to definitions.ts - [x] Separate fetch data queries to data.ts - [x] Separate data mutations to actions.ts - [x] Separate components into component.tsx under ui which are imported in page.tsx

## Todos - [x] Split deployment into frontend and backend - https://help.railway.app/questions/how-to-expose-a-fast-api-backend-service-a1712631 - https://help.railway.app/questions/econnrefused-when-calling-another-servic-5662d969#p-1 - ~~[ ] Or consider something like this: https://vercel.com/templates/next.js/nextjs-fastapi-starter~~ (only works with Vercel) - [x] Add external database (Railway Postgres) - [x] Write interface to ensure compatibility between SQLite and Postgres - [x] Connect label-app to Railway Postgres - [x] Connect label-hpo to Railway Postgres - [x] Show feedback to users while optimization is running - [x] Update table names to use CSV file name - [x] Add support for multiple tables - [x] Replace tablename parameter with filename parameter - [x] Uploading a CSV file with an existing name should return the existing table - [x] Add llm-evaluator optimization to label-hpo - [x] Add dropdown to select evaluation fields - [x] Add ability to delete optimization table, with password - [x] Add progress bar to gamify labeling, evaluation and optimization - [x] Add buttons to click pass and fail - [x] Add usage count (upload (files, rows), evaluate (files, rows), optimize (files, trials)) - [x] Add info button intro next to header to explain the site - [x] Update favicon - [x] Add support for OpenAI models - [x] Add balanced val-test split for optimization - [x] Add columns to optimization metrics: split (dev, test), model, evaluation_fields - [x] Set max upload rows to env variable - [ ] Fix bug where alert pops up: "Failed to handle optimization: Unexpected token '<', "