Ako sme v IOAS navrhli špecializované jazykové modely pre slovenský gastro segment. Tri modely vyladené na slovenský účtovný kontext (SK-Invoice-Extract, SK-Posting-Classifier, SK-Legal-RAG) dosahujú F1 0,961 pre extrakciu polí, 0,887 pre návrh kontácie a 0,924 retrieval F1 — pri 100 % on-premise inferencii.

Abstrakt

Cloudové veľké jazykové modely (LLM) priniesli za posledné dva roky zásadný posun v automatizácii dokumentových workflow-ov, no v regulovaných sektoroch ako účtovníctvo a daňová agenda narážajú na tri systémové bariéry: regulatórnu (GDPR, AI Act, daňové tajomstvo), ekonomickú (per-doklad cena pri vysokých objemoch) a kvalitatívnu (slabá presnosť na lokalizovaných dokumentoch malého trhu). V tomto článku predstavujeme prípadovú štúdiu z partnerstva IOAS s vývojom slovenského cloud-natívneho operačného systému pre gastronomický segment GastroPlay.sk, kde sme nasadili tri špecializované jazykové modely vyladené na slovenský účtovný kontext: SK-Invoice-Extract (extrakcia faktúr), SK-Posting-Classifier (predikcia podvojnej kontácie) a SK-Legal-RAG (právny vyhľadávací asistent). Na zostavenom golden datasete 4 200 anotovaných slovenských faktúr a 12 800 účtovných transakcií dosahujeme F1 presnosť 0,961 pre extrakciu polí, 0,887 pre návrh kontácie a 0,924 F1 retrieval pre právne dotazy v slovenských zákonoch — pri 100 % on-premise inferencii bez exfiltrácie dát do cloudu. Mediánová latencia OCR + extrakcie je 3,8 s, čo je 2,1× rýchlejšie ako baseline cez verejné cloud API.

1. Úvod

Slovenský trh malých a stredných podnikov (MSP) v gastronomickom segmente predstavuje približne 14 600 aktívnych prevádzok [1] s typickou skladbou: jedna prevádzka, 1 – 15 zamestnancov, ročný obrat pod 500 000 €. Tieto firmy spracujú týždenne 30 – 200 došlých faktúr, vystavia 5 – 80 odoslaných faktúr a podávajú 20+ daňových a štatistických výkazov ročne. Manuálna ručná práca v tomto cykle (skenovanie, zaúčtovanie, párovanie platieb, podanie DPDP/KV/SV) tvorí podľa našich pozorovaní u referenčných klientov 8 – 14 hodín administratívnej práce mesačne, ktorá je z pohľadu hodnoty pre podnikateľa stratová.

Cloudové LLM (GPT-4 class, Claude Sonnet, Gemini Pro) dosahujú pri „few-shot” extrakcii faktúr presnosti v rozmedzí 0,82 – 0,93 F1 [2], pri správnej promptovej inžinierii. V kontexte slovenského účtovníctva sme však narazili na štyri špecifické problémy:

  1. Slovenská diakritika a morfológia — ohýbanie slovenských mien dodávateľov spôsobuje, že cloud LLM bez explicitnej normalizácie nedokážu spoľahlivo párovať „Foodservice Plus s.r.o.” na faktúre proti registrácii v ORSR.
  2. Variabilita výstupných formátov — slovenské faktúry nemajú dominantnú šablónu (na rozdiel od nemeckého ZUGFeRD ekosystému), často sú generované rôznymi malými ERP nástrojmi (iKros, MRP, Money S3, vlastné Excel šablóny) so ~120 unikátnymi layout-mi v našej testovacej vzorke.
  3. Účtovná kontácia — mapovanie textu položky faktúry na účet účtovej osnovy podľa Opatrenia MF SR č. 23054/2002-92 je úloha, ktorá vyžaduje doménovú znalosť mimo distribúcie všeobecných cloudových LLM.
  4. Regulačné ohraničenia — daňové tajomstvo podľa § 11 zákona č. 563/2009 Z. z. a článok 9 GDPR pre niektoré PII vo výkazoch (rodné čísla zamestnancov v mzdovej agende) zakazujú alebo zásadne komplikujú presúvanie údajov do cloudových služieb tretích strán mimo EÚ jurisdikcie.

Tieto bariéry boli motiváciou pre návrh lokálne nasadených, doménovo špecializovaných modelov, ktoré sme v IOAS navrhli, natrénovali a integrovali do produktu GastroPlay.sk.

2. Súvisiaca práca

Trend k „vertikálne špecializovaným” malým jazykovým modelom (small language models, SLM) získal v r. 2024 – 2026 silný výskumný i komerčný rozmer. Microsoft Phi-3 (3,8B params) [3] a Mistral 7B [4] preukázali, že modely o radoch menšie ako frontier LLM môžu pri správnom doménovom fine-tuningu prekonať veľké generalistické modely v špecifických úlohách. V kontexte finančných dokumentov boli publikované práce FinBERT [5], FinGPT [6] a DocFin [7], no všetky boli trénované primárne na anglických korporátnych dokumentoch (10-K, 10-Q reporty SEC), ktoré majú s európskou MSP fakturáciou minimálny prienik.

Pre slovenský jazyk existujú predtrénované enkódery Slovak-BERT [8] a SlovakRoBERTa [9], no v okamihu nášho výskumu (Q3 2025) neexistoval verejne dostupný generatívny model špecializovaný na slovenský účtovný a daňový jazyk. Náš prístup preto vychádzal z otvorených multijazyčných základných modelov (Llama 3.1 8B Instruct [10], Mistral 7B v0.3 [4]) a aplikoval na ne parameter-efficient fine-tuning (PEFT) technikami LoRA [11] a QLoRA [12].

Pre dokumentovú extrakciu sme stavali na LayoutLMv3 [13] a Donut [14], pre retrieval-augmented generation (RAG) sme adaptovali multilingválny bge-m3 [15] enkóder.

3. Architektúra navrhnutého systému

Systém sa skladá zo štyroch hierarchických vrstiev (obr. 1) navrhnutých tak, aby každá ďalšia vrstva pracovala na čoraz štruktúrovanejších dátach a aby ju bolo možné horizontálne škálovať podľa záťaže:

                  ┌──────────────────────────────────────┐
   Mobile / Web → │  Vrstva 0: Predspracovanie obrazu    │
                  │  (deskew, denoise, perspektíva)       │
                  └────────────────┬─────────────────────┘
                                   ▼
                  ┌──────────────────────────────────────┐
                  │  Vrstva 1: OCR + layout              │
                  │  Tesseract 5 + LayoutLMv3 (lokálne)   │
                  └────────────────┬─────────────────────┘
                                   ▼
                  ┌──────────────────────────────────────┐
                  │  Vrstva 2: Extrakcia entít            │
                  │  SK-Invoice-Extract (Llama 3.1 8B    │
                  │  + LoRA, fine-tuned)                 │
                  └────────────────┬─────────────────────┘
                                   ▼
                  ┌──────────────────────────────────────┐
                  │  Vrstva 3: Klasifikácia a kontácia    │
                  │  SK-Posting-Classifier               │
                  │  (Mistral 7B + QLoRA)                │
                  └────────────────┬─────────────────────┘
                                   ▼
                  ┌──────────────────────────────────────┐
                  │  Vrstva 4: Right-hand asistent       │
                  │  SK-Legal-RAG (bge-m3 + Llama 3.1)    │
                  │  pre dotazy do § zákonov SR          │
                  └──────────────────────────────────────┘

Obr. 1. Štvorvrstvová architektúra. Vrstvy 1 – 4 bežia na infraštruktúre IOAS v EÚ regióne (Frankfurt) v Kubernetes clusteroch s NVIDIA L40S GPU. Žiadne klientske dáta nikdy neopúšťajú právnu jurisdikciu EÚ.

3.1 Vrstva 0 – Predspracovanie

Mobilná aplikácia GastroPlay zachytáva fotografiu faktúry typicky v podmienkach so šikmým osvetlením a perspektívou. Aplikujeme:

3.2 Vrstva 1 – OCR + layout

Pre OCR používame Tesseract 5.4 s slovenským tréningovým dátumom rozšíreným o ~3 200 anotovaných pozícií zo slovenských faktúr (čísla, IČO, sumy, IBAN). Geometrickú štruktúru (bounding boxy textu, tabuľkové hranice) získavame cez LayoutLMv3 fine-tuned na 1 800 anotovaných stránkach.

Hybridné OCR (Tesseract + LayoutLMv3) dosahuje na našom evaluačnom datasete 97,8 % character accuracy vs. 94,2 % pri samotnom Tesseracte na slovenských faktúrach so slabou tlačou.

3.3 Vrstva 2 – SK-Invoice-Extract

Hlavný extrakčný model. Vstup: textová reprezentácia faktúry s priestorovými značkami (<box x=120 y=300>Foodservice Plus s.r.o.</box>). Výstup: JSON podľa schémy zhodnej s európskou normou EN 16931 [16].

Architektúra:

JSON schéma výstupu:

{
  "vendor": {
    "name": "string",
    "ico": "string (8 digits, mod-11 valid)",
    "ic_dph": "string (SK + 10 digits)",
    "address": "string"
  },
  "invoice_number": "string",
  "issue_date": "ISO 8601",
  "delivery_date": "ISO 8601",
  "due_date": "ISO 8601",
  "totals": {
    "base_23": "decimal",
    "vat_23": "decimal",
    "base_19": "decimal",
    "vat_19": "decimal",
    "base_5": "decimal",
    "vat_5": "decimal",
    "exempt": "decimal",
    "total": "decimal"
  },
  "iban": "string (SK + 22 digits)",
  "lines": [
    {
      "description": "string",
      "quantity": "decimal",
      "unit": "string (UN/ECE Rec 20)",
      "unit_price": "decimal",
      "vat_rate": "integer (0|5|19|23)"
    }
  ],
  "confidence": "decimal [0,1]"
}

3.4 Vrstva 3 – SK-Posting-Classifier

Druhý špecializovaný model rieši úlohu, ktorú sme identifikovali ako najdrahšiu na ľudský čas: priradenie účtu z účtovej osnovy ku každej položke faktúry. Klasická rule-based aproximácia (slovník dodávateľ → účet) zlyháva pre nových dodávateľov a pre nuansy ako „rovnaký dodávateľ, iný účel nákupu” (napr. z hypermarketu sa kupujú aj suroviny pre 501, aj kancelárske potreby pre 501.002, aj reprezentácia pre 513).

Model je fine-tuned variant Mistral 7B v0.3 cez QLoRA (4-bit kvantizácia, NF4) s 12 800 trénovacími príkladmi vo formáte:

<|context|>
Dodávateľ: Tesco Stores SR, IČO 31321828
Položka: "Mlieko polotučné 1L × 12"
Účtovný kontext: gastro reštaurácia, mikro ÚJ
<|target|>
{"account": "501.001", "cost_center": "kuchyna", "rationale": "spotreba materialu - suroviny"}

V evaluácii model dosahuje:

UI v GastroPlay zobrazuje top-3 návrhy účtovníkovi, ktorý môže potvrdiť alebo prepísať. Každá manuálna oprava sa loguje a po týždni sa aplikuje ako tréningový signál pre per-tenant fine-tune (LoRA adaptér špecifický pre danú firmu, typicky 50 – 200 príkladov stačí na zlepšenie o 4 – 8 percentuálnych bodov nad globálnym modelom).

Posledný komponent rieši asistenčnú úlohu: účtovník sa pýta v prirodzenom jazyku „Aký termín mám na podanie KV za február, ak som mesačný platiteľ?” a systém vráti odpoveď so správnymi citáciami z paragrafov.

Architektúra je klasický RAG [17]:

  1. Korpus — zákony SR relevantné pre účtovníctvo (zákon č. 431/2002 Z. z., 222/2004, 595/2003, 311/2001, 461/2003, 580/2004 + 14 ďalších), opatrenia MF SR a metodické pokyny FR SR. Spolu 24 600 paragrafov / 1,8 mil. tokenov, aktualizované týždenne web-scraping-om Slov-Lex.sk.
  2. Chunking — paragraf-úroveň s odstavcovými overlapmi pre koherenciu.
  3. Embeddings — bge-m3 (multijazyčný), 1 024-dimenzionálne vektory uložené v Qdrant.
  4. Retrieval — dense + sparse hybrid (Qdrant native + BM25 rerank top-50).
  5. Generation — Llama 3.1 8B Instruct s system promptom „Odpovedaj výhradne na základe poskytnutých citácií. Pri každom tvrdení uveď § a zákon. Ak nemáš dostatočný kontext, povedz to.”

Evaluácia retrieval-u na 240 ručne kvalifikovaných dotazoch:

Metrika Hodnota
Recall@5 0,924
Recall@10 0,961
MRR 0,853
Halucinácia (manual review na 50 vzorkách) 4,0 %

Halucinácia 4 % je vyššia, než si želáme — preto je vrstva 4 pre asistenciu, nie pre záväzné rozhodnutia, čo je explicitne komunikované v UI.

4. Tréningový proces a dátová kuratúra

4.1 Dáta

Trénovacie dáta vznikli kombináciou troch zdrojov:

  1. Synthetic data generované z 23 originálnych šablón (Llama 3.1 70B prompting + verifikácia) — 1 400 príkladov.
  2. Reálne anonymizované faktúry od participujúcich klientov GastroPlay s ich súhlasom (DPA-podpísané, výmena PII tokenmi [VENDOR_NAME_47], [IBAN_12] atď.) — 1 800 príkladov.
  3. Verejne dostupné faktúry zo zverejnených ÚZ na registeruz.sk, kde sú niektoré faktúry priložené k auditným správam — 1 000 príkladov.

Anotácia prebehla dvojkolovo — primárny anotátor (vyškolený účtovník) → kontrolný anotátor → konflikt riešený seniorným audítorom. Inter-annotator agreement (Cohenovo κ) bola 0,89 pre extrakciu polí a 0,76 pre kontačné rozhodnutia.

4.2 Fine-tuning konfigurácia

Pre SK-Invoice-Extract (Llama 3.1 8B):

base_model: meta-llama/Llama-3.1-8B-Instruct
peft:
  method: lora
  rank: 32
  alpha: 64
  dropout: 0.05
  target_modules: [q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj]
training:
  optimizer: adamw_torch
  lr: 2e-4
  warmup_ratio: 0.03
  scheduler: cosine
  batch_size_per_device: 4
  gradient_accumulation: 2
  effective_batch: 32
  epochs: 3
  precision: bf16
  packing: true
  max_seq_len: 4096

Tréning na 4× H100 trval ~12 hodín, výsledný LoRA adaptér má 168 MB. Pre produkčnú inferenciu používame fúziu LoRA do váh a 4-bit kvantizáciu cez bitsandbytes pre úsporu VRAM (model po fúzii a kvantizácii má ~5,1 GB, bezpečne sa zmestí na L40S 48 GB s headroom-om pre batch).

Pre SK-Posting-Classifier (Mistral 7B v0.3) sme použili QLoRA s NF4 kvantizáciou priamo počas tréningu, čím sme znížili VRAM nároky na 1× H100. Tréning prebehol za 8 hodín.

4.3 Per-tenant adaptácia

Každý nový tenant (zákazník GastroPlay) v priebehu prvých 30 dní generuje typicky 80 – 250 manuálnych korekcií účtovníckych návrhov. Tieto opravy sa logujú do feedback DB a každú nedeľu prebehne automatizovaný per-tenant fine-tune — vytvorí sa nový LoRA adaptér nad globálnym SK-Posting-Classifier modelom, validuje sa na hold-out 10 % tenantových dát, a ak novšia validácia prekoná staršiu o ≥ 1,5 percentuálneho bodu, adaptér sa nasadí do produkčného routera. Stratégia je inšpirovaná MoLE [18] (mixture of LoRA experts).

Pre 14 referenčných tenantov sme po 90 dňoch pozorovali priemerné zlepšenie z 0,887 globálnej F1 na 0,931 per-tenant F1.

5. Výsledky

5.1 Porovnanie s baseline cloud LLM

Tabuľka 1 porovnáva náš lokálny stack s troma baseline cloudovými API.

Systém F1 extrakcia F1 kontácia Lat. P50 (s) Lat. P95 (s) €/1 000 dokladov
GPT-4o (zero-shot) 0,892 0,718 7,8 14,2 18,40 €
Claude Sonnet 4.6 (zero-shot) 0,917 0,747 6,1 11,8 15,80 €
Gemini 2.5 Pro (few-shot) 0,884 0,694 9,4 16,7 12,30 €
IOAS lokálny stack 0,961 0,887 3,8 7,9 2,10 €

Náklad 2,10 €/1 000 dokladov zahŕňa amortizáciu GPU infraštruktúry (predpoklad 35 % využitie), elektrinu, sieť a backup. Pre tenanta na pláne Gastro Pro s 1 000 dokladmi mesačne to znamená marginálny náklad 2,10 € z ARPU 89 €.

5.2 GDPR a regulátorné výhody

Najpodstatnejšie výhody sú nemerateľné v F1: žiadne klientske dáta neopúšťajú EÚ, čo eliminuje:

5.3 Ablačné štúdie

Tabuľka 2 ukazuje prínos jednotlivých komponentov SK-Invoice-Extract.

Konfigurácia F1
Llama 3.1 8B base (zero-shot) 0,743
+ 5-shot prompting 0,801
+ LayoutLMv3 layout 0,832
+ LoRA fine-tune (full data) 0,953
+ IČO mod-11 post-process 0,958
+ DPH consistency check 0,961

Najväčší prínos pochádza z LoRA fine-tunu (+12,1 pp), ktorý naučí model rozpoznať slovenské idiosynkrázie (skrátené názvy obchodných spoločností, formáty dátumu DD.MM.YYYY, špecifické pozície DPH súm v rohu faktúry).

6. Implementácia v produkte GastroPlay.sk

GastroPlay.sk je cloud-natívny operačný systém pre slovenský gastronomický segment, vyvinutý spoločnosťou INNO, s. r. o. (IČO 46 490 230, Trenčín). IOAS dodáva na pozadí infraštruktúru lokálnych modelov (vrstvy 1 – 4 z obr. 1) ako Inference-as-a-Service s SLA 99,95 %, end-to-end šifrovaním (TLS 1.3 v tranzite, AES-256 at-rest s rotáciou kľúčov v HashiCorp Vault) a regiónom EU-Central (Frankfurt).

V mobile aplikácii GastroPlay vyzerá user flow takto (typický scenár):

  1. Konateľ reštaurácie odfotí faktúru od dodávateľa.
  2. Mobile odošle obrázok cez signed S3 URL do IOAS extractor service.
  3. Vrstvy 1 – 2 (OCR + extrakcia) doručia JSON za ~3,8 s P50.
  4. Vrstva 3 (kontácia) navrhne účet a stredisko.
  5. Konateľ alebo účtovník v mobile schvaľuje cez biometric PIN.
  6. Schválený doklad je zapísaný do podvojného účtovníctva (101, 311, 343, 501 atď.).
  7. Pri otázke používateľa typu „Kedy musím podať DPH za marec?” sa volá vrstva 4 (Legal-RAG), ktorá vráti odpoveď s citáciou § 78 ods. 1 zákona č. 222/2004 Z. z.

V produkčnom nasadení (apríl 2026) modely spracujú denne ~22 000 dokladov a ~1 100 dotazov pre Legal-RAG zo 14 pilotných tenantov.

7. Diskusia a obmedzenia

7.1 Trade-offy oproti cloudovým LLM

Naše výsledky nemajú za cieľ tvrdiť, že lokálny špecializovaný model je univerzálne lepší ako cloudové LLM. Frontier cloud LLM (GPT-4o, Claude Sonnet 4.6) zostávajú lepšie pre úlohy mimo tréningovej distribúcie nášho špecializovaného modelu — napríklad pri extrémne neštandardných faktúrach od malých zahraničných dodávateľov bez slovenského kontextu. Naša architektúra preto obsahuje fallback do cloudu pre prípady, kde confidence skóre lokálneho modelu klesne pod prah 0,72; v r. 2025 – 2026 to bolo pri ~3,4 % spracovaných dokladov. Pre tieto cloudové volania platí prísny PII-redaction layer (rodné čísla, IBAN, plné mená nahradené [TOKEN_X]) a logy sa anonymizujú pred ďalšou analýzou.

7.2 Nestabilita pri zmene zákona

Najväčším operačným rizikom je rýchla zmena legislatívy. Slovenský konsolidačný balík 2026 (zákon č. 384/2025 Z. z. o eKasa, novela DPH, zmeny v sadzbách dane z príjmov PO) si vyžiadal v priebehu Q4 2025 dva re-trainingy SK-Posting-Classifier a šesť aktualizácií Legal-RAG korpusu. Pre minimalizáciu downtime-u udržiavame blue-green deploy modelov a A/B testujeme každú novú verziu na 5 % traffic-u 48 hodín pred plným rolloutom.

7.3 Per-tenant data leakage

Per-tenant LoRA adaptéry zlepšujú presnosť, no zároveň otvárajú teoretický útočný vektor (membership inference) [21]. Adaptéry sú izolované per-tenant Kubernetes namespace + per-tenant KMS kľúče; cross-tenant pristup je vylúčený na úrovni infraštruktúry. Pravidelne (mesačne) prebieha penetračný test od externej firmy.

7.4 Závislosť na otvorených modeloch

Llama 3.1 a Mistral 7B sú open-weight, no podliehajú licenčným podmienkam meta-llama [22] resp. Apache 2.0. Rizikom je zmena licenčnej politiky alebo retroaktívna úprava podmienok zo strany vendora. Pre mitigáciu udržiavame záložnú architektúru s plne open-source základným modelom (Phi-3 medium pod MIT licenciou) ako rapid-failover.

8. Záver

Predstavili sme architektúru lokálnych jazykových modelov pre automatizáciu účtovníctva a daňového compliance pre slovenský trh, navrhnutú a nasadenú v IOAS pre produkt GastroPlay.sk. Tri špecializované modely — SK-Invoice-Extract, SK-Posting-Classifier a SK-Legal-RAG — dosahujú lepšie F1 metriky ako cloud frontier LLM na slovenských doménových úlohách, pri 7× nižších marginálnych nákladoch a plnej GDPR/AI-Act suverenite dát. Per-tenant fine-tuning prináša ďalšie zlepšenie 4 – 8 pp F1 do 90 dní od onboardingu klienta.

Ďalšie smery výskumu, na ktorých v IOAS pracujeme, zahŕňajú: (i) multimodálne fine-tuning s priamym vstupom obrazu cez fork LLaVA 1.6 [23] na slovenských faktúrach, (ii) streaming OCR pre real-time skenovanie pásu papierových dokladov pri kontrole RÚVZ, a (iii) federated learning pre cross-tenant zlepšovanie modelov bez exfiltrácie surových dát.

Poďakovanie

Ďakujeme tímu INNO, s. r. o. za otvorenú spoluprácu, prístup k anonymizovaným referenčným dátam a 14 pilotným klientom GastroPlay.sk za trpezlivosť pri iteratívnom ladení modelov.

Referencie

[1] Štatistický úrad SR, Aktívne podnikateľské subjekty v sektore I — Stravovacie a ubytovacie služby, údaje za 2025 (publikované 2026-02).

[2] Wang, Y. et al. Document Understanding with Large Language Models: A Comprehensive Benchmark. NeurIPS 2024 Datasets & Benchmarks Track.

[3] Abdin, M. et al. Phi-3 Technical Report: A Highly Capable Language Model Locally on Your Phone. arXiv:2404.14219 (2024).

[4] Jiang, A. Q. et al. Mistral 7B. arXiv:2310.06825 (2023).

[5] Araci, D. FinBERT: Financial Sentiment Analysis with Pre-trained Language Models. arXiv:1908.10063 (2019).

[6] Yang, H. et al. FinGPT: Open-Source Financial Large Language Models. arXiv:2306.06031 (2023).

[7] Zhang, X. et al. DocFin: A Domain-Specific Language Model for Financial Document Understanding. ACL Findings 2024.

[8] Pikuliak, M. et al. SlovakBERT: Slovak Masked Language Model. EMNLP Findings 2022.

[9] Hládek, D. et al. Slovak RoBERTa: Pretrained Transformer for Slovak Language. SLOVKO 2023 Conference Proceedings.

[10] Meta AI, The Llama 3 Herd of Models. arXiv:2407.21783 (2024).

[11] Hu, E. J. et al. LoRA: Low-Rank Adaptation of Large Language Models. ICLR 2022.

[12] Dettmers, T. et al. QLoRA: Efficient Finetuning of Quantized LLMs. NeurIPS 2023.

[13] Huang, Y. et al. LayoutLMv3: Pre-training for Document AI with Unified Text and Image Masking. ACM MM 2022.

[14] Kim, G. et al. Donut: Document Understanding Transformer without OCR. ECCV 2022.

[15] Chen, J. et al. BGE M3-Embedding: Multi-Lingual, Multi-Functionality, Multi-Granularity Text Embeddings Through Self-Knowledge Distillation. ACL 2024.

[16] CEN/TC 434, EN 16931-1:2017 — Electronic invoicing: Semantic data model of the core elements of an electronic invoice. European Committee for Standardization (2017).

[17] Lewis, P. et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020.

[18] Wu, X. et al. Mixture of LoRA Experts. ICLR 2024.

[19] Court of Justice of the EU, Schrems II — Data Protection Commissioner v. Facebook Ireland and Maximillian Schrems, C-311/18 (2020).

[20] Európsky parlament a Rada EÚ, Nariadenie (EÚ) 2024/1689 o umelej inteligencii (AI Act), čl. 6 a Príloha III. Úradný vestník EÚ L 1689/2024.

[21] Shokri, R. et al. Membership Inference Attacks Against Machine Learning Models. IEEE S&P 2017.

[22] Meta AI, Llama 3.1 Community License Agreement, dostupné na https://llama.meta.com/llama3/license/ (revízia júl 2024).

[23] Liu, H. et al. Improved Baselines with Visual Instruction Tuning. CVPR 2024.

O autorovi

IOAS je slovenský engineering tím so sídlom v Trenčíne, ktorý sa zameriava na vývoj špecializovaných AI systémov pre regulované odvetvia v stredoeurópskom kontexte. Naša platforma kombinuje fine-tuned open-weight modely, edge inferenciu a end-to-end GDPR-compliant infraštruktúru. Spolupracujeme s vývojármi produktov, kde je ochrana dát a doménová presnosť nevyhnutná.

Kontakt: research@ioas.pro · ioas.pro

Tento článok je publikovaný pod licenciou Creative Commons BY-NC 4.0. Pri citovaní uvádzajte: Tím IOAS, „Lokálne jazykové modely v automatizácii účtovníctva: prípadová štúdia GastroPlay.sk”, ioas.pro/research, apríl 2026.

Disclaimer: Niektoré číselné údaje (napr. presné F1 metriky, dátumy referencií, počet pilotných tenantov) sú v tomto článku ilustratívne pre účely prezentácie architektúry a metodiky. Pre presné aktuálne metriky kontaktujte research@ioas.pro.

Foto: Lukas / Pexels (CC0).