SAP-RPT-1-OSS: Tuning Guide — Context Size, Bagging & Best Practices

SAP-RPT-1-OSS: Tuning Guide

Jak nastavit max_context_size a bagging pro optimalni vysledky.

Jak model funguje

SAP-RPT-1-OSS je tabulkovy foundation model. Na rozdil od klasickeho ML netrenujes model — posles mu treninková data jako "kontext" a on na jejich zaklade predikuje. Funguje podobne jako LLM, ale pro tabulky.

Dva klicove parametry urcuji kvalitu a rychlost predikce:

Parametr	Co dela	Rozsah	Default
`max_context_size`	Kolik radku treninkovych dat model "vidi"	1 - 8192	2048
`bagging`	Kolikrat model predikuje a zprumeruje vysledek	1 - 16	2

max_context_size

Princip

Model ma "kontextove okno", do ktereho se vejde urcity pocet treninkovych radku. Kazdy radek se interně prevede na tokeny (nazvy sloupcu + hodnoty), ktere model zpracuje.

Limit je v radcich, ale skutecna kapacita zavisi na poctu sloupcu.

Radek se 3 sloupci zabere malo tokenu. Radek se 100 sloupci zabere hodne tokenu. Se stejnym max_context_size tedy model spotrebuje vyrazne vic pameti, pokud maji data vic sloupcu.

3 sloupce  × 2048 radku = male tokenove zatizeni  → ~3 GB RAM
30 sloupcu × 2048 radku = stredni zatizeni         → ~4-5 GB RAM
100 sloupcu × 2048 radku = vysoke zatizeni          → muze zpusobit OOM

Vliv poctu sloupcu

Model pouziva nazvy sloupcu semanticky — pochopi, co "REVENUE" nebo "DELIVERY_DELAY_DAYS" znamena. Proto:

Pouzivej popisne nazvy — REVENUE je lepsi nez X1

Vybirej relevantni features — 10-50 sloupcu je optimalni rozmezi

Nepridavej vsechno — vic sloupcu = vetsi pamet na radek = mene radku se efektivne vejde

Jak vybrat

Treninkovych radku    Sloupcu     →  context_size
────────────────────────────────────────────────────
< 500                 10-50       →  1024
500 - 2000            10-50       →  2048
2000 - 5000           10-50       →  4096
5000+                 10-50       →  8192

Hodne sloupcu (50-100):
< 500                             →  512 - 1024
500 - 2000                        →  1024 - 2048
2000+                             →  2048 (sleduj pamet)

bagging

Princip

Bagging spousti model N-krat s jinym nahodnym vzorkem treninkovych dat a vysledky zprumeruje.

Kdy pomaha a kdy ne

Pomaha kdyz max_context_size < pocet_radku — kazda iterace vidi jina data.

Nepomuze kdyz max_context_size >= pocet_radku — vsechny iterace vidi stejna data, vysledky jsou identicke.

Jednoduchy test: Spust s bagging=1 a bagging=4. Pokud jsou vysledky stejne, bagging nema efekt.

Jak vybrat

context_size >= pocet_radku             →  1
pocet_radku ~ 2x context_size          →  2
pocet_radku ~ 4-8x context_size        →  4
pocet_radku > 10x context_size         →  8

Bagging skaluje linearně: bagging=4 trva ~4x dele nez bagging=1.

Rozhodovaci strom

1. Kolik radku a sloupcu?
   ├─ < 500 radku        → context=1024, bagging=1
   ├─ 500-2000           → context=2048, bagging=1-2
   ├─ 2000-5000
   │   ├─ Rychlost       → context=2048, bagging=2
   │   └─ Presnost       → context=4096, bagging=4
   └─ 5000+
       ├─ CPU            → context=2048, bagging=4
       └─ GPU 40GB+      → context=4096-8192, bagging=4-8

2. 50+ sloupcu? → Redukuj na 20-50 a sniz context o stupen

3. bagging=1 == bagging=4? → Data se vejdou, nech bagging=1

Hardware tabulka

Hardware	RAM	context_size	bagging	Sloupcu max
Laptop (CPU)	8 GB	1024-2048	1-2	~30
Server (CPU)	16 GB	2048-4096	2-4	~50
GPU 24 GB	24 GB	2048	2	~50
GPU 48 GB	48 GB	4096	4	~80
GPU 80 GB	80 GB	8192	8	100+

API nastaveni

Parametry max_context_size, bagging, n_jobs se nastavuji primo v JSON body requestu (POST /predict, /predict/batch) nebo jako query string (POST /predict/csv).

Kazda kombinace (task_type, context_size, bagging) vytvori samostatny cachovany model (~2 GB). Pro produkci pouzivej 1-2 konfigurace.

Kompletni API priklady: viz DEVELOPER_GUIDE.md