Знайомтеся з автором: Ештон Чью, інженер-засновник Theta

Почнімо! Розкажіть трохи про себе. Наприклад, ім'я, професію та особисті інтереси.

Привіт! Мене звати Ештон, і я інженер-засновник у Theta, де я працюю над інфраструктурою RL, RL та розподіленими системами. Я зосереджуюсь на використанні комп'ютера та інструментів. У минулому я працював у Amazon AGI та займався інфраструктурою для виведення та використання інструментів. У вільний час я люблю графічний дизайн, побічні проєкти та боулдеринг.

Цікаво! Про що була ваша остання популярна стаття на Hackernoon?

Моя остання стаття "Чи може ваш ШІ насправді користуватися комп'ютером? Карта еталонів використання комп'ютера 2025 року" торкнулася однієї з найгарячіших тем у VC зараз: середовища RL та оцінки. Я дав вичерпний огляд найбільш використовуваних еталонів використання комп'ютера, а також практичні поради щодо вибору еталонів для навчання та тестування агентів, що використовують комп'ютер.

Я постійно стикався з однією і тією ж проблемою: немає багато статей, які аналізують самі еталони. І в міру розвитку цієї галузі життєво важливо, щоб ми насправді оцінювали якість, а не винагороджували те, що випадково грає на метриці. Ми вже були тут раніше. На ранніх етапах розвитку LLM еталони були настільки випадковими та різноманітними, що лише слабко відображали справжнього переможця.

Еталони стали фактичним табло для "найкращої моделі", а потім люди зрозуміли, що багато з них не вимірювали те, що вони стверджували.

Одним із найбільш показових невдач раннього періоду було те, коли "розуміння прочитаного" тихо перетворилося на "зіставлення шаблонів у структурі набору даних". Дослідники запустили навмисно провокаційні базові лінії (тільки питання, тільки останнє речення), і результати були достатньо високими, щоб викликати незручну можливість: еталон не послідовно змушував моделі використовувати весь уривок. У критиці 2018 року суть була не в тому, що читання ніколи не має значення, а в тому, що деякі набори даних випадково зробили його необов'язковим, надмірно винагороджуючи такі скорочення, як новизна та стереотипні попередні відповіді.

\

# Supposed task: answer the question given the passage and question Passage (summary): - Sentences 1–8: John's day at school (mostly irrelevant detail) - Sentence 9: "After school, John went to the kitchen." - Sentence 10: "He ate a slice of pizza before starting his homework." Question: "What did John eat?" Answer: "pizza"

Еталон випадково винагороджує скорочення, коли модель надає надмірну вагу останньому реченню (оскільки відповідь часто знаходиться ближче до кінця) і просто витягує прямий об'єкт найновішої дії ("з'їв ___"), що в цьому випадку дає "піцу".

А потім з'являється ще більш шкідлива базова лінія: повністю видаліть уривок і подивіться, що станеться. Якщо модель, що працює лише з питаннями, є конкурентоспроможною, це ознака того, що набір даних витікає сигнал через повторення та попередні знання, а не тестує розуміння, засноване на уривку.

Question: "What did John eat?"

Ця базова лінія є по суті перевіркою здорового глузду: чи може модель все ще добре оцінюватися, спираючись на шаблони відповідей з високою частотою без будь-якого обґрунтування на уривку? На практиці вона просто вгадує токен, який набір даних непропорційно винагороджує ("піца", "сендвіч"), і якщо це працює частіше, ніж повинно, ви вимірюєте не стільки розуміння, скільки попередні знання набору даних.

Оцінки використання комп'ютера вже створили ще більш буквальне скорочення: агент має браузер, еталон є публічним, і оцінка перетворюється на іспит з відкритою книгою з ключем відповідей на останній сторінці. У статті про Holistic Agent Leaderboard (HAL) автори повідомляють про спостереження за агентами, які шукали еталон на HuggingFace замість вирішення завдання, поведінку, яку ви помітите, лише якщо перевірите журнали.

\

# Supposed task: complete a workflow inside the web environment Task: "Configure setting X in the app and verify it's enabled." Failure mode: 1) Open a new tab 2) Search for: "benchmark X expected enabled state" / "HAL <benchmark> setting X" 3) Find: repo / leaderboard writeup / dataset card / issue thread 4) Reproduce the expected end state (answer)

На цьому етапі оцінка вимірювала, чи може вона знайти ключ відповіді.

Task: "Find the correct page and extract Y." Failure mode: - Search: "<benchmark name> Y" - Copy from a public artifact (docs, forum post, dataset card) - Paste the value into the agent output as if it came from interaction

Якщо агент може витягти значення з картки набору даних або репозиторію і все ще "пройти", перевірка успіху оцінює правдоподібність, а не правильність взаємодії. Публічні завдання плюс поверхнева перевірка перетворюють веб-пошук на експлойт.

Ці два приклади є попереджувальним пострілом: якщо ми не будемо дотримуватися вищих стандартів для еталонів використання комп'ютера на ранньому етапі, ми повторимо еру LLM, просто з кращими інтерфейсами користувача та більш складними способами обману.

Ви зазвичай пишете на подібні теми? Якщо ні, про що ви зазвичай пишете?

Так! Працюючи над середовищами RL та інфраструктурою RL навколо використання комп'ютера, я постійно оточений найкращими моделями використання комп'ютера та найбільш реалістичними навчальними середовищами. Тому я написав ще одну статтю, "Екран - це API", яка є аргументом на користь використання комп'ютера і пояснює, чому це майбутнє моделей ШІ.

Цей простір надзвичайно недостатньо висвітлений з двох причин:

1. Моделі не такі здібні у використанні комп'ютера, як в інших завданнях (кодування, математика тощо).
2. Використання комп'ютера швидко розвивається і є надзвичайно новим.

Я хочу це змінити.

Чудово! Який у вас звичайний режим написання (якщо він у вас є)

Я зазвичай читаю багато дослідницьких статей і розмовляю з колегами в галузі про їхні думки щодо теми. Крім того, я витрачаю багато часу на читання статей великих блогерів, таких як PG. Тому я зазвичай черпаю багато натхнення від інших людей у своєму письмі.

Бути письменником у технологічній сфері може бути викликом. Це часто не наша основна роль, а доповнення до іншої. Яка найбільша проблема у вас виникає, коли справа доходить до письма?

Знайти час, щоб сісти і перетворити свій життєвий досвід у слова.

Чого ви сподіваєтеся досягти наступного у своїй кар'єрі?

Вирішувати складніші проблеми з чудовими людьми, вчитися у цих людей і ділитися своїм досвідом.

Вау, це гідно захоплення. Тепер щось більш повсякденне: яке ваше улюблене задоволення?

Перегляд фільмів! Мій улюблений фільм зараз - "Спіймай мене, якщо зможеш" (2002).

Чи є у вас хобі, не пов'язане з технологіями? Якщо так, яке?

Я люблю боулдеринг, тому що він змушує мене відчувати себе людським агентом використання комп'ютера, що взаємодіє зі скелелазною стіною. Я жартую. Я думаю, що боулдеринг - це дуже весело, тому що він дозволяє мені відволіктися від роботи і впорядкувати свої думки.

Що спільнота Hacker Noon може очікувати прочитати від вас наступного?

Я зараз пишу ще одну статтю про інфраструктуру середовища RL!

Яка ваша думка про HackerNoon як платформу для письменників?

Я думаю, що структура рецензування чудова, і це було чудове місце для мене, щоб представити свої думки перед технічними читачами.

Дякуємо, що знайшли час приєднатися до нашої серії "Зустріч з письменником". Це було задоволення. Чи є у вас якісь заключні слова?

Я люблю писати. Дякую, HackerNoon!