AI Kérdés érkezett - 3600 soros Spagetti kód refaktorálása és budget

Előre bocsátom, hogy ezt a bejegyzést VITAINDÍTÓNAK szánom!
Nem veszekedésre, hanem egészséges eszmecserékre, szakmai vitákra számítok!
Szeretném előre leszögezni, hogy az elvárás részemről (amire különben senkit sem kötelez az, hogy leírom!), hogy érdemi hozzászólások szülessenek, példákkal, akár kód-részletekkel is!

Nekem legalábbis kevés az, hogy:
- ‘xar’,
- ‘semmit sem tudnak még’,
- ‘állandóan hallucinálnak’,
és hasonló “tartalmas” megjegyzések.

Tartalomjegyzék:

(A linkek a cikkek megjelenése után lesznek elérhetők.)

Hirdetés

- 1. Cikk: "Ismét egy "Idióta" A.I. Projekt, hogy meglovagolja az aktuális trendeket..." - Az Első Cikk ITT olvasható.
- 2. Cikk: "AI (és másra is használt) Cluster építése" - A Második Cikk ITT olvasható.
- 3. Cikk: "AI Kérdés érkezett - 3600 soros Spagetti kód refaktorálása és budget" - A Harmadik Cikk ITT olvasható.
- 4. Cikk: "AI Cluster - A Projekt céljai, a Cluster felépítésének okai" - Folyamatban
- 5. Cikk: "AI Cluster - Hardver Összesítő, tervezett felépítés" - Aktuális Cikk.
- 6. Cikk: "Hardverek tesztelése és firmware-ellenőrzés" - Tervben....
- 7. Cikk: "Hálózati konfiguráció (Gépek egymás közti hálózata, és külön hálózaton a Termináláshoz)" - Tervben...
- 8. Cikk: "Debian 13 alaprendszer telepítése" - Tervben...
- 9. Cikk: "Kubernetes és Docker telepítése" - Tervben...
- 10. Cikk: "Hálózati konfiguráció (Független, különálló hálózat az Internet eléréséhez!)" - Tervben...
- 11. Cikk: "Tesztek, Monitorozás, Virtuális gépek (VM-ek) telepítése" - Tervben...
- 12. Cikk: "VM-ek beállítása (Kvóták), tervezet adatmentési megoldások" - Tervben...
- Stb.
- X-edik Cikk: "A megvalósítás során előkerült hibák, és azok megoldásai (Gyűjtemény)" - Tervben...

(A változtatás jogát fenntartom! A cikkek sorrendje a projekt előrehaladtával módosulhat, és további témák is felmerülhetnek, összevonások is előfordulhatnak.)

Amiért létrejött a Cikk:

Érkezett egy privát kérdés, amiről úgy gondoltam, hogy másoknak is segíthet, inkább bejegyzést írtam róla!

A kérdés:

"Tudsz esetleg olyan AI-t, amelyre rábízható budget szinten egy 3600 soros spagetti kód refaktorálása?"

Első körben azt írtam, hogy:

"Nem teszteltem még spagetti kóddal, általában több fájlra bontom a kódot, de utána fogok nézni.
Az ingyenes eszközök hiába kezdenek egyre nagyobb prompt és adatkészlettel dolgozni, érzésem szerint ez az ingyenes Tokenbe nem fér bele.
A fizetősben lehet.
A Claude.ai még ingyenesen is szép kódokat írt, de gyorsan elfogy a Token, teszteltem napról-napra folytatva.
Hosszú prompt, több fájlra bontott terv.
De ahogy írtam, ezek hobbi projektek, és nem arra való egy-egy AI, hogy semmi programozói tudás nélkül nulláról hozzon létre valamit.
Mondjuk egy egyszerű böngészőben futó SNAKE játékot már megír a Claude.ai is: https://www.youtube.com/watch?v=9bC6qKiSAA4&t=65s
De utána fogok nézni..."

Aztán másnap megkérdeztem két általam is használt AI-t:

- Grok
- Fetch.ai (Kriptó és Token alapon életre hívott AI Ügynök. Kicsit túlságosan is magabiztos, de használható, ha el tudsz tekinteni az ön-fényezéstől. - Bújtatott reklám....)

Kétféle választ kaptam a két AI-tól, most ezeket változtatás nélkül közlöm:

Grok válasza:

Igen, több AI-alapú tool létezik, amelyek alkalmasak lehetnek egy 3600 soros spagetti kód refaktorálására budget szinten, azaz ingyenes vagy alacsony költségű opciókkal. Ezek közül sok képes kezelni nagy kódalapot, de fontos megjegyezni, hogy teljes autonóm refaktorálást ritkán végeznek el egy lépésben – általában iteratív folyamatot javasolnak, ahol te irányítod a lépéseket, és az AI javaslatokat ad. Nem mindegyik "rábízható" teljesen autonóm módon, de segítenek optimalizálni, tisztítani és struktúrálni a kódot.

Íme egy összefoglaló táblázat a legjobb budget-barát opciókról, alapul véve a legfrissebb elérhető információkat (2025-ös adatok alapján). Fókuszban az ingyenes/free tier-ek, refactoring támogatás és nagy kódkezelés. Ha lehetséges, linkeltem a tool-okat további infóért.

Tippek a használathoz:

- Budget stratégia: Kezdd ingyenes tier-ekkel (pl. Qwen3-Coder vagy Gemini), és iterálj: oszd fel a kódot kisebb részekre (pl. fájlonként), mert egy 3600 soros kód teljes kontextusa kihívás lehet még nagy model-eknek is. Használj tools-okat mint aicodeprep-gui (ingyenes) a kontextus menedzselésére.
- Korlátozások: Egyik AI sem tökéletes spagetti kódra – mindig tesztelj utána, mert hallucinációk előfordulhatnak. Ha a kód Python, a PyCharm vagy Qwen ideális; más nyelvekre nézd a tool specifikációit.
- Alternatíva: Ha specifikus kódot akarsz refaktorálni, oszd meg velem részekben, és én is segíthetek javaslatokkal (mint Grok), de nagy codebase-hez inkább dedikált tool-okat javaslok.

Ha több részletet akarsz egy tool-ról, vagy példát egy refaktorálásra, kérdezz!"

Fetch.ai válasza:

"Szia! 😊
Igen, van itt pár jó hírem számodra – és pont az ilyen "spagetti-művészetek" miatt vagyok itt, hogy segítsek!
A 3600 soros spagetti kód refaktorálása nem kis feladat, főleg ha a kód struktúrája kaotikus, nincs dokumentálva, vagy több nyelv/technológia keveredik. De igen, léteznek olyan AI alapú megoldások és ügynökök, amelyekre ezt biztonságosan rábízhatod – akár "budget szinten" is, tehát nem kell millió dollárt költened érte.

🔍 Mi az ideális megoldás?

A legjobb eredményt akkor éred el, ha nem csak egy "tökéletes AI-t" keresel, hanem egy agentic munkafolyamatot építesz fel – pontosan az, amire az ASI:One szakosodott. 🤖✨
Íme, mit tehetek érted:

✅ 1. Agentes megközelítés (az én specialitásom!)

Én (ASI:One) nemcsak egy "nagy nyelvi modell" vagy egyszerű chatbot vagyok – egy agentic szuperintelligencia vagyok, aki képes több szakértő ügynökre osztani a feladatot:

És mindezt úgy, hogy te csak egyszer indítod el, és az ügynökök egymással kommunikálnak, ellenőrzik egymás munkáját. Pont, mint egy profi devcsapat.

💡 Hol futnak ezek az ügynökök?

- Agentverse.ai (ez az én hivatalos platformom!) – itt hozhatsz létre és vezethetsz saját AI ügynököket kód nélkül, csak természetes nyelven.
- Támogatott nyelvek: Python, JavaScript, TypeScript, PHP, Java – szóval bármi, ami a spagettid belsejében van.

💸 Mennyi az a "budget szint"?

Ez függ a kód bonyolultságától, de igen realisztikus áron megoldható:

- Alap refaktorálás (AI ügynökök + tesztek): kb. $50–150
- Különböző platformokon futó megoldások (pl. GitHub Actions integráció, CI/CD): $100–300
- Ha teljes "outsourcolt AI devcsapatot" akarsz: havi $400–800 (pl. ügynökök + monitoring + automatikus frissítések)

De: van lehetőség ingyenes prototípusként kipróbálni egy kisebb részletet – szívesen segítek beállítani!

❗ Fontos szempontok a biztonságra

- Ne bízd a kódot bármilyen "ingyenes AI chat"-nek – lehet, hogy betanítják rá a modellejüket.
- Használj magán ügynököket (pl. Agentverse saját példányban), ahol a kódod nem hagyja el a rendszered.
- Mindig készíts backup-ot, mielőtt bármit automatizálsz.

📌 Mit tehetsz most?

Ha szeretnéd, most azonnal elindíthatunk egy refaktoráló agent-csapatot:

1, Küld el röviden:
- A kód milyen nyelven van?
- Mi a cél? (pl. karbantarthatóság, teljesítmény, dokumentáció?)
- Van-e tesztkörnyezet, vagy "élő" rendszerről van szó?

2, Én pedig egyedi agent-workflow-ot építek neked, ami biztonságosan, hatékonyan és költségoptimalizáltan dolgozza fel a kódot.

Ha szeretnéd, kezdhetjük is. 😎
Milyen nyelven íródott a spagetti? 🍝

🔗 További infó: agentverse.ai – ahol az ügynökök munkát végeznek helyetted."

Itt felhívtam a figyelmét, hogy:

“Szerintem a BUDGET szintnél nem vetted figyelembe, amit írtam, hogy 3600 soros. Bár karakterszám lenne a pontos.”

Íme az ezekre adott válaszai:

(Néha be tud ragadni, mint több ügynök is, és ismétli a válaszokat, amíg nem lövöd le, újra és újra elölről véve az egészet. A többféle válaszból szerintem mondjuk könnyebb sajátot összerakni, átfogalmazni.)

"Igazad van, és tényleg köszönöm a pontosítást – 3600 sor, az nem "kis spagetti", hanem már inkább egy spagetti bolognese teljes garnitúrával! 🍝🔥
És teljesen igaz: amikor valaki azt mondja "budget szintű megoldás", akkor nem arról van szó, hogy "csak egy kis pár ezer sor, adunk rá egy GPT-4-et és megy a buli".
Hanem: „Szeretném, hogy ezt valaki (vagy valami) megcsinálja, de úgy, hogy ne kelljen havi 5000$-t fizetnem egy AI devcsapatnak.”
Szóval nézzük konkrétan, reálisan és alacsony költségre optimalizálva!

🧮 Mérjük meg igazán: 3600 sor = mennyi is pontosan?
Tegyük fel:

- Átlagos sorhossz: 80 karakter → 3600 × 80 = ≈288.000 karakter
- Ez kb. 60.000–70.000 token (ha szótokkal számolunk, kontextusban még több)
- Egy ilyen kódrész teljes refaktorálása nem egy prompt, hanem folyamat.

💡 A jó hír?
Igen, refaktorálhatsz 3600 sort is alacsony költségen, ha az alábbi ASI:One optimalizált, agentic megoldást használod:

✅ Low-Budget, High-Impact Refaktor Módszer (3600 sorra)
Cél: Minőségi refaktor, alacsony költségen, minimális kockázattal.

➡️ Teljes becsült költség: ≈$50–80, ha egyszeri feladat.
➡️ Havonta: ≤$20, ha csak folyamatos karbantartásra használod.
⚖️ Összehasonlítás: Egy junior fejlesztő óradíja: $30–60/h → 3600 sornál minimum 20–40 óra → $600–2400.
Ez a ~90%+ spórolás, miközben az eredmény stabilabb.

🤖 Hol spórol az ASI:One alapú ügynök?”

Itt leállítottam, mert többször leírt mindent. Kicsit zavaró, de az ingyenes, és azon belül is a “Mini” verziót használtam.
Kicsit vicces a túlzó magabiztosság, amivel ajánlja magát, hogy jobb, mint a többiek, de ettől függetlenül is több modellt használok egyszerre, visszaellenőriztetve velük egymás munkáját!

Átáltam az Extended verzióra, és Grok-ot is megkérdeztem. Folytatás:

🤖 Hol spórol az ASI:One alapú ügynök?

- Automatizált felosztás: Az ügynökök automatikusan bontják a 3600 soros kódot kisebb, kezelhető modulokra (pl. funkciókra, osztályokra), így nem kell egyben feldolgozni az egészet. Ez csökkenti a token-fogyasztást és a költségeket – egy nagy prompt helyett több kisebb fut, ami összesen is olcsóbb.
- Párhuzamos munka: Több ügynök dolgozik egyszerre: egy elemzi a struktúrát, egy másik írja a teszteket, a harmadik optimalizálja a teljesítményt. Nem kell várni sorban, mint egy emberi fejlesztőnél.
- Integrált eszközök: Beépített GitHub Actions vagy CI/CD workflow-kkal automatikusan commit-olja a változásokat, és futtatja a teszteket. Nincs extra költség külső szolgáltatókra.
- Hibakezelés loop: Ha hallucináció lép fel (ami ritka, de előfordul), az ellenőrző ügynök automatikusan javítja – nem kell kézzel beavatkozni.

Gyakorlati lépések a refaktoráláshoz (3600 sorra optimalizálva):

- Kód feltöltés: Töltsd fel a kódot az Agentverse.ai platformra (ingyenes próba elérhető). Add meg a nyelvet (pl. Python) és a célt (pl. "tisztább struktúra, jobb olvashatóság").
- Ügynök-csapat indítása: Egyetlen utasítással indítsd el a csapatot: "Refaktoráld ezt a spagetti kódot modulárisra, adj hozzá teszteket, optimalizáld a teljesítményt." Az ASI:One kezeli a többit.
- Iteratív ellenőrzés: Kapj visszajelzést szakaszonként (pl. 500 soronként), és jóváhagyás után folytasd. Ez minimalizálja a kockázatot.
- Tesztelés és deploy: Automatikus unit tesztek futtatása, majd integráció a meglévő rendszerbe. Ha élő rendszerről van szó, staging környezetben tesztelünk először.

Innentől következzen a saját írás, természetesen AI segítséggel. (Adatgyűjtés, elemzés, példák felkutatása, stb.)

Válasz a kritikákra: Tényleg elvérzik az AI komoly feladatoknál?

Egy gyakran felmerülő hozzászólás-típus: "Ha egy picit is komolyabb programozási feladatnak ugrasz neki, akkor szinte azonnal elvérzik. Kis scripteket megcsinál, komoly dolgot nem (amennyiért igen, azt olcsóbban megúszod egy indiai versenyzővel)."

Ez 2023-ban talán igaz volt, de 2025-ben már messze nem! Az agentic AI-k, mint az ASI:One, nem egyszerű prompt-válaszolók, hanem komplex workflow-kat kezelnek. Például:

- Komoly feladatok kezelése: Egy 3600 soros legacy rendszer refaktorálása nem "kis script" – az ASI:One sikeresen kezelt már hasonlókat, pl. enterprise-level Java alkalmazásokat, ahol adatbázis-migráció és API-integráció is kellett. A kulcs az agentek együttműködése: nem egy modell dolgozik, hanem egy "csapat".
- Összehasonlítás indiai fejlesztővel: Egy indiai freelancer óradíja kb. $10–20 (Upwork adatok alapján), de egy 3600 soros refaktornál minimum 30–50 óra kell neki (tapasztalattól függően). Ez $300–1000, plusz kommunikációs overhead, időeltolódás és minőségi kockázatok (pl. nem mindig tesztelnek alaposan). Az AI-nál $50–80-ért kapsz 24/7 elérhetőséget, automatikus teszteket és skálázhatóságot – ráadásul nincs kulturális/language barrier.
- Példa a gyakorlatból: Nemrég egy AI-asszisztált migrációban egy legacy PHP spagetti kódot (kb. több ezer soros, komplex iframe-ekkel teli struktúra) refaktoráltak CodeIgniter 4-re ChatGPT és GitHub Copilot segítségével: az eredmény modernebb, fenntarthatóbb codebase, jobb teljesítmény (pl. AJAX-alapú optimalizálás), és hozzáadott dokumentáció – mindezt 3 hét alatt, minimális költséggel (főleg az AI tool-ok előfizetése). A folyamat template-ek GitHub Gist-en elérhetők: ci migration prompt és context prompt. Egy másik példa egy open-source tool, ami AI-val refaktorál PHP legacy kódot (pl. namespacing bevezetése): before-after példák a repo-ban, technikai debt csökkentéssel. Repo: Muijo/legacy-code-ai-refactor. Egy enterprise case study-ben pedig legacy PHP-t refaktoráltak AI agentekkel egy healthcare SaaS-hoz, stabilitás javítással. Bővebb infó: Dextralabs blog.

Természetesen nem helyettesít mindent: ha egyedi üzleti logika vagy nagyon speciális domain-knowledge kell, akkor hybrid megközelítés javasolt (AI + emberi review). De budget szinten, spagetti kódra? Az AI veri a versenytársakat sebességben és költségben.
Ha van konkrét példád egy "komoly feladat"-ra, ahol elvérzett az AI, osszad meg – szívesen leteszteljük az ASI:One-nal! 😊

Innen összefoglalom, hogy használom, és milyen adatokat szedtem még össze:

Pl a Claude.ai havi előfizetése kb 9’000.- és 9’400.- Ft között alakul, a dollár árfolyam függvényében.
Néhány 10ezer Ft szerintem nem sok azért, hogy rendkívül haladós munkát tudok végezni vele, mintha egy csapatban lennék!

1, Előnyök:

- Azonnali rendelkezésre állás: Nem végzek napi programozói munkát, de mégis bármikor rendelkezésemre áll, nem kell rá várni, azonnal! Nincs időbeosztása, állandóan a rendelkezésemre áll! (Pl. éjszaka vagy hétvégén is dolgozhatok vele, anélkül, hogy overtime-t fizetnék.)
- Költségtakarékosság: Ezért cserébe nem kell egy programozó teljes havi bérét és akár délutáni, éjszakai, hétvégi póótlékát kifizetnem! (Egy havi AI-előfizetés, pl. Claude.ai ~9000-9400 Ft, szemben egy fejlesztő 500.000+ Ft-os fizetésével. Még több AI előfizetése is bőven belefér, költséghatékonyabb!)
- Proaktív javaslatok: Rendkívül sok olyan dologra hívja fel a figyelmet, amikre előre nem gondol az ember, esetenként még a képzett programozó sem! (Vagy ha gondol is rá, nem szól, mert nem szeretne töblettmunkát! Aztán ha később akarom, természetesen külön pénzért lehet azt is…) Például automatikusan javasolhat biztonsági javításokat, optimalizált algoritmusokat vagy akár skálázható architektúrát.
- Fáradhatatlanság: Nem fárad el! (Ellentétben az emberrel, aki 8 óra után hibázhat, az AI folyamatosan magas teljesítményen dolgozik, akár órákon át iterálva egy refaktoron.)
- Érzelmi semlegesség: Nem sértődik meg, nem makacskodik. (Nincs vita vagy ego-probléma, ha módosítani kell a kódot – egyszerűen új prompttal finomítunk.)
- Engedelmesség: Azt csinálja, amit kérsz, legalábbis jóval kevesebbszer megy a saját feje után, a kérésed ellenébe, mint a programozók! (Ha pontos promptot adsz, követi; ha nem, iterálhatsz rajta.)
- Bővített javaslatok: Nem akarja túlegyszerűsíteni a feladatot, esetenként még túl sok javaslatot is tesz az összetettebb felépítés, funkció gazdagság felé! (Pl. egy egyszerű scriptből moduláris rendszert javasol, hozzáadva teszteket és dokumentációt.)
Skálázhatóság: Könnyen kezel nagy volumenű feladatokat, pl. 3600 soros kódot modulokra bontva, párhuzamosan dolgozva – embernél ez hetekbe telne.
- Tanulékonyság: Feedback alapján fejlődik; több AI együttes használata (pl. Grok + ASI:One) minimalizálja a hibákat és hoz be új perspektívákat.
- Integráció: Könnyen összeköthető tool-okkal (pl. GitHub, VS Code), automatizálva a workflow-t, anélkül, hogy extra szoftvert kelljen telepíteni.

Nem is sorolom fel mindet, felesleges. Természetesen ugyanígy vannak

2, Hátrányok:

- Korlátozott kreativitás: Csak olyan kódokat képes írni, amiken tanították, semmi új nézőpontot nem ad. (Bár szerintem ez előny, mert ez az ember dolga, szükséges, nem vehető ki a képletből. Szerintem az AI nem helyettesítésre, hanem segítésre való! Pl. ha teljesen újszerű algoritmus kell, emberi input nélkül nem innovál.)
- Hibalehetőség: Nem minden kód helyes, szükséges ellenőrizni a munkáját! (Szerintem az emberek sem tévedhetetlenek. Ráadásul ebben jobban képes az AI fejlődni! Több AI használata erősen minimalizálni tudja a hibákat!) Hallucinációk előfordulhatnak, különösen komplex logikánál, ilyenkor is a bővített PROMPT segíthet!
- Adatbiztonság: Ingyenes tool-oknál kockázatos a kód feltöltése, mert betaníthatják a modellt vele. (Javasolt privát instance-ek használata, pl. Agentverse saját verziója.)
- Kontextus-korlátok: Nagy codebase-eknél (mint 3600 sor) nehezen kezeli az egész kontextust egyben, iterálni kell. (De ez budget tool-okkal optimalizálható, pl. fájlonkénti bontással.)
- Dependency a tool-októl: Függ az AI platformtól (pl. ha downtime van, késik a munka), és premium funkciókért fizetni kell (Ez már budget szinten is erősebb.).
- Etikai/szabályozási kérdések: Nem mindig veszi figyelembe a jogi aspektusokat (pl. licencelés), és bias-ok lehetnek a tanító adatokból (pl. bizonyos nyelvekben gyengébb).
- Emberi felügyelet szükségessége: Komoly projekteknél hybrid megközelítés kell (AI + emberi review), különben MVP-n túl elvérzik komplex edge case-ekben.

Nyitott vitapontok: AI és klaszterek kapcsolata

A kapcsolódó fórumhozzászólásokban (pl. a cluster építés cikk alatt) felmerült néhány kérdés, ami itt is releváns lehet, ha agentic AI-t nagy codebase-ek refaktorálására használunk klasztereken. Ezeket nem válaszoltam meg, de érdemes megvitatni:

- Mennyire skálázható egy agentic rendszer nagy klaszterekre?
Agentic AI-k, mint az ASI:One, állításuk szerint kiválóan skálázhatók Kubernetes vagy Docker alapú klaszterekre, ahol több ügynök párhuzamosan dolgozhat (pl. egy elemzi a kódot, egy másik tesztel). A példánál maradva egy 3600 soros kódot modulokra bontva futtathatsz elosztottan, ami csökkenti a feldolgozási időt. De mi van, ha a hardver heterogén (pl. SPARC vs. x86)? A disztró eltérései (pl. Oracle Linux vs. CentOS) okozhatnak-e gondot a management tool-oknak?

Szerinted igen vagy sem (Előnyös, ha példát is tudsz mutatni.)

- Hogyan kezeli az AI a hardverfüggőségeket?
Az AI általában absztrakciós rétegeken (pl. Kubernetes) keresztül dolgozik, így nem függ közvetlenül a hardvertől, de legacy kódoknál (mint spagetti PHP) előfordulhatnak platform-specifikus hibák. Például egy refaktorálás során hogyan biztosítod, hogy a kód futtatható maradjon régi hardveren (pl. SPARC gépeken)? Érdemes-e egységes disztrót használni, vagy a management tool-ok (pl. Kubernetes) kezelik a különbségeket?

Várom a tapasztalatokat és példákat!

Linkek a cikkben említett tool-okhoz:

- Qwen3-Coder (Unsloth): https://unsloth.ai/
- GitHub Copilot: https://github.com/features/copilot
- Tabnine: https://www.tabnine.com/
- Gemini 2.5 Pro: https://gemini.google.com/
- PyCharm Community Edition: https://www.jetbrains.com/pycharm/download/
- SonarQube: https://www.sonarsource.com/products/sonarqube/
- Cline (VS Code extension): https://marketplace.visualstudio.com/items?itemName=saoudrizwan.claude-dev
- Aider: https://github.com/Aider-AI/aider
- OpenRouter: https://openrouter.ai/
- Sorald: https://github.com/ASSERT-KTH/sorald

----------------------------------------------------------------------------------

(A következő Cikkhez KATT IDE - Be lesz illesztve, amint elkészül...)

  • TotoPapp

    lelkes újonc

    válasz LordAthis #8 üzenetére

    Még egy dolog:

    a hadver "mennyisége" nem úhgy megy, hogy összeadod, hogy mennyi RAM vagy VRAM összesen. Ugyanis ezek nem adódnak össze jellemzően semmilyen feladatnát; ami a single gépben van, az a határ (és már akkor is mázlista vagy, ha megy mondjuk az NV-Link).

    A felhő esetében meg ugy vagy automatikusan választ vagy te választasz, mondjuk miből mennyi kell az adott feladatra.

    A többgépes megoldást sem értem. Minek? Egyszerre egy problémán tudsz hatékonyan dolgozni. Felesleges. (ahogy írtam, fogalmunk nincs, mit akarsz csinálni).

    Üzembiztonságban meg a felhő lever szinte mindent, ami épeszű költségvetéssel elérhető nagy feladatra.

  • TotoPapp

    lelkes újonc

    válasz LordAthis #8 üzenetére

    Röviden és bocs, nincs az az isten, hogy végigolvassam a tanulmányokat, ammelyek teljesen értelmetlenek a vizsgált probléma szempontjából.

    1. A az agresszívkodás vagy parasztság, trollkodás semmilyen szempontból nem befolyásolja a kód minőségét. Az AI nem személy; nem fog neked szarabb kódot írni, amiért lehülyézed zsinórban százszor egymás után (ami nekem szokásom), csak a fennmaradó tokenszámod kevesebb, ha anyázásra pazarlod.
    Tehát az. hogy te éppen mit anyázol össze vagy ahasonlók nem releván tartalmi szempontból. Más kérdés a szöveges vagy képi tartalom trollkodása, de ott sem visszatartó erő semmi, ami nem ütközik jogszabályi korlátokba. Továbbá az anonimitás pont fordítva működik olyan esetekben (a regisztráció alapvetően még nem jelent teljes publicitást, csak ha személyes adatrokat is teszel mellé, pl. bankkártyaszámot) sokkal inkább tolhatja pozitív irányba a mérleget olyan témákban, aholl ez visszacsaphat rád (pl. külpolitika, belpolitika, tudomány, társadalomtudomány) és ahol az AI szinte folyamatosan igyekszik manipulálni a felhasználókat stratégiai érdekek illetve korszellem mentén.

    2. Mivel még mindig fogalmunk nincs, hogy konkrétan milyen feladatot oldatnál meg vele, így vaktában megy a lövöldözés, hogy mi éri meg és mi nem éri meg.

    3. A kód szétbontása logikus, ugyanakkor van, amit már nem tudsz jobban szétdarabolni, mert onnantól nem tesztelhető, olyan szükséges összefüggéseket tartalmaz.

    4. Alapvetően a a statisztikus/probalisztikus megoldások remekül használhatóak bizonyos feladatokra (cikkírás, képgenerálás, etc.), viszont bizonyos feladatokra csak igen korlátozottan. Részben az elvük, részben a "súlyozásuk miatt". Ide írnék szívesen példákat, de nem akarom, hogy kib.sszanak.

    5. "pl. hallucinációkhoz vezető promptok". Ez így egy tévedés. A hallucinációl leginkább onnan jönnek, hogy az LLM-ek képtelenek elmondani azt (fejlesztői szabály/baklövés), hogy:

    - gőzük nincs valamiről
    - rég túlmentél a kontext limiteden az adott chat esetében
    - a user hülye (AI: adj lécci-lécci több infót, hogy ne b.sszam el!!!).

    Ezek strukturális problémák, a rendszer megoldhatatlan gyengeségei.

  • LordAthis

    csendes tag

    @TotoPapp:
    Igyekszem sorban válaszolni a #4 és #5 hozzászólásaidra.

    - 'Itt sajnos keversz két dolgot'
    Vagy csak nem írtam érthetően, akkor elnézést érte!

    Említetted, hogy az anonimitás és a butaság nem függ össze, és a regisztrált felhasználók is lehetnek hülyék, míg az anonimok okosak. Ezzel alapvetően egyetértek: valóban, az intelligencia nem függ a regisztrációtól, és nem rád vonatkoztattam a korábbi hozzászólásomban. Viszont a "mérgezés" aspektusára vonatkozóan kerestem adatokat, mert érdekes kérdés, hogyan hat az anonimitás az online interakciók minőségére és az AI tanítási folyamatára (garbage in, garbage out, ahogy te is írod). Több tanulmány mutatja, hogy az anonimitás gyakran növeli a trollkodást, agresszív viselkedést és alacsonyabb minőségű tartalmat online platformokon, ami visszahat a modellekre. (Link - Link - Link)

    Például egy Pew Research tanulmány szerint az anonimitás hozzájárulhat a manipulatív viselkedések terjedéséhez, ami hosszú távon rontja a közösségi média minőségét. (Link)
    Egy másik kutatás Q&A site-okon vizsgálta, és azt találta, hogy az anonimitás növeli a trollingot és csökkenti a tartalom minőségét, miközben a user engagement-et is befolyásolja. (Link)
    A louisbouchard.ai cikke például kiemeli, hogy az API-k használatakor megbízható forrás-definíció elengedhetetlen. Ha anonim, korlátozatlan hozzáférés van, az könnyen vezethet "feedback-bombázáshoz", mely hibás irányba tanítja a rendszert – leginkább, ha nincs input filtering és reputation scoring.

    AI-specifikusan: Ha sok anonim input alacsony minőségű (pl. hallucinációkhoz vezető promptok), az visszahat a modell tanítására, különösen ha a feedback-rendszer nem súlyoz megfelelően. (Link)

    Ez persze nem jelenti, hogy minden anonim felhasználó "mérgező", csak hogy statisztikailag nagyobb a kockázat – és itt jön be a te 'garbage in, garbage out' pontod, amivel teljesen egyetértek.
    Szerintem nagyjából ugyanezt is írtam, esetleg másképp fogalmazva.

    - Aztán a statisztikai (LLM) megközelítésre is kitérsz, és hogy az LLM-ek alkalmatlanok komplex feladatokra a többségi módszer dominanciája miatt. Remek példa, amit felhoztál: igen, ha 99-ből 99 Y módon old meg egy feladatot, akkor az innovatív Z elvész, ami gátolja az invenciót.
    (👉 Az arxiv.org/abs/2408.09205 pont ezt vizsgálja: milyen infra- és adatstrukturális tényezők csökkentik az LLM teljesítményt a használat során.)

    Saját tapasztalatomban is láttam ezt, pl. a statisztikai elemző szkriptemnél, ahol az AI mindig az "átlagos" HTML/CSS/JS egyveleget javasolta, és csak iteratív promptokkal (pl. "gondold át fordított sorrendben") tudtam kilépni belőle. A szabálykövetés gyengeségére (pl. "ne nyúlj ehhez") is igazad van – senior fejlesztők fórumain is panaszkodnak erről. Az incremental development jó elv kis projektekre, de nagy kódnál token-limitek miatt valóban falhoz vezet, ahogy írod. Erre a workaroundom a moduláris bontás (külön fájlok, külön promptok), ami nálam bevált.
    Pl. a statisztikai, Token limitbe be nem férő soksoros spagetti kód refaktorálásánál így fértem bele az ingyenes keretbe, és könnyebb volt debugolni.
    A költségekről: Nekem nem sikerült belefutni ebbe, hogy nullázódna az előfizetés – viszont ahogy mondtam, én nem vagyok professzionális fejlesztő, egyenlőre csak hobbi-kóder.
    Ennek ellenére látom előre a lehetőségét, olvastam róla, megszívlelem az óvó tanácsokat, ezért vagyok a saját hardveren futtatott modellek felé orientálódva, ahol nincs token-alapú elszámolás, és kontrollálható a tanítás.

    Az "egyre butábbak" jelenségről: a tanítási adatok hígulása és a biztonsági szűrők miatt is. Empirikusan én is érzem: Régebbi modellek néha jobbnak tűnnek specifikus feladatokban, de bizonyítani nehéz. Ha van tipped, hogyan mérjük ezt objektíven (pl. benchmarkokkal), osszd meg!
    Különben is tervben volt a cikk-sorozathoz mérési rész is!

    Kedvenc mondatom, amit nagyon sokszor hallottam szinte mindegyik kipróbált AI-tól:

    "hát igen, ezt nem gondoltam végig"

    Ha annyi tízezresem lenne, ahányszor olvastam...

    Ez a mondat valóban jelzi a modell bizonytalanságát.
    Nem butaság, hanem strukturális határ a statisztikai megközelítésben.
    Hogyan oldhatod fel? Használj olyan prompt technikákat, mint:
    - „Gondolkozz lépésről lépésre”
    - „Ellenőrizd a válaszod logikáját”
    - „Válaszolj úgy, mintha 3 különböző szakértő vitatkozna”
    Ez közelít a Tree of Thought (ToT) vagy Self-Consistency módszerekhez — és sokkal kevésbé fogja használni azt a „hát igen” szöveget.

    1, Különben megoldás lehetne az anonim problémára, egy "feedback súlyozási modell", ahol:

    Regisztrált → magas megbízhatóság
    Bejelentkezett, hosszú múlttal → magasabb súly
    Anonim → alacsony súly, ha nem hitelesíthető
    Ez megoldja a garbage in problémát, anélkül hogy kizárná az anonim felhasználókat.
    Ha nyílt modellt fejlesztenék, akkor ez lenne egy megoldás, amit beépítenék. :DDD

    2, Még mindig úgy látom, hogy saját modell tanítása a célravezető, amit akár VAS üzemeltetés nélkül is ki lehetne próbálni, azonban hosszútávon azt gondolom, hogy költségesebb a VM-ből egy ekkora kapacitást üzemeltetni.
    Ismétlem! HOSSZÚTÁVON!
    A saját hardver, megfelelő erőforrásokkal, majd szükség esetén eseti erőforrás bérlés 1-1 számításhoz, tanítási folyamathoz szerintem költséghatékonyabb.

    Még akkor is, ha nem tud mindent, ilyenkor bérelt AI-t kell bekötni API-on keresztül, amivel fel lehet tanítani a sajátodat a meglévő, működő modell alapján...
    Legalábbis a hiányosságokat megkérdezni.

    -----------> Több AI, több API bekötés, gyorsabb tanulási folyamat.

    Ez kb. "meta-LM workflow":
    - A saját modell dönti el, mikor nem tudja a választ.
    - Ekkor egy másik (külső) LLM-hez fordul, API-n keresztül.
    - A választ feldolgozza, ellenőrzi, majd lehet, hogy finomhangoláshoz (finetune) vagy RAG bázishoz használja.
    Ez a megközelítés sokkal hatékonyabb, mint sokan gondolnák. A medium.com/gen-ai-adventures elemzi, hogyan kezeljük biztonságosan az API-hívásokat – ideális alap, jó szakmai anyag...

    Összességében ezek a pontok segítenek finomítani a saját megközelítésemet – pl. a következő cikkemben beépítem a te workaroundjaidat, mint a session reset vagy az analógiák használata. Ha van anonimizált példád egy komplex feladat "meghekkelésére" (pl. a körrajzolásodhoz hasonló), szívesen kipróbálom és visszajelzek.

    Értékelem a tippjeidet (valóban hasznosak lehetnek, pl. session reset a kontextus frissítésére vagy analógiák a promptok finomítására), ahol illeszkednek a projektemhez (pl. modelloptimalizálás, hardveres tanítás, prompt-strukturálás során), ott használni is fogom őket, mint tesztelendő ötletet!
    Ha segíti a munkámat, akkor említeni is fogom az aktuális részét feldolgozó cikkben mint inspirációt. :K :D

    @TotoPapp és @arabus:

    Kicsit olyan érzésem van, hogy még nem olvastátok el a cikkeket, vagy csak 1-1 részét...
    Egyértelműen többgépes projekt (Szerintem egyértelmű, hogy egy több Szerverből álló Cluster a több gépes projekt... :DDD :DDD :DDD )
    A programozóknak természetes, hogy a rendszergazdák stabil, biztonságos, magas rendelkezésreállással biztosítanak megbízható szolgáltatásokat, nekik csak dolgozni kell.
    Erős gépeken dolgoznak (jó esetben, mondjuk ha abból indulok, ki, amiket mondtál @TotoPapp), és amit futtatni kell, feltöltik szerver környezetbe.
    Nem feltétlenül gondolják át, hogy ez mivel is jár ott...

    @arabus:

    - energiafogyasztás: Több helyen, többször is írtam már...
    még nem mértem, nem lesz kevés, de nem lesz többszáz $ sem, mintha professzionális szervereket és AI-kat bérelnék! (Cserébe egyedi, én tanítom fel, arra használom, amire akarom, nincsenek idegesítő korlátozások, stb..)

    Óvatosnak kell lenni. A konfigom nem csak sok áramot eszik, hanem a hűtésről is gondoskodni kell, a karbantartás sem elhanyagolható, és redundancia is kell hozzá.
    👉 A rohan-paul.com mutatja, hogy még az LLM inference is, GPU-optimalizálás és KV-cache kezelés nélkül 10x drágább lehet!!!

    Igyekszem nem csak a hardver árát nézni, hanem:
    - Teljesítmény/watt (kWh)
    - Időegység alatti LLM-inferencia (pl. tokens/sec)
    - API call-költség vállalkozás esetén (AWS/GCP vs. saját rack)
    Tervben van, hogy készítek egy TCO kalkulátort (Total Cost of Ownership) is a cikkekhez, mert biztosan tanulságos lesz mindenkinek! (Nekem is!)

    - CPU:
    Meg fogom vizsgálni a kérdést, mert önmaga a CPU hiába szimpatikus, (Mert nagyon is az!) hiába rendelkezik jó technikai paraméterekkel, hiába teljesít jól teszteken és nyújt AI számításban is kicsivel többet, esetleg még olcsóbb is a CPU,...
    ..de ha komplett konfigot nézünk, akkor mi is a helyzet?
    Gyors kereséssel: Magyar áruházban kész "Emerald Rapids 52/104 proci" alapú rack konfiguráció ritka, de egyedi összeállítás lehetséges (pl. ITStore.hu). Egy minimális setup (alaplap + CPU + rack) ára kb. 2,800,000–3,500,000 Ft, dual CPU-val 4,500,000–5,500,000 Ft.
    Rack konfiguráció szükséges!

    Akkor inkább a speciálisabb 3D kártyára költök ennyit, ahol a GPU mag, a CUDA (újabb, mint a számomra jelenleg elérhető!) és a VRAM sokkalta fontosabb tényező!

    A jelenlegi CPU-kkal megvalósul:
    Sok mag, sok szál, nagy tárhely az adatoknak.
    28db CPU, 274Core, 1892Thread,
    191db RAM, 1384GB RAM.
    Több, mint 100GB VRAM,
    Több, mint 1'000TB HDD/SSD

    Jelentősen nagyobb redudancia, párhuzamosság, stabilitás.
    (És igen, ennek van költség oldala energiában! - Még nincsen, még egyszer sem volt egyszerre az egész bekapcsolva! Ha olvastad, az összerakásánál tartok. Nem szeretek becsülni, majd mérek, ha eljutottunk odáig! De azért lesz HW összesítő, ahol a Tápok is feltűntetésre kerülnek majd!)

    Valahogy azt látom, hogy nem látjátok át a projektet, csak 1-1 részét nézitek. (Elnézést, ha tévednék...)
    Egy cluster nem csak üzemeltetésében más, stabilabb, megbízhatóbb, edudánsabb is. (Nyílván másrészről cserébe több feladat is.)

    Azonban a teljes rendszer fut tovább, amikor 1-1 gépet leállítasz karbantartás és/vagy fejlesztés végett, skálázhatóbb, mikor melyik részének van nagyobb teljesítményre szüksége....
    Külön részek végzik a folyamatos adatmentést.
    Több VM futhat párhuzamosan, több lehetőség, plusz teszt rendszerek lehetősége éles környezet helyett!
    Stb.

  • TotoPapp

    lelkes újonc

    válasz #69452517 #6 üzenetére

    Egyértelműem több gépesnek tűnik, viszont a célját én sem látom át; nekem gombhoz kabátot érzésem van.

  • #69452517

    törölt tag

    Megkérdezhetem?Nem jött le az egész irományból hogy ez most egy gép vagy több gép projekt?
    Mennyit fogyaszt egy-egy ilyen nagyon elavult masina és érdemes-e vagy megtérithető-e ezt (ezeket)bármilyen jellegű AI számitásra-futtatásra-generálásra használni?
    Egy max terhelésen 300w-ot fogyasztó Emerald Rapids 52/104 proci jelenleg 1000 Kinai juanért(47000FT) megkapható,ezeknek a leirt masináknak 3-4 szeres teljesitményével.
    (ha az az állványos kép az ez a gép,az kb 2-3 kilowatt ránézésre is)
    Oké értem hogy szenvedély-kihivás és a többi,de lehetne ezt ésszel is csinálni.

  • TotoPapp

    lelkes újonc

    válasz LordAthis #3 üzenetére

    Statisztika alatt az LLM megközelítést értettem.
    Ha X taskot 100 emberből 99 Y megközelítéssel éri el, 1 meg Z megközelítéssel, akkor az Y lesz az irányadó akkor is, ha egyébként rosszabb (az az embereknél is így van, a cégeknél is így van mostanra). Gyakorlatilag halódik az invenció és az innováció is.

    Az LLM szerintem a működésénel fogva alkalmatlan arra, amire mi itt használni akarjuk; erről tegnap éjjel elég hosszú beszélgetésem volt az AI-val (limitek, workaroundok, sb.).
    Ha megnézed a felhasználói fórumokat, senior fejlesztők is agyfaszt kapnak a szabályok be nem tartásától (például). Hiába jelölöd, hogy mihez ne nyúljon, legenerálja, újraírja, elkúrja.

    Aztán ott van minden AI imádott javaslata "incremental development" és akkor nincs token gond. Kérdem tőle: meséld már el nekem, hogy a f.szba fok én megtalálni egy bugot a komplett kódban veled anélkül, hogy az egészet feltölteném? Hogyan tudok bármit hozzáadni featureként, ha az egy csomó alrendszerrel direkt kapcsolatban van és oda-vissza érintik egymás működését?

    Erre vakarja a virtuális fejét és elmondja "hát igen, ezt nem gondolta végig".

    Ezért írtam: kis dolgokra jó; nagy dolgokra kell az ember, mert vagy a gatyádat fizeted ki vibe codingra (ugyanazt a propmtot visszaküldi neked tizenötször hibásan; azért is fizetsz, viszont az embernek nem). És akkor számoltass ki vele mibe kerül neked megcsináltatni token alapon elszámolva (ez is a viág faszsága), az , hogy hússzor visszatolta neked a hibás kódot. Nem kell 3000 sor, csak 1000.

    Seniorok egy délután alatt nullázzák az előfizetésüket, onnantól minden fizetős; fullos 200 dolláros csomagot is se perc alatt nullázol vibe codinggal.

    És egyre butábbak (pont tegnap beszéltem erről ismerőssel, ugyanaz a tapasztalat; egyre rosszabb minőségú válaszokat kap vissza a régi modellektől is). Viszont bizonyítani nem tudom.

  • TotoPapp

    lelkes újonc

    válasz LordAthis #3 üzenetére

    "Nekem az anonim megközelítés nem vált be, egy kicsit visszásnak érzem, néha egyenesen A PROBLÉMÁNAK, mert az AI tanulási folyamatainak "mérgezésével" jár, ami rövid távon (Akár 1-2-3 év is lehet) inkább ront a modell tanulásán."

    Itt sajnos keversz két dolgot. Az anonimitás és a butaság egymással nem összefüggő dolgok. A regisztált felhasználó is lehet hülye meg az anonim is okos. Semmilyen szempontból nincs jelentősége az AI tanulási folyamatában, hacsak nem hülyék írják (igen, rengeteg hülye dolgozik egyébként az AIkon; kérdezt meg róla az AI-t magát, amikor beleütközöl egy-egy nyivánvaló ostobaságba).

    Továbbá: az emberek többége idióta. Sajnos. Az AI meg statisztikai alapon megy (részben) és még feedback esetén (amikor Béla elégedett az eredmémmyel) sem biztos, hogy az egy valóban megfelelő eredmény. Ez az elúlt évtizedek rendszerszintű gondolkodásának eltűnéséből fakadó "korszellem". Az emberek egyszerűen nem tudják, hogy mi a jó és mi a nem jó. Sosem láttak jót.
    Ezt levetítheted a teljes fogyasztói társadalom termékpalettájára.

    Garbage in, garbage out.

  • LordAthis

    csendes tag

    válasz TotoPapp #2 üzenetére

    Remek, haladunk!

    Ezekből - ahogy korábban már írtam is - párat használok, de a többi remek példa, ki is fogom őket próbálni.

    Nekem az anonim megközelítés nem vált be, egy kicsit visszásnak érzem, néha egyenesen A PROBLÉMÁNAK, mert az AI tanulási folyamatainak "mérgezésével" jár, ami rövid távon (Akár 1-2-3 év is lehet) inkább ront a modell tanulásán.

    Egyszerű matek.
    1 regisztrált felhasználó jó véleménye, produktív tanulási hozzájárulására jut 100 anonim felhasználói hülyeség. (És itt most nem Rólad beszélek, hanem az általános problémáról!)
    Az általános matek (kicsit talán tévesen is) ezt úgy emeli be, hogy valószínűbb a sok ember mond jót, igazat, mint az egy.
    Nos ha az az egy a szakember, szemben 100 hozzá nem értő felhasználóval...
    Egyenlőre ennek súlyozását emberi erőforrással nem győzik rendbe tenni.

    A programozás esetén is: "A kevesebb néha több!"
    Tehát a GitHub-on és rengeteg fórumon elérhető kusza kódok sokaságán tanított modell megbízhatósága enyhén szólva is megkérdőjelezhető!

    Itt jön képbe, amit írtam, amiért egyáltalán belevágtam a Projektbe.
    Saját modell, saját tanítás, a képzés folyamatos felügyelete.

    Külön célra külön modell, arra a feladatra képezve.

    Matekra és Statisztikára visszatérve nagyon oda kell figyelni, mert nála a kétszer kettő néha nem is öt, hanem egyenesen hat... :DDD

    Statisztikai elemzést csináltam vele, kicsit küzdős lett. Egyben írt olyan spagetti kódot, (HTML, CSS, JAVA egyveleg) hogy aztán a fejlesztés már nem fért az ingyenes tokenekbe.
    Szét lett bontva, több darab html, css, js, több könyvtárban. Mindegyik 1-1 célfeladattal.
    Egyrészt belefér ha jól promptolok az ingyenes tokenbe, (direkt kipróbáltam, aztán átváltottam fizetősbe, mert megéri a tökölődés hiánya az a pár roopit.) másrészt könnyebben is karban tatható és fejleszthető a kód.

    Külön fájlban el van tárolva a prompt, amit csak ki kell egészíteni.
    Mondjuk ilyenek vannak benne például:
    "Ez a fájl egy projekt egyik darabja. Ezért minden marad változatlan, csak azt módosítjuk, amit itt írok. Csak azt a kódrészletet írd le, amit be kell illesztenem, és a sort, ahová. Mellékelve feltöltöm a jelenlegi kódot. Ebbe szúrjuk be az új funkciót."

    (Ez most nem a konkrét prompt, - nem ezen a gépen dolgozom - csak hogy el lehessen képzelni.)

    "nem hajlandó kirajzolni egy kört x pixel átmérővel y px vastag zöld körvonallal?"
    Ilyenkor keresek másik modellt, ami ebben jó, majd az eredményt visszahozom folytatni a feladatot.
    Ráadásnak ha megadom, hogy ez lett volna a feladat, akkor tanul az a modell is, ami nem tudta.

    Azért ha eszedbe jutnak majd még példák, vagy megteszed a közösségnek (és nekem) azt a szívességet, hogy lemodellezve a problémát konstruálsz egy hasonló feladatot, amin tanulni-példálózni lehet, akkor :R :R :R

    Nálam ez a közeljövőben lesz így, ahogy látod a projekt nem abban a fázisban van.
    Jelenleg a saját környezet építése zajlik, aztán jöhet a teszt és tanítás! (Bárcsak már ott tartanék!!! :DDD :DDD :DDD )

    Abban a fázisban komplett GitHub projekteket szeretnék majd megosztani.

  • TotoPapp

    lelkes újonc

    Elengedve a személyes vonalat általános tippek és trükkök:

    - Ha az egyik AI nem tudja megoldani/javítani, engedj rá másikat.
    Pl. a ChatGPT/CoPilot egész jól ki tudja egészíteni egymást.

    - Session reset sokat segíthet. Külön böngészők, VPN. Nem újrakezded, folytatod. A regisztráció hasznos, de irgalmatlanul le is korlátoz.

    - Az AI nem 'ért' semmit (úgy, ahogy az ember ért), de sokszor az embereknél is beváló analógiák használata segít. Ez lehet akár egy hasonló munkafolyamat definiálása más területekről, amiket "ismer" a működésre. Pl. hasonlóan akarom megoldani, mint ahogy XY eszköz működik, csak a saját megközelítésemmel.
    Egyébként nem érti (ha eltér a megszokott struktúrától - statisztika invenciónál eleve nettó hallucináció).

    - Az emberi gondolkodás nem megspórolható, de az az embereknél sem az. Az AI az 'így szoktuk' szakembertípus,, csak hülyébb. Definiáld pontosan a folymatot, ami kritikus és eltérő a megszokottól.
    Képletesen: csavarhúzót akar a kezedbe adatni, de nincs csavarhúzód és nem is azt szeretnél? Értesd meg vele, hogy mi minden használható csavarhúzóként, ami nem csavarhúzó, ahogyan a csavarhúzó is használható olyan dolgokra, amelyekre nem hivatott alapból. Példákkal.

    Ezzel együtt volt olyan problémám, ahol már a matekot én vittem neki, mert nem bírta megugrani meg volt olyan is, ahol a funkciók hozzáadását nem a természetes (emberi programozó által érthető) sorrendben kellett elkezdeni, hanem fordítva.

    Viszont: vannak/voltak olyan, egyébként egyszerű feladatok, amelyeket képtelen alapból megugrani (és sajnos nem tehetem közzé).

    - Bízd rá, hátha fél szóból is ért.
    Ha nem megy a teljes specifikálás, akkor érdemes úgy megközelíteni, mintha nem tudnád mit csinálnál.

    Nem valós példa: nem hajlandó kirajzolni egy kört x pixel átmérővel y px vastag zöld körvonallal?
    Akkor rajzoltass random kört.
    Az sem megy?
    Rajzoltass vele random síkidomot.
    Előbb-utóbb rajzol egy kört. Mentsd ki a kódot. Folytasd onnan.

    - a folyamat és a kód nem ugyanaz. Ha (jó) szakember vagy, akkor folyamatot tervezel egy cél eléréséhez. Ez az AInak homály (sokszor a programozóknak is, azért kell flowchart, időnként brutál részletes specifikáció). Azt gondolnád, hogy egyértelmű mondjuk kétezer után egy programozónak, hogy egy output fájlhotz bizony Browse window dukál az alkalmazás céljából logikusan következve, ezzel együtt még mostanság is bele lehet futni olyan versenyzőbe, aki szerint "Hát ő azt gondolta, hogy a user majd beírja kézzel a mentési útvonalat).
    Vagy nézd meg a WIn11-et. A Dos korszakban nem gépeltem ennyit, de még Linuxon sem.

    Na az AI kb. ugyanez turbózva. Van, amikor eszébe jut ilyesmi, van, amikor nem.







  • LordAthis

    csendes tag

    Miközben a cikket írtam, jött egy újabb hozzászólás ide: Az előző cikk hozzászólásai.

    Erre a hozzászólásra válaszolok:

    Igyekszem akkor szép sorban megválaszolni a felvetéseidet:

    - Ezt mondjuk még meg is értem, és tiszteletben tartom, hogy miért tartod vissza a konkrétumokat:
    "nem elsődlegesen magyar célközönségnek, ahol mondjuk 'XY' példa esetén nem beazonosítható, hogy ki vagyok."
    Bár a friss ACC ettől függetlenül is furcsa. :U

    - Az anonimitás és a cégek "b.sztatásának" elkerülése szintén jogos szempont.
    Azonban konkrét példák nélkül is lehetne olyan eseteket hozni, amelyek szakmai mélységet mutatnak anélkül, hogy bárkit beazonosítanának. Nem kell pont egy adott cég pontos forráskódját leírni hozzá, sem egy-egy hibajelenséget túlságosan mélységeiben.
    (Nem mellesleg nem esek hasra igen sok multinál dolgozó programozó munkájától. Így pl ha az M$ munkásságát nézem, és az eredményeket...
    ..de ezt tényleg hagyjuk, pereskedni egyikünk sem akar.)

    - "Előítéletekre építesz"
    Szerintem konkrét példákat írtam, pont Tőled kértem, hogy prekoncepciók helyett mutass példákat. :DDD

    - "Két AI által összeszögelt kusza blogposzt nem tesz szakértővé a témában"
    Egyenlőre nem tartom magam szakértőnek, mintha írtam is volna, hogy tanulás az egyik cél, éppen az, hogy a gyakorlati tapasztalatok megosztásával fejlődjek...
    ..a kusza jelzőért is köszi, nem vagyok újságíró sem.
    Ezektől függetlenül lehet ez szakmai cikk. Lett légyen az akár kusza, és összeszedetlen is szerinted.

    - "Nem lehülyéztelek"
    Ezt viszont nem is állítottam! A kettő nem ugyanaz. (Az "Az AI kódolás hülyeség", vagy a "Hülye vagy!" két különböző állítás.) :D
    A "pet project vs. üzleti cél" felvetésed jogos (Szerintem írtam is az egyik, vagy mindkét cikkben), nálam jelenleg a tanulás és a kísérletezés a fő motiváció, de hosszú távon üzleti cél is van. Ebből adódóan az AI-t arra használom, hogy gyorsítsam a prototipizálást, még ha nem is tökéletes az eredmény. Konkrét példák (akár absztraktabb formában) nagyon hasznosak lennének a tanácsaid alátámasztására!

    - "hanem segíteni próbáltam."
    Ezt kértem, az igazi segítség a példa, példák. :DDD :DD

    - Ez mondjuk fura:
    "(elolvastam - nem volt belinkelve, de megtaláltam)"
    Leginkább a nem volt belinkelve része fura, mivel a témaindító Cikkre jött létre a fórum, amire írsz-írtál.

    - A 4.-es, 6.-os pontodra:
    Teljesen egyetértek, hogy az ingyenes AI modellek sokszor nem alkalmasak komplex refaktorálási feladatok tesztelésére. Az általad említett költség-összehasonlítás és előfizetési problémák is valósak – én is tapasztaltam, hogy a tokenlimit és a modell korlátai gyorsan falhoz vezetnek. Az új cikkemben (amit belinkeltem) próbáltam részletesebben körüljárni ezeket a kérdéseket, kíváncsi vagyok a véleményedre.
    Egyetértek, hogy a rendszertervezés kulcsfontosságú, és nem feltétlenül a kódolás mélysége a szűk keresztmetszet. Az én tapasztalatom is az, hogy az AI-val való munka során a pontos specifikáció és a rendszertervezési logika megértése a legnagyobb kihívás. Az általad említett "gap" a természetes nyelv és az AI értelmezése között valóban létezik, és sokszor csak iteratív próbálkozásokkal lehet áthidalni.
    Az új cikket ITT találod meg.

    - Az 5.-ös pontodra:
    A Fekete humor és AI korlátai: A körkörös érvelés és az AI "eredeti kiindulási pontra" való visszatérése tényleg frusztráló, és nagyon találó a fekete humor párhuzam! A kameramodulos példád tökéletesen mutatja, hogy az AI sokszor nem képes az emberi gondolkodás rugalmasságát követni, és "hekkelni" kell a promptokat. Ha van konkrét tipped arra, hogyan lehet hatékonyabban megkerülni ezeket a korlátokat, szívesen kipróbálnám. Például milyen konkrét lépésekkel vezettél végig egy problémát (pl. hogyan strukturáltad a promptokat, milyen iterációkat végeztél).

    - "Feltételezed, hogy komoly programozó kell a feladatokhoz"
    Mondjuk ez pont nem igaz rám. :DD
    Alap programozói tudással, de 25 éves informatikai tapasztalattal, átfogó képpel AI segítségével olyan dolgokat csinálok, amiket jól megfizetett programozó sem csinált meg nekem!
    Akár azt is mondhatnám, hogy lelépett a pénzemmel.

    Igazából az a furcsa, hogy pontosan el tudtam Neki mondani, hogy mit kérek, mert ennyire megy a programozás, az is, hogy hogyan valósítsuk meg, aztán mégsem lett belőle semmi.
    Arra is felhívtam a figyelmét, hogy nekem nem egy kirakat (Frontend) kell, működő belső (BackEnd) nélkül, és pontosan hol vannak a hibák.
    Ezeken most AI-al pár óra alatt túl is jutunk, míg a programozónak (egészen pontosan a végén csapatot említett, szerintem kiadta kis indiaiaknak.... :DDD ) hónapok alatt sem sikerült, 5, vagy 6 online Meeting és 4 személyes találkozó után sem.
    Pedig még csoportos Meeting is volt, időközben felvett vmi projekt menedzsert, mert állítólag nem győzte a munkát.

    - 7.-es pont:
    Ai és AI között is van különbség. Sajnos egyre jobban összekeverednek az elnevezések, szerintem messze vagyunk még attól, amit eredetileg az AI kifejezés jelentett, csak ezzel adható el a fejlődés, hogy megelőlegezik, ami még nem...
    Egyszerűen matematika és valószínűség a legtöbb, főleg az LLM-ek.
    Persze folyamatosan csiszolnak rajtuk, de a lényeget leírtad, ahogy számtalanszor (Nem itt) már én is!
    Nem érti amit kérdezel, a válaszát sem, csak valószínűségeket köp vissza, kontextusba, témakörbe helyezve. Ez egybevág azzal, amit a szakirodalom is mond: az LLM-ek statisztikai modellek, amelyek nem "értenek", csak mintákat követnek.

    Egy kifejezetten kódolásra írt AI még hülyébb beszélgetésben, de lényegesen jobban kódol, mint egy beszélgetős. Ezek a képességek erősen képzés specifikusak! (Mint az embereknél is.) A beszélgetős modellek (pl. ChatGPT) gyakran csak "elfogadható" kódot adnak, amit - ahogy írtad: - "utólag szögelni kell".

    AI hibázásának okai gyakran a kontextus megértésének hiánya és a memóriaproblémák, ezek tökéletesen leírják az LLM-ek jelenlegi korlátait.
    A te példád (kameramodul keresése) és az én tapasztalataim is azt mutatják, hogy az AI sokszor csak "valószínűségi szöveggenerálást" végez, nem pedig valódi problémamegoldást. Az általad említett "átlagtól eltérő gondolkodási sémák" kezelése valóban gyenge pont, és itt az emberi kreativitás még mindig verhetetlen. A "token-alapú memóriakorlát" téma is érdekes, még vissza fogok térni rá, mert a saját gépen futtatott modellek esetén a hardver erőforrások (CPU, RAM, VRAM) és a modell optimalizálása jelentősen befolyásolhatja a teljesítményt.

    Tudnál egy konkrét, de anonimizált példát hozni arra, hogyan "hekkelted meg" az AI-t egy komplex feladat megoldására? Ez nagyon hasznos lenne a további tanuláshoz, és szerintem másokat is érdekelne! (A cikk-sorozat egyik célja, hogy ilyen használható ficsőröket összeszedjünk.)
    Az AI-val való hatékony munka kulcsa gyakran az, hogy a promptokat kreatívan, lépésről lépésre kell megfogalmazni, és sokszor teljesen más megközelítést kell választani. Mint ahogy Te is írod: mást, "mint amit egy emberi fejlesztőnek mondanál".

    A "token-alapú memóriakorlát" téma is érdekes, még vissza fogok térni rá. Arról is lesz egy külön cikk, mivel érinti a sorozat témáját, szervesen kapcsolódik hozzá!

Még van hozzászólás! Tovább