Актуальні теми
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
Хороший пост від @balajis на "верифікаційну прогалину".
Ви могли бачити, що у творінні є два режими. Запозичення термінології GAN:
1) генерація та
2) дискримінація.
Наприклад, малювання - ви робите мазок пензлем (1), а потім деякий час дивитесь, щоб побачити, чи покращили ви живопис (2). Ці два етапи перемежовуються практично у всій творчій роботі.
Другий момент. Дискримінація може бути обчислювально дуже складною.
- Зображення на сьогоднішній день найпростіші. Наприклад, команди генераторів зображень можуть створювати гігантські сітки результатів, щоб вирішити, чи є одне зображення кращим за інше. дякую гігантському графічному процесору у вашому мозку, створеному для дуже швидкої обробки зображень.
- З текстом все набагато складніше. Він доступний для перегляду, але вам потрібно читати, він семантичний, дискретний і точний, тому вам також потрібно міркувати (особливо в коді).
- Звук, можливо, ще складніший IMO, тому що він змушує вісь часу, тому його навіть не можна проскочити. Ви змушені витрачати послідовні обчислення і зовсім не можете їх розпаралелити.
Можна сказати, що в кодуванні LLM згорнулися (1) до ~instant, але зробили дуже мало для вирішення (2). Людині все одно доводиться дивитися на результати і розрізняти, чи хороші вони. Це моя основна критика кодування LLM у тому, що вони недбало випльовують *дуже* занадто багато коду на запит із довільною складністю, вдаючи, що етапу 2 немає. Отримати стільки коду – це погано і страшно. Замість цього LLM повинен активно співпрацювати з вами, щоб розбити проблеми на маленькі поступові кроки, кожен з яких легше перевірити. Він повинен передбачити обчислювальну роботу (2) і скоротити її настільки, наскільки це можливо. Він повинен дійсно піклуватися.
Це підводить мене до, мабуть, найбільшого непорозуміння щодо кодування, яке не є програмістами. Вони думають, що кодування – це написання коду (1). Це не так. Йдеться про те, щоб дивитися на код (2). Завантаження всього цього в робочу пам'ять. Ходьба туди-сюди. Продумування всіх крайніх випадків. Якщо ви застанете мене у випадковій точці, коли я «програмую», я, ймовірно, просто дивлюся на екран і, якщо мене перебивають, дуже злий, тому що це дуже важко з обчислювальної точки зору. Якщо ми отримаємо набагато швидше лише 1, але не зменшимо також 2 (що в більшості випадків!), то очевидно, що загальна швидкість кодування не покращиться (див. закон Амдала).

4 черв. 2025 р.
ПІДКАЗКА ШТУЧНОГО ІНТЕЛЕКТУ → ПЕРЕВІРКА ШІ
Підказка ШІ масштабується, тому що підказка – це просто набір тексту.
Але верифікація ШІ не масштабується, тому що перевірка результатів ШІ включає набагато більше, ніж просто набір тексту.
Іноді це можна перевірити на око, тому ШІ чудово підходить для фронтенду, зображень та відео. Але для будь-чого тонкого вам потрібно глибоко прочитати код або текст — а це означає знати тему досить добре, щоб виправити штучний інтелект.
Дослідники чудово знають про це, тому так багато роботи над евалами та галюцинаціями.
Однак концепція верифікації як вузького місця для користувачів ШІ недостатньо обговорюється. Так, ви можете спробувати формальну верифікацію, або критикувати моделі, коли один ШІ перевіряє інший, або інші методи. Але навіть усвідомлювати це питання як першокласну проблему – це половина успіху.
Для користувачів: перевірка ШІ так само важлива, як і підказка ШІ.
449,31K
Найкращі
Рейтинг
Вибране