Ні, скоріше про те, що ми не можемо покращити кращу модель.

Наприклад, одна модель натренована на собаках, але нічого не знає про котів. Друга модель, натренована на котах, але нічого не знає про собак.
Обидві моделі окремо дають 0.9 ймовірність. Але якщо будуть задачі і по котам і собакам, в результаті дві моделі можуть давати кращі результати ніж окремо. По питанням про собак буде обиратися відповідь із першої моделі, а по котам із другої. в результаті всі відповіді можуть бути вірними. А окремо — ймовірно результат був би гірший.

Коли людина розмірковує, то робить певні припущення. Тобто це вже інші дані будуть. Звісно можна їх відразу запхнути у модель. Припускаю, що теорема

про відсутність безкоштовних обідів

буде працювати, якщо одні і ті ж дані(промпти) і одна й та ж модель.

Я розумію, що чим більше невірних даних, тим достовірнішими вони виглядають. Невірні дані підтверджують інші невірні дані.
Але модель все рівно повинна вміти сама фільтрувати дані. При цьому опираючись на якісь 100% достовірні джерела даних. Аналогічно до «побачив на власні очі».
Тобто, модель майже все повинна піддавати сумніву.

Ой, якби це було так, то всі давно би так робили. З точки зору теорії надійності це не покращує ситуацію, бо це послідовний зв’язок — надійності перемножуються. Якщо перша має 0.9, друга 0.9, то разом буде 0.81, а не 0.99.

Трохи не так. Тому що:
Перший агент вивів — 0.9
Другий агент перевіряє за певними критеріями(перевіряє на адекватність) — приймати цю відповідь чи ні.
І якщо не адекватно. То просить перегенерувати і звернути увагу на певно моменти.
Перегенерований варіант буде мати теж около 0.9 ймовірність але будуть враховані якісь нюанси.
Наприклад, перша модель може умову «ніч» прийняти, як не суттєву для генерації електрики, а друга модель при перевірці визначить, що яка ж генерація електрики сонячною електростанцією вночі. І попросить першу модель звернути увагу, що там же «ніч». Перш модель перегенерує відповідь. Знову отримає около 0.9(згідно показників моделі), але ця відповідь вже ймовірно буде більш вірною.

В мене на складних задачах теж не працює. Тому стараюсь не давати моделям такі, бо розбиратися в згенерованому довше ніж самому написати. (Але прогрес ШІ для кодингу за попередній рік-два все-рівно вражає)

І тут питання, а чи це можливо взагалі?

Я думаю, що ідеального розбиття не існує, бо завжди можна додати залежності між окремими модулями. І чим більше залежностей ми додаємо між модулями, тим більша ймовірність, що архітектуру потрібно переробляти. Бо основа розбиття на модулі — мінімальна залежність між модулями і максимальна всередині модулів. (До речі на задачу кластеризації схоже)

Тут треба зібрати навчальні дані, то обʼємна задача, і то не факт, що запрацює. Є варіанти reinforecement learning, але тут як раз невідомо як вийде.

По ідеї модель сама під час навчання повинна перевіряти які дані 99.(9)% вірні, а які ні. Тобто годуємо всі дані моделі при навчанні, а вона сама обирає вірні. (або ж починати вчити на аксіомах(на 99.9% вірних даних), а вже потім давати все підряд(щоб модель сама фільтрувала) — так вийде значно швидше навчити)

Абстракції запросто, проблема якраз у конкретиці. Припустимо, що ШІ виконує елементарний крок з надійністю 99%. Тоді 10 кроків поспіль це 90%, 50 кроків це 60%, 1000 кроків це 0.005%.

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

Тому LLM бачить тільки фінальний результат і намагається вгадати відповідь одразу, замість того щоб йти покроково:

Для цього треба вчити модель оцінювати саму задачу. Щоб зрозуміти робити її покроково чи відразу. По дефолту задача, напевно, спочатку повинна розглядатися, як багатокрокова. А, якщо задовольняють певні умови, то тоді можна робити за один крок.
Тобто треба змушувати модель робити покроково, а не вгадувати.

Для LLM фактично простіше написати скрипт та виконати його, ніж виконувати «в умі». tool use працює набагато краще за pure reasoning.

Логічно. Конкретні інструкції простіше виконати ніж все прораховувати. Особливо, коли якихось критично важливих даних може не бути.

В ШІ така кількість грошей заливається, що складно уявити, що вони не знайдуть за кілька років, потрібні рішення.

Або напишите, або не напишете. Я теж можу сказати, дайте мені 10 років на підготовку і я стану гросмейстером. Або стану, або не стану.

Не треба бути «гросмейстером», щоб успішно писати 95% програм до рівня, щоб їх можна було нормально використовувати. (В цьому суть)
В результаті, якщо один програміст не захоче писати код, то можна знайти іншого чи інших. (Так, можливо з більшими в рази затратами)

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

Невже ШІ не можна навчити абстракції? Або ж ділити проект на менші частини(як ви і написали). Для перебору, потрібно, щоб модель не лізла у певні сценарії, які вже раніше продивилась. Теоретично, у нейромережу можна додати можливість зменшувати ваги у певної групи вузлів. (щоб нейромережа знову туди не полізла). З цим може бути складність. Але це теж можна вирішити.

Ну... скільки я не бачив складних багатоагентних моделів, всі вони згодом програвали одній моделі: накопичення помилок між етапами, втрачається контекст, прогалини в комунікації.

В будь-якому випадку моделі потрібно протестувати на девайсі і отримати фідбек. Тому, як мінімум два агенти потрібно.
Я під час кодингу генерую кілька варіантів і обираю найкращий. Це дозволяє уникнути випадків, коли модель залізла в якесь тупе рішення. (аналог локального максимуму(мінімуму) у математичної функції на графіку). В цьому і ідея моделі для перевірки.

Що таке типовий прогріміст?

Дайте мені рік на підготовку і я напишу будь-який функціонал програми, яку ви можете написати. І ви аналогічно відносно мене. Тобто різниця тільки у витратах часу. Ми не вирішуємо такі задачі, що «тільки ми можемо їх вирішити і ніхто інший».

Як трохи інженер і трохи науковець я бачу ситуацію з ШІ з різних боків.

Я теж знаю як працюють моделі ШІ. І розумію, що ШІ потрібно пояснити всі фічі у програмі, які повинні бути. Але це(теоретично) може зробити і той, хто не вміє програмувати.
Далі. Беремо кілька агентів. Один пише код. Другий перевіряє код по архітектурі. Третій по рефакторингу. Четвертий запускає і тестує. І всі вони дають фідбек першому. Навіть при нинішньому рівні моделей ШІ типу ChatGPT підозрюю що вже можуть писати зовсім прості програми досить адекватно.
А ШІ ще тільки на початковому етапі свого розвитку.

ШІ не замінить програмістів, не зможе писати все, із багатьох причин цього не станеться, на наш вік ще вистачить роботи.

Якби ж воно так було.

Я не питав порад, як мені розглядать.

Та в Зе — там комплекс неповноцінності)))

В результаті програмісти просто отримають меншу плату, бо фінансовий об’єм ринку зростає значно повільніше ніж економія часу розробки.

Плюсую. У мене теж було саме 3 описані стадії.)

З однієї сторони — добре. А з іншої — в результаті програміст отримає приблизно таку ж оплату за тиждень, яку за тиждень отримав би і раніше. А потім — просто іншу роботу буде виконувати. Тобто реальна вигода під питанням для програмістів.
А далі — ШІ буде писати все і програмісти в принципі будуть не потрібні.)
[А зараз же ті 3 програмісти кілька місяців будуть сидіти без роботи, або ж працювати за копійки і створять вам же конкуренцію. Типового програміста зараз досить просто замінити на іншого.]

Дуже плюсую!

Крім того, якби не ШІ у програмістів було б значно більше вакансій і вища оплата. Тому для звичайного програміста розвиток ШІ це швидше мінус ніж плюс.

Типу вайб-інженер краще? Типу вайб-інженер ніколи «не плюється», що воно не працює, чи що ШІ не те написав?...) Тепер «вайб-інженеру» треба значно більше написати функціоналу, щоб відпрацювати оплату. Краще ніж без ШІ, але...

Тобто люди не можуть якусь чепуху написати?

Як я впала зі стільця і потрапила в IT

Як же бісять подібні назви статей...

«Як я пострибав на одній нозі» — читайте.)