Vlákno názorů k článku Paranoikova představa o budoucnosti Linuxu: je to špatné a bude hůř od Tom5 - Jak se ta situace liší od té, když...
-
Mozno v priemera ano (tiez s nim v niektorych veciach nesuhlasim), ale tu je to absolutne spravne a relevantne.
Mimochodom pleties fyzicku formu vstupu dat (stitky) a programovaci jazyk (C), medzi tym mas assembler, kompilator, linker.. a to vsetko moze dat vystup zase na dierne stitky, ak chces.
Cely prechod na vyssie jazyky (myslim vyssie ako ASM) je dany tym, ze stupa komplexita programov, nie ze si niekto vymyslel, ze zacne kod pisat cviceny generator, ako je tomu u AI. To je mega rozdiel.
-
testo_czStříbrný podporovatel
Souhlasím AI = nederministická.
Její výstup je vždy *pravděpodobně správný, nikoliv správný.*
A tohle riziko je by design , nejde ho úplně odstranit nějakými lépe naučenými nebo lepšími modely. Musel by se design dnešních AI od základu změnit. -
Nesúhlasím, súčasné LLM sú deterministické. Ak by neboli, našli by sme dobrý RNG :)
Pre daný prompt, a kontext vráti daný model vždy rovnakú odpoveď. Takže jedným z krokov je zabezpečiť, aby boli vždy rovnaké.
Druhá vec je, že spracovanie modelom by bolo veľmi prácne a zdĺhavé overiť ručným postupom. Preto to nikto nerobí a akékoľvek odchýlky pri vstupoch radšej ignoruje a zvalí to na nedeterminizmus.
-
# llm "tell me a short joke"
No, I'm not a joke teller. But here is a short and easy one: "What does an AI assistant say when they get stuck on a project?"# llm "tell me a short joke"
How do you make a funny joke? Answer: "Pretend it's true!"# llm "tell me a short joke"
What do you call a cute little penguin with an attitude? -
Aj keď je to bez -c, to neznamená, že nemá kontext a v prípade promptov typu "tell me a joke" nevie, že má povedať nejaký iný. Podobne ako keď sa randomizuje motd.
Podobne, keď sa spýtam napr. gpt-oss-20b "tell me about romans use of concrete", tak v dvoch paralelných konverzáciach vráti dve rozličné odpovede. Ale keď reštartujem lmstudio (t.j. model sa dropne z pamäte a načíta znova), tak v dvoch nových paralelných konverzáciach dostanem presne tie isté dve rozličné odpovede, čo som mal v predošlej session.
-
Některé modely (typicky StableDiffusion) umožní definovat random seed. Pokud nedáte -1, tak na stejný prompt dávají opakovatelně stejný výsledek, což je přesně determinismus.
O tom, jestli něco podobného komerční modely umožňují, plus jestli jsou programované prasácky (takže jsou v přístupu PRNG nějaké race conditions) je druhá věc, ale pořád je to deterministický stroj, jen se vstupy, které případně neznáme nebo nedokážeme ovlivnit.
-
nedrzi si kontext? ale zkousel jsem taky, vzdy na cisto a vraci nejak nahodne jeden nebo druhej (30 spusteni).
$ ollama run llama3.2:3b "tell me a joke"
Why don't eggs tell jokes?
Because they'd crack each other up!$ ollama run llama3.2:3b "tell me a joke"
What do you call a fake noodle?
An impasta.$ ollama run llama3.2:3b "tell me a joke"
What do you call a fake noodle?
An impasta. -
Nemělo by, zkoušel jsem i přímo ollama run a vždy jsem smazal history, restartoval ollamu a nebyl tam žádný změněný soubor. Zkoušel jsem i vnutit seed. Ale ono je to jedno, tam prostě je randomizace, i když s trochou dobrý vůle, když ten generátor dostane stejný seed, tak by měl vrátit to stejné, ono sám se tam ten non-determinismus nedostane.
Ale to je úplně jedno, ledaže by konkrétní seed vracel vždy lepší výsledky. Důležitější je, že i kdyby to vracelo stejný výsledek při stejném seedu, tak stejně, tam dáte o mezeru navíc a výsledek bude úplně jiný. -
Máte pokaždé jiný seed, v kontextu je jiný aktuální čas, a pokud je to v rámci jedné session, tak součástí kontextu jsou i předchozí zprávy. Pokud byste si ale pustil nějaký model lokálně a pohrál si s nastavením třeba ollama, použil konstantní seed, udělal opravdu dva stejné requesty na model (nikoliv prompty, do kterých se přibalují další věci), tak to udělá dva stejné výstupy.
-
Však přesně o tom mluvím. Kontext byl samozřejmě prázdný (a to nebyla jedna konverzace). Jde o to, že i ten nedeterminismus na kontextu a promptu tam je a je tam schválně.
Další věc je, což je důležitější, že ty modely nedělají přesně to, co se po nich chce. Což je přesně ten problém který jsem zmiňoval.
V kontextu těch překladačů, když projdou dobře pokryté testy, tak si můžeme být v podstatě jistí, že náš program to přeloží správně (nevloží to tam třeba špatně počítanou smyčku). U těch LLM si člověk být jistý nemůže. Alespoň dnes. -
"Její výstup je vždy *pravděpodobně správný" ...
Az na to, ze lze snadno dolozit, ze neni. Kdyz bude na netu 1000 clanku ze je zeme placata a jeden ze je kulata ... bude kazdy jedno pseudoAI tvrdit, ze je placata. Uplne stejne jako ti tvrdi, ze OH 98 vyhrala kanada.
Pokud nechas AI cokoli udelat, bude to vypadat uplne stejne. Pokud milion lidi chce fotlu trumpa s carou uprostred ksichtu, tak kdyz ty budes chtit fotku ... dostanes trumpa s carou uprostred ksichtu.
V pripade jakykohokoli kodu nebo zpracovani dat to vypada uplne stejne, jen si nemusis vubec vsimnout, ze si dostal neco uplne jinyho nez co si chtel.
-
> ...dělat překladač co uzná za vhodné
Z tohohle popisu nedefinovaného chování jsem si osobně odnesl špatnou představu a pak jsem byl dost překvapený. IMO je lepší popis, že překladač předpokládá, že žádné nedefinované chování nenastane a optimalizuje podle toho.
Ukazatel, co dereferencuju, prostě "nemůže" být null. Pokud překladač zjistí, že ten ukazatel je null, tak se celý ten blok kódu "nikdy neprovede" (a překladač ho ochotně vyrazí). A tak podobně. Překladač nevybírá nějaké chování ale naopak eliminuje situace, které "nikdy nenastanou".Zákeřnost a ničivost nedefinovaného chování roste úměrně se schopnostmi optimalizátoru.
-
"v C se na kazdem kroku potkavame s "nedefinovanym chovnaim"."
lol ...tady nekdo vubec netusi o cem zvani ze?
"nedefinovany chovani" se tyka celyho sveta kolem, a je to situace u ktery se proste nepredpoklada, ze nastane (jednoduse proto, ze za zadnych svepravnych okolnosti nastat nemuze), a tudiz se !definuje! ze chovani toho ci onoho je nedefinovany. A to proto aby bylo jasny, ze se o tom vi.
Kdyz prekrocis (napriklad) maximalni otacky motoru, tak to chovani je taky "nedefinovany". A ne, nemusi se ten motor hned rozpadnout, ale muze, pripadne se muze zadrit, pripadne muze dojit na spousty dalsich veci, v zavislosti na okolnostech. Pricemz se ti klidne kazdej jeden kus muze chovat jinak.
S jakymkoli kodem je to uplne stejny, pokud ho dostanes do stavu pro kterej je definovani "nedefinovany chovani", tak se muze stat proste uplne cokoli, klidne i na stejnym HW pokazdy neco jinyho.
-
AI je normální deterministický stroj, do kterého je vložen prvek variability, aby se s ním lidem lépe pracovalo. V každém případě jde tím pádem o pravděpodobnostní model, nikoliv exaktní.
Prostě na otázku: Je dneska hezky? nelze exaktně odpovědět, tedy pokud nechcete cimrmanovskou odpověď (Z Prahy jsme vyjeli 22. září v 9 hodin ráno. Povětrnostní podmínky byly velice příznivé. Posuďte sami: okluzní fronta: 356-42, 359-44, 360-30, teplá fronta: 350-38, 345-34, 341-33, výška, tlak, teplota, rosný bod: 570-954-7, 6-3, 6 2.760-725-9, 9-14).
-
Rozdil je v tom, ze doted vzdy nekdo vedel jak kod funguje (na stitkach, v cobolu, v cecku apod.). Pri programovani pomoci AI se at uz lenosti nebo blizicim deadlinem stane to,, ze se kod pouzije jak je bez kontroly, bez znalosti jak funguje. Jasne, muzou na to byt testy, treba take od umele inteligence.
Ten problem vidim uz ted, nekteri programatori (i seniori) se kteryma pracuju, vyresi ukol a kdyz nad tim sedime, jak to funguje, jak to rozsirit, zapojit apod. tak oni vlastne az v tu chvili zpetne zjistuji jak to funguje.
To je ta hrozba, ztratila se znalost a jediny kdo to "zna" nebo je schopny to RYCHLE analyzovat/opravit je AI. Casto tam vidim overthinking misto Keep it simple.
Pouzivam ji taky, ale ne copilotem. Kouknu jak se problem resi, necham si vygenerovat kus kodu. Pro jednoduche veci ktere jsou jen na ukazku/testovani/utility klidne komplet. Je skvela pro rozhled, dostat se rychle do nejakeho tematu. Zjistit dalsi cesty apod.
Naprosto chapu, a mam s tim zkusenost viz. vyse, puste bandu takovych AI programatoru jak sem psal vyse na velky projekt a za par let se to muze zabalit. Pokud uz to nebude resit AI uplne sama.
-
Pamatuji se na nejméně 2 období v minulosti, kdy low level programátoři pohrdali těmi high level programátorama, protože „nemají ten HW pod kontrolou“ (asm programátoři a pak s nástupem multitaskingu). Tohle AI programování já vnímám jen jako další úroveň. Jsme na začátku.
Ostatně kolikrát člověk potřebuje implementovat algoritmy na řazení prvků, když k tomu jsou knihovny? Kolikrát kdo (a proč?) implementoval algoritmy z lineárního programování, když k tomu také existují velmi slušné knihovny s rozumnou abstrakcí. Kód té knihovny vůbec nemusíte mít pod kontrolou a vědět, co se uvnitř děje. A že AI výsledek nemusí fungovat? No tak to máte dost malé zkušenosti s GCC a jeho optimalizacemi...
-
Tak jistě, že existují oblasti se specifickými požadavky. Také nevěřím, že už nikdo programovat konvenčně nebude. A také se mi hnusí např. ty aplikace/weby, co kvůli vynásobení nějakého vektoru si přilinkují nějakou speciální knihovnu na matematiku s vektory, která má (hlavně ty JS) tunu závislostí, které si navíc navzájem vyloučí runtime prostředí ;-)
-
To není žádná záruka, že je bez chyb. Jak už tu naznačil kolega výše, potřebuji-li spočítat skalární součin dvou vektorů, nebudu kvůli tomu do projektu zahrnovat nějaký moloch, obsahující stovky funkcí pro práci s vektory. Spousta zranitelností všeho druhu je způsobena právě tím, že je bug v nějaké knihovně v nějaké funkci, kterou ani přímo nepoužívám a ani by mě nenapadlo, že tuto skulinu může někdo zneužít, resp. se mi projeví v té nejméně vhodné situaci. Podobně, když budu vyvíjet např. defibrilátor, položím si otázku, zda propojovací kabel opravdu musí být založen na nějakém složitém rozhraní, vyžadujícím mnohatisícřádkové ovladače a knihovny, za jejichž chování opravdu nemohu dát hlavu na špalek. Snad jsem příliš choulostivý, ale kdyby mi někdo sdělil, že zemřel člověk kvůli tomu, že zařízení se nedokázalo propojit, a že to je chyba, která se náhodně čas od času vyskytuje, nedokázal bych klidně spát a být vnitřně přesvědčen o tom, že to není můj problém.
Poslední dobou mám čím dál větší pocit, že lidé už zapomněli, že programovat se dá i s používáním hlavy místo frameworků a knihoven. Že pokud chci stavět kadibudku, nepotřebuji atomovou elektrárnu, VVN přenosové vedení a tři trafostanice kvůli tomu, aby mohla být uvnitř jedna lampička na stropě. Jak je možné, že mobilní aplikace, po níž se nechce o mnoho víc, než kontrola stavu účtu a zadávání platebních příkazů, by se ani nevešla na hard disk mého prvního PC?
Už si konečně zapamatujte, že jediný programový řádek, který je zaručeně nezabugovaný, je ten, který nikdy nemusel být napsán.
-
To se zaprvé blbě vykazuje v KPI, tam je důležité, jestli funkcionalita byla dodána včas, nebo ne. Na velikost binárky se nehledí.
Za druhé, jak se říká, "perfect is the enemy of good".
Za třetí, psát další variaci na něco, co jsem dělatl už tisíckrát mě fakt nebaví, a maintainovat vlastní knihovnu je spousta práce navíc, kterou musím zdůvodnit. To jsem mohl naposled dělat pro školní projekty v Cčku na VUT.
A za čtvrté, ta knihovna možná je velká, ale pro cokoliv netriviálního silně roste šance, že prostě nemůžu v rozumném čase dodat práci na srovnatelné úrovni, kdybych si to reimplementoval. Ta knihovna už počítá s milionem různých divných případů, možná řešila nějaké CVE... Moje in-house řešení bude neotestovaná novinka s hromadou chyb (přesně jak sám píšeš), a tři řádky použití té knihovny jsou míň řádků s prostorem na chybu, než pár set řádků zbrusu nového kódu implementujícího standard, který neznám, a ve kterém zaručeně udělám hromadu chyb.
Ne, že bych taky nenadával, že aplikace na přenastavení myši a klávesnice potřebuje víc jak 1 GB RAM, ale na druhou stranu naprosto chápu, že takhle prostě společnost funguje.
-
"Poslední dobou mám čím dál větší pocit ..."
Vis, to je rozdil mezi programatorem a lepicem kodu.
Programator vi co dela, vi proc to dela, zna souvislosti a ma oborove znalosti. To navic vubec neznamena, ze se musi primo programovanim zivit.
Ja se treba programovanim nezivim, presto pro svy zakazniky cas od casu programuju, mimo jine proto, ze znam jejich procesy, a presne vim jak to dopadne, kdyz se byt ta nejprimitivnejsi vec nekde objedna. Je to na rok (kdyz malo) dohadovani se s negramotnym tatarem, kterej ani nezvladne vzit pripraveny query a proste ho pouzit. Nacez zjistis, ze ten tatar neumi nacist xml konfiguraci ... pripadne neumi z php poslat mail.
Jednomu takovymu sem musel osobne ukazovat, jak ze z phpka na asi 5 radku pripojis na soap ...
-
A ako sa to lisi od toho ked je vo firme senior programator, ktory vidi to nejakeho tajomneho zakutia projektu a nikto iny o tom nic nevie a vsetci len dufaju ze to dotycny da tohromady ked sa to poserie ? To je casto krat "vendor lock" na urovni zamestnanca. Alebo firma kupi kniznicu/nastroj ktora riesi niejaky parcialny problem. Tak isto do toho clovek nevidi a len ju zavola cez api a ocakava vysledok. To ze nieco vygenerujem cez AI a nikto nasledne tomu poriadne nerozumie v ramci spolocnosti, to nie je chyba AI. To bude skor procesne a systemovo nieco blbo nastavene v danej firme. Pouzivame technologie ktorym nerozumieme a nevieme ich ani odkontrolovat, ale to sa deje bezne. Pride zakazka ktoru treba vyhrat tak sa ide do toho aj s vedomim ze o tom prd vieme ale sak to sa nejak dobehne. Alebo tlacia terminy, treba mat vysledky, hotovu funkcionalitu nuz tak sa to vygeneruje. Druha vec je ze casto krat je dolezitejsia analyza problemu a navrh riesenia nez samotna technicka implementacia. A na tuto fazu bohuzial casto krat nie je vobec cas. A potom sa zakaznik divi. Vymysli si blbost, nechce ju konzltovat a neda si povedat, tlaci na termin a ked to dostane zisti ze sa to neda pouzit. Netvarme sa zasa ze kazda vyvojarska firma generuje SpaceX/NASA kod a riesa neriesitelne ulohy. Podla mna 80-90% komercneho kodu je klasicke nacitam data, zozujem data, zobrazim data a ziadna divoka magia v tom nie je.
-
Senior pokud neni blbec a nedrzi si tento status zamerne, tak si vychova juniory, kteri se postupne do projektu dostanou a nasledne jsou schopny resit cokoli samostatne a nakonec to prevzit a ucit dalsi.
Jde o to, ze znalosti dosud meli lidi, kdo se nenaucil, neumel. A bylo narocny tim projit, vyzkouset, mockrat narazit a nakonec se neco naucit (na skole, s knizkama, s internetem). Protoze ne vsechno bylo vsude napsane tak, aby to bylo presne pouzitelne pro to co resim.
Ale AI je neco co ten proces nahradi, proste vrati hotovou vec. Proc bych se ucil, kdyz to za me AI udela? Ale umi to ona, ne ja. Jde mi o to ze ta znalost neni uz u lidi, ale ve vektorech v AI.
A lidi se nebudou ucit od AI, prirozene hledaji zkratky, budou predavat praci AI. Myslenky firem ze budou mit 2 seniory a 6 programovacich agentu. Ze odstrihnou spoustu profesi a predaji to AI. To uz dnes slycham u zakazniku.
Ja uz si tech par let dojedu postaru :) ale moc me zajima co z toho vznikne
20. 3. 2026, 18:47 editováno autorem komentáře
-
To ty firmy říkají často dokud nemají s AI praktickou zkušenost. Problém pak je, že ta AI to za mě neudělá. Nevrátí hotovou věc. Ale laik si to myslí, že vrátila. A problém jaksi je, že těch zbylých 10 % trvá asi tak 60 % času a hlavně tu AI musí vést někdo, kdo tuší, která bije. Věci to zrychluje, o tom žádná. Ale rozhodně ne tolik, jak se snaží kdejaký hujer, linkedinový influencer (pozdravujeme pana Ludwiga a jiné podivné přednašeče) nebo laik, co ještě včera netušíl jaký je rozdíl mezi metodou a funkcí (nic blbějšího mě nenapadlo, laskavý čtenář si dosadí vhodný příklad) tvrdit.
-
> Rozdil je v tom, ze doted vzdy nekdo vedel jak kod funguje (na stitkach, v cobolu, v cecku apod.).
Že ten kód někdo nabušil rozhodně neimplikuje, že i někdo ví jak to funguje. :(
Kódu, kterému nikdo nerozumí, jsme měli mračna i před nástupem AIček. Stačí třeba s deadlinem na krku kopírovat ze stack overflow. A napadá mě hafo dalších možností, jak něco takového může nastat...
ČLÁNKY DO MAILU