Záznam ze Vzdělávacího okénka HAVIT z 25. září 2025, kde jsem ukazoval třetí způsob AI-vytěžování dokumentů – prostřednictvím all-in-one cloudové služby Azure AI Content Understanding.
V předchozích dílech série jsme si ukázali dva přístupy k vytěžování dokumentů pomocí AI: konverzi do Markdown přes Azure Document Intelligence s následným zpracováním přes LLM a přímé zpracování bitmapových obrázků přes GPT-4o Vision. Tentokrát jsme se podívali na třetí cestu – Azure AI Content Understanding, která celý pipeline (OCR, analýza struktury, extrakce dat) zapouzdřuje do jedné cloudové služby.
Co se dozvíte
Co je Azure AI Content Understanding a čím se liší od Azure Document Intelligence
Jak službu nastavit a nakonfigurovat v Azure portálu
Praktická ukázka volání REST API z C#
Porovnání všech tří přístupů k AI-vytěžování dokumentů
Záznam ze Vzdělávacího okénka HAVIT z 11. září 2025, kde jsem ukazoval specificky techniku vytěžování s pomocí GPT-4o Vision (vstup ve formě bitmapových obrázků přímo předávaných LLM, bez mezipřistání v Markdown).
Co se dozvíte:
GPT Vision vs. Markdown přístup – kdy který použít a jaké jsou trade-offs
Resizing obrázků na straně klienta před odesláním do GPT (limit 2048×768 px)
C# implementace: JSON schéma pro přesnou extrakci strukturovaných dat
Multimodální vstup v .NET SDK – předávání image content parts
Reálné výsledky na lékařských zprávách a ukázka edge cases
Záznam z přednášky pro konferenci WUG Days Brno z 5.9.2025, kde jsem telegraficky představoval novinky z „.NET 9 vlny“ a pár přicházejících v „.NET 10 vlně“.
Záznam ze přednášky pro konferenci WUG Days Brno z 4. září 2025. Ukázka dvou implementací (POC) vytěžování dokumentů pomocí moderních AI technik:
Kombinace Azure Document Intelligence (s výstupem do Markdown) a LLM (OpenAI GPT-4o) pro efektivní vytěžování netriviálních dokumentů (zde přijatých faktur i s energetickými přílohami).
OpenAI GPT-4o v režimu Vision pro vytěžování údajů obrázků (fotografií zdravotních zpráv).
Záznam ze Vzdělávacího okénka HAVIT z 12. června 2025. Ukázka implementace (POC) vytěžování dokumentů pomocí moderních AI technik. Kombinace Azure Document Intelligence (s výstupem do Markdown) a LLM (OpenAI GPT-4o) pro efektivní vytěžování netriviálních dokumentů (zde přijatých faktur i s energetickými přílohami).
O čem přednáška je
Potřebujete z naskenovaných nebo PDF dokumentů dostat strukturovaná data? Tradiční OCR systémy (Kofax, EFlow, starší Azure Forms Recognizer) vyžadují trénování na konkrétních layoutech a ruční definici cílových polí. V této přednášce ukazuji modernější přístup – kombinaci dvou AI služeb, která zvládne i netriviální dokumenty bez předchozího trénování.
Azure Document Intelligence – konverze do Markdown
Prvním krokem je převod vstupního dokumentu (PDF, sken, fotografie) do strojově čitelné podoby. Azure Document Intelligence analyzuje layout dokumentu a výstupem je Markdown – čistý text se zachovanou strukturou tabulek, nadpisů a odstavců. Oproti klasickému OCR výstupu je Markdown ideálním vstupem pro LLM, protože zachovává kontext a vztahy mezi údaji.
OpenAI GPT-4o – extrakce strukturovaných dat
Markdown výstup z Document Intelligence předáváme OpenAI GPT-4o s promptem, který definuje cílovou strukturu JSON výstupu. Model díky function calling vrací přesně typovaný JSON se všemi požadovanými poli – číslo faktury, datum, dodavatel, položky, částky, měrné jednotky a další technické údaje.
Energetické faktury jako netriviální use case
Ukázka pracuje s reálným scénářem zákazníka – vytěžování přijatých energetických faktur. Tyto dokumenty obsahují desítky položek s různými měrnými jednotkami (kWh, MW, Kč/MWh), technické údaje jako činná a jalová složka, distribuční poplatky, rezervované kapacity a smluvní hodnoty. Výstupní JSON se zapisuje přes REST API do cílového systému, kde se jednotlivé řádky mapují na specifická pole včetně netypických zápisů (např. nulová jednotková cena pro technické údaje).
Implementace v .NET
Celý POC je implementován v C# / .NET s využitím Azure SDK pro Document Intelligence a OpenAI SDK pro komunikaci s GPT-4o. Přednáška zahrnuje praktické ukázky kódu, prompt engineering pro strukturovaný výstup a tipy pro nasazení v produkčním prostředí.
Narazili jsme po instalaci .NET 9 SDK 9.0.204 (a nepomohl ani 9.0.300) na zajímavou chybu published Blazor WebAssembly front-endů (browser console výstup, front-end nenabíhá):
ManagedError: AggregateException_ctor_DefaultMessage (Could not resolve type with token 01000024 from typeref (expected class 'System.Reflection.Assembly' in assembly 'netstandard, Version=2.1.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'))
at an (dotnet.runtime.5nhp1wfg9b.js:3:26894)
at Kt.resolve_or_reject (dotnet.runtime.5nhp1wfg9b.js:3:26449)
at dotnet.runtime.5nhp1wfg9b.js:3:172714
at dotnet.runtime.5nhp1wfg9b.js:3:172778
at fr (dotnet.runtime.5nhp1wfg9b.js:3:35046)
at Fc (dotnet.runtime.5nhp1wfg9b.js:3:172361)
at dotnet.native.swgexbmoy7.wasm:0x1f1a4
at dotnet.native.swgexbmoy7.wasm:0x1c8ae
at dotnet.native.swgexbmoy7.wasm:0xea19
at dotnet.native.swgexbmoy7.wasm:0x1ec88
První podezření bylo na trimming, nicméně když to zkrátím, tak se ukázalo, že se jedná o klasický problém buildů po instalaci nového SDK – je potřeba vymazat pracovní složky build-agentů, pokud každý váš build neběží na úplně čistém prostředí, ale používáte nějakou formu inkrementálního uspořádání. Když to převedu do roviny lokálního vývoje s Visual Studiem, je potřeba udělat Clean solution a vymazat složky bin a obj.
Proč to vůbec píšu? Kdyby někoho potkala stejná chyba, při troše štěstí vygooglí tento post a ušetří si čas s diagnostikou. U nás už jsme si poměrně zvykli, že když po instalaci nové verze SDK padá build, je potřeba před dalším bádáním vymazat pracovní složky build-agentů. Poprvé v historii se nám však stalo, že build úspěšně prošel (nepadal), ale výsledek build byl „vadný“ způsobem, který se projevil až při spuštění Blazor WASM front-endu v browseru.
HAVIT Knowledge Base 