New forensic evidence supports Egyptian "retainer sacrifice"

Osmnáct ze 46 zkoumaných egyptských lebek nese známky potenciálně smrtelného poranění z doby kolem smrti. Nová studie tím posiluje hypotézu, že někteří lidé museli doprovodit panovníka na onen svět násilně. Pro technologický blog zdánlivě zvláštní začátek. Jenže otázka, kterou nález otevírá, právě trápí také vývojáře umělé inteligence: odpovídá přesvědčivé vysvětlení skutečným důkazům?

Egyptské lebky varují: své AI nevěřte jen proto, že zní přesvědčivě

Bioarcheoložka Roselyn A. Campbellová z Purdueovy univerzity se vrátila k ostatkům z Abydu. Pocházejí z vedlejších pohřbů u královských pohřebních areálů první dynastie. Hypotéza obětování panovníkova doprovodu předpokládá usmrcení lidí, kteří měli vládci sloužit po smrti.

Výzkum popisuje poranění u 39 procent zkoumaných lebek. Vedle lineárních zlomenin zaznamenal také zásahy ostrým předmětem. Má však omezení: neúplné ostatky, poškození a konzervaci parafínem, která zakrývá některé znaky. Dochované lebky navíc představují jen část původních pohřbených. Původní studie ve Frontiers tedy podporuje hypotézu obětí. Nedokazuje okolnosti smrti každého jednotlivce.

Pro AI je na tom poučný způsob uvažování. Pozorování, interpretace a míra jistoty jsou tři různé věci. Když je asistent slije do jedné hladké odpovědi, čtenář snadno přehlédne, kde skončila data a začalo domýšlení.

Představme si zadání: „Shrň studii a řekni, zda potvrzuje lidské oběti.“ Dobrá odpověď musí zachovat omezení vzorku. Špatná vyrobí kategorický verdikt. Obě přitom mohou mít stejně úhledné odstavce.

Při práci s odborným textem proto požadujte u každého zásadního tvrzení konkrétní pasáž zdroje. Potom ji otevřete. Odkaz sám nic nezaručuje. Je to adresa, nikoli znalecký posudek.

Agent oznámil úspěch. Databáze měla jiný názor

Tento rozdíl dostal měřitelnou podobu v projektu ThinkingBox. Microsoft a Hugging Face představily testování 507 pracovních scénářů, opakovaných dvacetkrát. Hodnotí se výsledný stav systému a vedlejší účinky operací.

V jedné dílčí analýze zahrnující 121 680 platných pokusů napříč dvanácti modely neprošlo kontrolami 79 853 pokusů. Z těchto neúspěchů přesto 67,24 procenta skončilo bez závěrečné chyby nástroje a zahrnovalo volání měnící stav. Pozor na jmenovatel: jde o podíl mezi neúspěšnými pokusy, nikoli mezi všemi použitími AI. Podrobnosti uvádí původní příspěvek ThinkingBox.

Pro běžnou firmu z toho plyne praktický požadavek. „Faktura je zpracovaná“ musí znamenat něco ověřitelného: existuje příslušný záznam, odpovídá částka, sedí zákazník a nevznikl duplikát. Hezká zpráva v chatu účetnictví neopraví.

Zároveň není fér převést výsledek jednoho benchmarku na tvrzení, že každá AI selhává stejným tempem. Rozhoduje úloha, model, dostupné nástroje i kvalita integrace.

Při vlastním hodnocení sledujte dva ukazatele: kolik pokusů uspělo a kolik zadání prošlo všemi opakováními. Jednorázový úspěch ukazuje možnost. Opakovatelnost ukazuje provozní použitelnost. Ani dvacet úspěchů ovšem nezaručuje bezchybnou budoucnost. Demonstrace na poradě a automatizace pro tisíc zákazníků jsou prostě dvě různé disciplíny.

Apple řeší, kam až smí digitální pomocník sáhnout

Druhou polovinu problému tvoří oprávnění. Agent může udělat chybnou věc správně provedeným příkazem. Pak nepomůže, že všechny kontrolky svítí zeleně.

Apple 2. října 2026 oznámil chystané dodatečné kontroly pro úplný přístup k disku v macOS. Upozornil, že toto oprávnění umožňuje obejít značnou část běžných ochran soukromých dat. Výslovně spojil rostoucí riziko se schopnějšími a autonomnějšími AI agenty. Oznámení popisuje budoucí změnu; neuvádí konkrétní termín nasazení ani hotovou podobu ovládání. Vyjádření Applu proto nelze vydávat za ochranu, kterou už má každý Mac.

Při nastavování vlastního asistenta začněte seznamem potřebných dat. Má třídit faktury? Připravte mu složku s kopiemi faktur. Má analyzovat spotřebu? Předejte export měření. Přístup ke zprávám, historii prohlížení a soukromým dokumentům není přirozenou součástí takového zadání.

Rozlišujte také čtení a zápis. Analytický pomocník může navrhovat změny bez možnosti je provést. Pro zápis vytvořte samostatnou službu s úzkým rozhraním a kontrolou parametrů.

To není samoúčelná administrativa. Je to způsob, jak omezit následky omylu. Pověřit brigádníka inventurou také automaticky neznamená předat mu podpisové právo k firemnímu účtu.

Vlastní AI přes Ollamu: začněte malým modelem a malými právy

Pro první pokusy nemusíte kupovat server. Otevřenou alternativou je Ollama a lokálně spuštěný model. Například varianta `qwen3:8b` má podle katalogu Ollamy přibližně 8,19 miliardy parametrů. Nabízený soubor v kvantizaci Q4_K_M zabírá zhruba 5,2 GB a používá licenci Apache 2.0.

Po instalaci Ollamy můžete model stáhnout a spustit:

```bash ollama pull qwen3:8b ollama run qwen3:8b ```

Postup instalace pro svůj systém vezměte z oficiální dokumentace. Samotný chat ještě není agent s přístupem k souborům nebo databázi. Tyto schopnosti přidává až okolní aplikace a její nástroje.

Jako rozumný výchozí rozpočet paměti pro podobný experiment počítejte s počítačem se 16 GB RAM. Je to orientační doporučení, nikoli garantované minimum. Vedle vah modelu potřebujete prostor pro systém, kontext a pomocná data. Velikost staženého souboru tedy neodpovídá celkové spotřebě paměti. Rychlost na procesoru se navíc může výrazně lišit od běhu s grafickou akcelerací.

Zadejte nejprve krátký anonymizovaný dokument a ověřte deset konkrétních údajů. Datum, částku, jednotku, číslo smlouvy. Teprve potom přidávejte složitější úlohy.

Lokální provoz dává větší kontrolu nad cestou dat. Není však automatickou zárukou soukromí celé sestavy. Webové rozhraní, rozšíření nebo připojené nástroje mohou komunikovat ven. Posuzujte celý řetězec, ne pouze místo, kde běží model.

Kontrolu výsledku napište dřív než pochvalu do chatu

Pro vlastní automatizaci navrhuji jednoduché pravidlo: podmínky úspěchu definujte před spuštěním agenta. Kontrolní kód musí být mimo jeho možnost úprav.

Představme si testovací databázi s požadavky zákazníků. Agent má označit konkrétní požadavek jako čekající. Následující ukázka předpokládá existující databázi `pokus.db`, tabulku `pozadavky` a sloupce `id` a `stav`:

```python import sqlite3

with sqlite3.connect("file:pokus.db?mode=ro", uri=True) as spojeni: radek = spojeni.execute( "SELECT stav FROM pozadavky WHERE id = ?", (42,), ).fetchone()

if radek != ("čeká",): raise RuntimeError("Požadavek nemá očekávaný stav.") ```

Tohle je jen jedna kontrola, nikoli kompletní test. Přidejte ověření, že agent nezměnil jiné požadavky, nevytvořil duplicitní záznam a nezapsal chybnou částku. V izolovaném testu lze porovnat obsah databáze před úlohou a po ní. Každé opakování musí začínat stejným výchozím stavem.

V ostrém provozu je situace složitější, protože současně pracují další uživatelé. Tam potřebujete spojit změny s identifikátorem konkrétní operace. Samotný rozdíl celé databáze nestačí.

Zápisy v jedné databázi lze navrhnout transakčně. Odeslaný e-mail nebo příkaz externímu zařízení však databázový návrat změn neodvolá. Pro takové kroky potřebujete samostatné ověření a někdy nápravnou akci.

Také ošetřete opakované požadavky. Když se ztratí odpověď serveru, agent nesmí při opakování vystavit druhou fakturu. Jedinečný identifikátor operace je méně efektní než další model. Často ale užitečnější.

V energetice rozhoduje elektroměr, ne sebejistá odpověď

Energetika nabízí názorný příklad. Asistent oznámí, že posunul nabíjení baterie do levnějšího intervalu. Jenže co skutečně udělal? Vytvořil návrh? Uložil plán? Přijal ho střídač? Proběhlo nabíjení?

Tyto stavy musí aplikace rozlišovat. Pro kontrolu potřebujete skutečné měření a časové značky. Jedním z míst, kde začít zkoumat dostupné služby, je IoT monitoring SmartEnergyShare. Samotný monitoring však ještě nedokazuje, že konkrétní navržená AI integrace existuje nebo bezpečně ovládá zařízení.

Pro vstupní ceny lze sledovat přehled spotových cen SmartEnergyShare a porovnávat je s údaji denního trhu OTE. Při výpočtu důsledně kontrolujte jednotky: údaj v eurech za megawatthodinu není cenou v korunách za kilowatthodinu. K výsledku navíc patří podmínky konkrétního odběru.

Pro modelový výpočet vezměme přesun 10 kWh a cenový rozdíl 2 Kč/kWh. Hrubý rozdíl činí 20 Kč před ztrátami, opotřebením a dalšími náklady. Je to aritmetický příklad, nikoli slíbená denní úspora.

Při hledání využití ve firmě může posloužit nabídka [SmartEnergyShare pro firmy](https://smartenergyshare.com/pro-firmy?utm_source=smartenergyshare-info&utm_medium=referral&utm_campaign=satellite-marketing). Širší kontext nabízí také platforma pro sdílení elektřiny a tematický blog [ShareElectric.cz](https://shareelectric.cz). U konkrétní automatizace ale vždy požadujte popis datového propojení, odpovědnosti a způsobu ověření výsledků.

Kolik to stojí a proč LoRA neopraví všechno

Cena lokální AI začíná jinak než ceník cloudového předplatného. Pokud už vhodný počítač máte, nemusíte za tento pokus pořizovat nový hardware. Přesto platíte elektřinu, svůj čas a případnou správu.

Modelový výpočet: dodatečný příkon 100 W po dvě hodiny denně znamená za třicet dní 6 kWh. Při předpokládané ceně 6 Kč/kWh jde o 36 Kč. Stejných dodatečných 100 W nepřetržitě vychází na 72 kWh a 432 Kč měsíčně. Nejde o naměřenou spotřebu Qwenu ani aktuální nabídku dodavatele. Skutečný rozdíl ověřte zásuvkovým wattmetrem.

Náklady na práci mohou být vyšší. Dvě hodiny nastavování při vlastní kalkulační sazbě 800 Kč za hodinu znamenají 1 600 Kč ještě před první užitečnou odpovědí. Porovnávejte proto cenu správně dokončené úlohy včetně kontroly a oprav.

Pro specializaci modelu existuje LoRA. Umožňuje doškolovat menší přídavné matice místo všech parametrů; nástroje poskytuje například knihovna PEFT na Hugging Face. Může pomoci s formátem nebo odborným stylem. Nenahradí aktuální databázi, oprávnění ani kontrolu zápisu.

Začněte tento týden jedním úkolem, anonymizovanými daty a jednoznačným testem úspěchu. Změřte čas, chyby a cenu. Teprve potom přidávejte autonomii.

Moje předpověď? Nejcennější firemní AI nebude ta, která nejrychleji napíše „hotovo“. Bude to ta, u níž půjde za deset sekund zjistit, co přesně provedla.

Zdroje

Následující zdroje pokrývají původní výzkum, oznámení výrobce, měření agentů i energetické souvislosti. Praktické příklady a rozpočty v článku jsou vlastní návrhy a výpočty; nepředstavují výsledky těchto studií ani nabídky uvedených organizací.

• Frontiers: nové poznatky ze starých kostí v Abydu — původní odborná práce Roselyn A. Campbellové. Umožňuje ověřit povahu nálezu a především omezení, která při převodu vědeckého výsledku do novinového titulku snadno zaniknou.

• Apple: připravované změny úplného přístupu k disku — přímé oznámení výrobce z 2. října 2026. Pro posouzení změny oprávnění má větší váhu než komentáře, které zaměňují oznámený záměr za již vydanou funkci.

• Microsoft a Hugging Face: agent tvrdil, že dokončil práci, databáze nesouhlasila — původní vysvětlení projektu ThinkingBox. Při čtení procent je nutné sledovat rozsah konkrétní analýzy, jmenovatele a rozdíl mezi jedním úspěchem a opakovatelností.

• OTE: denní trh s elektřinou — český primární zdroj tržních údajů. Pro vlastní energetický experiment ukládejte vedle převzatých hodnot také datum, časový interval a jednotku, aby šel výpočet později reprodukovat.

• IEA: energie a umělá inteligence — širší mezinárodní kontext energetických nároků AI. Slouží k dalšímu čtení; nenahrazuje měření konkrétního domácího počítače a není podkladem modelových korunových rozpočtů uvedených v článku.

Obchodujete s batteriovými úložišti nebo hledáte partnera pro flexibilitu a day trading elektřiny? SmartEnergyShare nabízí kompletní řešení pro BESS projekty od 50 do 250 kW — obchodování flexibility, SVR služby a IoT monitoring. Zjistěte víc →

Další články na toto téma najdete na: Share-Electric.cz Vaše AI vyhrála benchmark. Bez těchto údajů to mnoho nezn... Vice o autosynthdata: generating