From 3391400f1f373284bf77bbf50b7e681dddf8c0ec Mon Sep 17 00:00:00 2001 From: majkarol Date: Thu, 25 Jun 2026 15:49:45 +0200 Subject: [PATCH] zmiana nazwy pliku --- Koncepcja 0.2 - rozszerzona.md | 714 --------------------------------- Pytania do koncepcji.md | 86 +++- 2 files changed, 65 insertions(+), 735 deletions(-) delete mode 100644 Koncepcja 0.2 - rozszerzona.md diff --git a/Koncepcja 0.2 - rozszerzona.md b/Koncepcja 0.2 - rozszerzona.md deleted file mode 100644 index 1795dc9..0000000 --- a/Koncepcja 0.2 - rozszerzona.md +++ /dev/null @@ -1,714 +0,0 @@ -# AdReactions — Koncepcja platformy v0.2 (rozszerzona) - -> **Status dokumentu:** rozszerzenie i ujednolicenie „Koncepcja 0.1 [KM]". -> Łączy w spójną całość źródła projektu i dokłada warstwy, których w wersji 0.1 -> brakowało: model domenowy, mapowanie *cel biznesowy → metryki → usługi AI*, -> wymienialność modeli, propozycję modelu danych oraz jawne rozgraniczenie -> **zakresu MVP 1.0 od roadmapy**. -> -> Miejsca wymagające decyzji właściciela produktu oznaczono znacznikiem **[?]** -> i zebrano w osobnym pliku **`Pytania do koncepcji.md`**. - -## Źródła zintegrowane w tym dokumencie - -| Dokument | Co wnosi | -|---|---| -| `Koncepcja 0.1.md` | Produkt, role, moduły, UX, kreator eksperymentu, use case'y | -| `Opis celów analiz kognitywnych.md` | 15 celów biznesowych + mapowanie na metryki ET/FC | -| `Specyfikacja-procesu-AI.md` | Logika procesu AI: kontrakty usług, orkiestracja, model danych, roadmapa | -| `info.md` | Wymaganie: wymiana modelu AI na inny (np. Gemini, Opus) z poziomu panelu | - ---- - -## Spis treści - -1. [Streszczenie wykonawcze](#1-streszczenie-wykonawcze) -2. [Wizja produktu i propozycja wartości](#2-wizja-produktu-i-propozycja-wartości) -3. [Słownik pojęć (model domenowy)](#3-słownik-pojęć-model-domenowy) -4. [Architektura logiczna platformy](#4-architektura-logiczna-platformy) -5. [Organizacje, role i uprawnienia](#5-organizacje-role-i-uprawnienia) -6. [Moduły platformy](#6-moduły-platformy) -7. [Cykl życia eksperymentu (kreator 4 kroków)](#7-cykl-życia-eksperymentu-kreator-4-kroków) -8. [Katalog celów analiz kognitywnych](#8-katalog-celów-analiz-kognitywnych) -9. [Warstwa AI — proces analizy](#9-warstwa-ai--proces-analizy) -10. [Wymienialność modeli AI (Proces ↔ Model)](#10-wymienialność-modeli-ai-proces--model) -11. [Struktura i generowanie raportu](#11-struktura-i-generowanie-raportu) -12. [Propozycja modelu danych (Supabase)](#12-propozycja-modelu-danych-supabase) -13. [Kredyty, subskrypcje, przestrzeń dyskowa](#13-kredyty-subskrypcje-przestrzeń-dyskowa) -14. [Logi i audyt](#14-logi-i-audyt) -15. [Bezpieczeństwo, prywatność, zgodność](#15-bezpieczeństwo-prywatność-zgodność) -16. [Internacjonalizacja](#16-internacjonalizacja) -17. [Przepływy użytkownika (use case'y)](#17-przepływy-użytkownika-use-casey) -18. [Zakres MVP 1.0 vs roadmapa](#18-zakres-mvp-10-vs-roadmapa) - ---- - -## 1. Streszczenie wykonawcze - -**AdReactions** to aplikacja SaaS do **predykcyjnego badania percepcji i emocji** wobec -kreacji reklamowych - bez udziału realnych respondentów. Zamiast organizować kosztowne -badania eye-trackingowe na ludziach, użytkownik wgrywa kreację (reklamę, baner, opakowanie, ekran UI) i otrzymuje **syntetyczny eye-tracking** oraz **predykcję reakcji emocjonalnej** generowane przez modele AI, w tym autorski model **ASM PNS**. - -Cechą wyróżniającą produkt jest **odwrócenie perspektywy**: użytkownik nie konfiguruje metryk, tylko wybiera **cel biznesowy** („Która kreacja lepiej sprzedaje?", „Czy CTA działa?"), a system samodzielnie dobiera technologię analizy (Eye Tracking / Facial Coding / ET+FC), zestaw metryk i sposób interpretacji wyniku. Raport nie podaje surowych liczb, lecz **rekomendację z uzasadnieniem** („Wariant B lepiej realizuje cel sprzedażowy, ponieważ…"). - -**Zakres MVP 1.0:** platforma SaaS (organizacje, projekty, eksperymenty, galeria kreacji, raporty), kreator eksperymentu, panel administracyjny z **wymienialnymi modelami AI**, -oraz pipeline AI obejmujący detekcję obiektów i predykcję uwagi wzrokowej (trzy modele saliency z walidacją krzyżową). Facial Coding, wizualizacje czasowe i ścieżki fiksacji są zaplanowane jako kolejne, niezależne gałęzie pipeline'u (patrz §18). - ---- - -## 2. Wizja produktu i propozycja wartości - -### 2.1. Problem - -Klasyczne badania eye-trackingu i kodowania mimiki (facial coding) są drogie, czasochłonne -i wymagają rekrutacji respondentów oraz sprzętu. Decyzje o wyborze wariantu kreacji -zapadają więc często „na wyczucie", już po poniesieniu kosztów produkcji. - -### 2.2. Propozycja wartości - -- **Szybkość i koszt:** predykcja w minutach zamiast tygodni, bez respondentów. -- **Decyzyjność:** wynik prowadzi do konkretnej rekomendacji („wybierz B"), a nie tabeli liczb. -- **Porównywalność:** test A / AB / ABC pozwala zestawić warianty na jednej osi metryk. -- **Segmentacja:** predykcje dla zdefiniowanej grupy docelowej (demografia, profile, neuroatypowość). -- **Powtarzalność:** eksperyment można sklonować i zmodyfikować jako bazę kolejnego. - -### 2.3. Kluczowa innowacja: „cel zamiast metryk" - -To centralny mechanizm produktu (rozwinięty w §8). Pięć warstw od wyboru celu do rekomendacji: - -``` -[1] Użytkownik wybiera CEL BIZNESOWY np. „Która kreacja lepiej sprzedaje?" - │ -[2] System pokazuje OPIS POMOCNICZY „Sprawdź, który wariant prowadzi uwagę do CTA…" - │ -[3] System rekomenduje TYP ANALIZY ET+FC (z możliwością zmiany przez użytkownika) - │ -[4] System dobiera METRYKI „pod spodem" udział uwagi na CTA, Positive Valence, … - │ -[5] Raport zwraca REKOMENDACJĘ Z UZASADNIENIEM „Wariant B…, ponieważ…" -``` - -### 2.4. Odbiorcy (persony) - -- **Marketer / brand manager** — wybiera wariant kampanii, potrzebuje rekomendacji. -- **Agencja kreatywna** — testuje koncepty przed prezentacją klientowi (pitch). -- **Projektant UX / CRO** — sprawdza, czy ekran prowadzi użytkownika do celu. -- **Super administrator (operator platformy)** — zarządza organizacjami i modelami AI. - ---- - -## 3. Słownik pojęć (model domenowy) - -Ujednolicenie nazewnictwa używanego w dalszej części dokumentu. - -| Pojęcie | Definicja | -|---|---| -| **Organizacja** | Najwyższy kontener klienta. Ma administratora, użytkowników, gości, projekty, pulę kredytów i przestrzeń dyskową. | -| **Użytkownik** | Niezależne konto osoby. Może należeć do wielu organizacji [?]. | -| **Projekt** | Kontener eksperymentów + galeria kreacji projektu. Typ pochodny: ET / FC / ET+FC. | -| **Eksperyment** | Pojedyncza analiza predykcyjna 1–3 kreacji wg zadanego celu, grupy, parametrów. | -| **Kreacja** | Materiał graficzny (PNG/JPEG) — reklama, baner, opakowanie, ekran. Jednostka wejściowa analizy. | -| **Galeria** | Zbiór kreacji: na poziomie **organizacji** (współdzielona) i **projektu** (podzbiór roboczy). | -| **Obiekt** | Rozpoznany element treści obrazu (osoba, butelka, logo…) z ramką (bbox). Źródło: AI lub użytkownik. | -| **AOI** (Area of Interest) | Obszar zainteresowania o znaczeniu marketingowym (CTA, Logo, Key Visual…). Źródło: AI lub użytkownik. | -| **Metryka** | Mierzalny wskaźnik percepcji/emocji (np. udział uwagi na AOI, Positive Valence). | -| **Cel** | Pytanie biznesowe wybrane przez użytkownika; mapuje się na typ analizy i zestaw metryk. | -| **Grupa docelowa** | Profil odbiorcy (wiek, płeć, miejsce, wykształcenie, dochód, neuroatypowość / preset). | -| **Raport** | Złożenie wizualizacji, metryk i interpretacji kognitywnej dla eksperymentu. | -| **Proces AI** | Pojedynczy krok analizy realizowany przez model (np. „detekcja obiektów", „predykcja saliency"). | -| **Model AI** | Konkretny silnik realizujący proces (LLaVA, ASM, DeepGaze…), wymienny na inny (§10). | -| **Kredyt / coin** | Wewnętrzna jednostka rozliczeniowa (eksperymenty, przestrzeń dyskowa). | - -### Diagram relacji encji (uproszczony) - -``` -Organizacja 1───* Użytkownik Organizacja 1───* Projekt - │ │ - │ 1 │ 1 - * * - Galeria(org) *───* Kreacja Eksperyment - ▲ │ * │ 1 - │ │ ├──* Kreacja (1–3: A/B/C) - Galeria(projekt) *────┘ ├──* Obiekt - ├──* AOI - ├──1 Cel + Grupa docelowa + Parametry - └──1 Raport ──* WynikModelu / Metryka -``` - ---- - -## 4. Architektura logiczna platformy - -### 4.1. Warstwy - -``` -┌──────────────────────────────────────────────────────────────────────┐ -│ FRONTEND — React + shadcn/ui + Tailwind │ -│ Panele: Administracyjny · Użytkownika · Organizacji │ -│ Kreator eksperymentu (4 kroki) · Studio (obiekty/AOI) · Raport │ -└───────────────────────────────┬──────────────────────────────────────┘ - │ REST / RPC -┌───────────────────────────────▼───────────────────────────────────────┐ -│ BACKEND — Node.js │ -│ • API platformy (CRUD: org, projekty, eksperymenty, galeria) │ -│ • Orkiestrator analizy AI (§9) — równoległe wywołania usług │ -│ • Warstwa metryk (saliency ∩ AOI → wskaźniki) │ -│ • Warstwa interpretacji kognitywnej (cel + metryki → rekomendacja) │ -│ • Generator raportu (PDF/XLS/wizualizacje) │ -│ • Rejestr modeli AI + router „Proces ↔ Model" (§10) │ -└──────────────┬────────────────────────────────────┬───────────────────┘ - │ │ HTTP POST (multipart) -┌──────────────▼──────────────────┐ ┌─────────────▼──────────────────────┐ -│ SUPABASE │ │ WARSTWA MODELI AI (mikroserwisy) │ -│ • PostgreSQL (model danych) │ │ LLaVA · Grounding DINO · DeepGaze │ -│ • Storage (kreacje, artefakty) │ │ UNISAL · ASM (PNS) · [Gemini/Opus]│ -│ • Auth (konta, sesje, role) │ │ Wymienne wg konfiguracji procesu │ -└─────────────────────────────────┘ └────────────────────────────────────┘ -``` - -### 4.2. Stack technologiczny (z Koncepcji 0.1) - -- **Front-end:** React / shadcn/ui + Tailwind -- **Back-end:** Node.js -- **Baza, Storage, Auth:** Supabase -- **Warstwa AI:** mikroserwisy modelowe za REST API, orkiestrowane przez backend Node.js (§9). - -### 4.3. Uwaga o orkiestracji - -Logika procesu AI jest opisana **niezależnie od narzędzia orkiestrującego** -(`Specyfikacja-procesu-AI.md`) i przeznaczona do implementacji jako komponent backendu -Node.js: równoległe wywołania usług modelowych, agregacja wyników i obsługa błędów (§9). -Pojedyncze modele (detekcja, saliency) pozostają niezależnymi mikroserwisami za REST API. - ---- - -## 5. Organizacje, role i uprawnienia - -### 5.1. Hierarchia - -- **Super administrator** — operator platformy. Dostęp do panelu administracyjnego; - zarządza organizacjami, użytkownikami i modelami AI. Może „wejść" w dowolną organizację - i poruszać się w niej jak administrator. Ma dostęp do logów systemowych i logów eksperymentu. -- **Administrator organizacji** — powstaje przy rejestracji organizacji; prawa zbywalne na - innego użytkownika. Pełny dostęp do projektów, rozliczeń, planów i ustawień organizacji. -- **Użytkownik** — niezależne konto; uprawnienia nadawane na poziomie organizacji i/lub projektu. -- **Gość** — wymieniony w strukturze organizacji; zakres uprawnień do doprecyzowania **[?]** - (proponowane: dostęp tylko do udostępnionych raportów, bez tworzenia treści). - -### 5.2. Macierz uprawnień (propozycja ujednolicająca) - -Uprawnienia działają na dwóch poziomach: **organizacji** i **konkretnego projektu**. - -| Uprawnienie | Super Admin | Admin org. | Użytkownik (org.) | Użytkownik (projekt) | Gość | -|---|:--:|:--:|:--:|:--:|:--:| -| Panel administracyjny | ✓ | — | — | — | — | -| Zarządzanie modelami AI | ✓ | — | — | — | — | -| Tworzenie projektów | ✓ | ✓ | wg uprawnień | — | — | -| Przeglądanie wszystkich projektów | ✓ | ✓ | wg uprawnień | — | — | -| Edycja wszystkich projektów | ✓ | ✓ | wg uprawnień | — | — | -| Usuwanie projektów | ✓ | ✓ | wg uprawnień | — | — | -| Zapraszanie do projektów | ✓ | ✓ | wg uprawnień | wg roli projekt. | — | -| Rozliczenia / plany / kredyty | ✓ | ✓ | — | — | — | -| Tworzenie / konfiguracja eksperymentu | ✓ | ✓ | ✓ | Editor | — | -| Podgląd raportu | ✓ | ✓ | ✓ | Editor / Viewer | Viewer (udostępniony) | - -**Role w obrębie projektu** (przy udostępnianiu): **Editor** (edycja + zapraszanie) / -**Viewer** (tylko podgląd). W Koncepcji 0.1 pojawia się też wariant „usuwanie, edycja i -zapraszanie" — ujednolicić do 2–3 ról projektowych **[?]**. - ---- - -## 6. Moduły platformy - -### 6.1. Panel administracyjny (tylko Super Administrator) - -**Sitebar:** Dashboard · Organizacje · Użytkownicy · Proces i modele AI · Logi. - -- **Dashboard** — KPI z dynamiką 30 dni (graficznie + liczbowo): liczba organizacji, - użytkowników, kreacji, przeprowadzonych eksperymentów. -- **Organizacje** — lista + wyszukiwarka; wejście w organizację pozwala zarządzać danymi, - użytkownikami, **kredytami** (globalnymi i miesięcznymi), aktywować / dezaktywować / - archiwizować organizację. -- **Użytkownicy** — lista + wyszukiwarka (dane podstawowe). -- **Proces i modele AI** — **zamknięta lista procesów** realizowanych w eksperymentach - oraz przypisany do każdego model AI. To miejsce wymiany modelu na inny (szczegóły §10). -- **Logi** — logi całego systemu z filtrowaniem (użytkownik, organizacja, zakres dat, typ operacji). - -### 6.2. Panel użytkownika (po zalogowaniu) - -Z tego miejsca użytkownik może: przejść do wybranej organizacji, dodać nową organizację -(limit: jedna nowa organizacja **[?]** — doprecyzować, czy dotyczy zakładania, czy członkostwa), -zmienić dane, e-mail, hasło. - -### 6.3. Panel organizacji (Administrator + użytkownicy) - -**Sitebar:** Dashboard · Projekty · Galeria. -**Topbar:** wybór organizacji · wyszukiwarka (projekty, kreacje, eksperymenty). -**Sitebar** chowa się na mobile; **Workspace** to obszar roboczy. - -- **Dashboard** — KPI: liczba kreacji w Galerii, liczba projektów, liczba eksperymentów. - Przyciski szybkich akcji: *Dodaj kreację do Galerii* · *Utwórz nowy Projekt* · - *Przejdź do ostatniego eksperymentu*. Poniżej: lista projektów z wejściem. -- **Galeria** — zarządzanie kreacjami organizacji: upload, kafelki ostatnio dodanych, - pełna galeria (slider). Klik w kreację → **drawer** po prawej: powiększenie + lista - eksperymentów/projektów, w których użyto kreacji (z przejściem do nich). -- **Projekty** — lista projektów (nazwa, typ ET/FC/ET+FC), przycisk *Nowy projekt*. - - **Panel projektu** — zarządzanie: przegląd, weryfikacja konfiguracji eksperymentów, - usuwanie projektu/eksperymentów, udostępnianie projektu. - - **Galeria projektu** — kreacje dodane do projektu (z Galerii organizacji lub własne projektu). - W jednym eksperymencie maks. **3 kreacje (A, B, C)**. Liczba materiałów ograniczona - przestrzenią dyskową subskrypcji (rozszerzalną za kredyty — §13). - - **Galeria eksperymentów** — wszystkie eksperymenty projektu z kluczowymi parametrami - (technologia ET/FC/ET+FC, typ testu, autor). - ---- - -## 7. Cykl życia eksperymentu (kreator 4 kroków) - -Każdy eksperyment przechodzi przez czterostopniowy kreator. Poniżej rozszerzenie z dopiętym -mapowaniem na warstwę AI (§9) i metryki (§8). - -### 7.1. Krok 1 — Cel i grupa docelowa - -- **Cel** — wybór ze słownika 15 celów (§8) lub opis własny. Cel determinuje rekomendowany - typ analizy i zestaw metryk. -- **Grupa docelowa** — cechy metryczkowe lub gotowe presety: - -| Kategoria | Wartości | -|---|---| -| **Wiek** | Młodzież (do 25) · Dorośli (26–64) · Seniorzy (65+) *(ujednolicić próg — patrz [?])* | -| **Płeć** | Kobieta · Mężczyzna | -| **Miejsce zamieszkania** | do 19 tys. · 20–50 tys. · 50–100 tys. · 100–500 tys. · >500 tys. | -| **Wykształcenie** | Podstawowe · Zasadnicze zawodowe · Średnie · Wyższe · Wyższe / tytuł naukowy | -| **Dochód** | Niski (≤MK) · Średni (MK–ŚK) · Wysoki (>ŚK) | -| **Neuroatypowość** | Brak / Neurotypowy · ASD · ADHD · Zaburzenia depresyjne | -| **Profile opisowe (presety)** | NT (Neurotypowy) · DE (Wykluczony cyfrowo) · SE (Silver Economy) · GZ (Gen-Z / Digital Native) | - -> **Powiązanie z AI — kluczowa uwaga:** obecny pipeline (§9) **nie przyjmuje** parametrów -> demograficznych na wejściu. Model ASM PNS ma docelowo generować predykcje różnicowane -> dla grup, jednak mechanizm warunkowania (np. przez `prompt` ASM lub osobne wagi modelu) -> wymaga decyzji. **[?]** — patrz §9.5 i `Pytania do koncepcji.md`. - -### 7.2. Krok 2 — Parametry - -- **Rodzaj analizy:** Eye Tracking · Facial Coding · ET+FC *(rekomendowany przez cel, - edytowalny przez użytkownika)*. -- **Rodzaj testu:** A (1 kreacja) · AB / AC / BC (2 kreacje) · ABC (3 kreacje). - *Uwaga: Koncepcja 0.1 w jednym miejscu podaje A/AB/ABC, a w innym A/AB/AC/BC/ABC — - ujednolicić.* **[?]** -- **Czas obserwacji:** 1s · 3s · 5s · 10s · 15s · 20s. - > Parametr nabiera pełnego znaczenia dopiero z **mapami czasowymi** (roadmapa). Przy - > obecnej, statycznej saliency służy do wyboru klatek wizualizacji statycznej. **[?]** -- **Zakres raportu:** wybór komponentów raportu (lista w §11). - -### 7.3. Krok 3 — Studio - -Edycja warstwy semantycznej obrazu przed analizą: - -- **Obiekty** — użytkownik zaznacza obszary i nazywa je **lub** korzysta z **identyfikacji - AI** (LLaVA → Grounding DINO), a następnie koryguje/usuwa. Słownik kategorii: Architektura, - Celebryci, Chemia, Edukacja, Elektronika, Finanse, Handel, Kosmetyki, Logistyka, Militaria, - Motoryzacja, Osoby, Przemysł, Przyroda, Sport, Ubrania, Zwierzęta, Żywność, Inne… -- **AOI** — analogicznie: ręcznie lub AI, z korektą. Słownik AOI: CTA, Dowód społeczny, - Key Visual, Kod QR, Kolorystyka, Kontakt, Korzyści, Kupon, Layout, Logo, Mapa, Nagłówek, - Narracja, Numer katalogowy, Regulaminy, Slogan, Ton komunikacji, Treść, Typografia, Tło… - -> **Obiekt vs AOI:** obiekty to *co jest na obrazie* (detekcja treści), AOI to *obszary o -> znaczeniu marketingowym* (jednostka analizy uwagi). Pipeline pewnie wykrywa **obiekty**; -> **AOI semantyczne** wymagają albo wskazania przez użytkownika, albo dodatkowego mapowania -> obiekt→AOI. **[?]** - -### 7.4. Krok 4 — Raport - -Generowanie i prezentacja wyników — szczegóły w §11. - -### 7.5. Logi eksperymentu - -Super administrator po wejściu w eksperyment widzi pełne logi: wszystkie działania i -ustawienia użytkownika oraz **wszystkie dane wysłane do i odebrane z modeli AI** (audyt -predykcji — istotne przy wymianie modeli, §10). - ---- - -## 8. Katalog celów analiz kognitywnych - -Mechanizm „cel zamiast metryk" (§2.3). Pełne opisy 15 celów znajdują się w -`Opis celów analiz kognitywnych.md`; poniżej **tabela zbiorcza** jako referencja -konfiguracyjna (źródło prawdy dla domyślnego doboru typu analizy i metryk). - -| # | Cel (nazwa UI) | Rekom. analiza | Sygnał kluczowy | -|---|---|:--:|---| -| 1 | Która kreacja lepiej sprzedaje? | ET+FC | uwaga na produkt/benefit/CTA + niskie napięcie | -| 2 | Czy odbiorca widzi najważniejszy przekaz? | ET (opc. ET+FC) | zauważalność i czas dotarcia do komunikatu | -| 3 | Czy CTA działa? | ET+FC | widoczność CTA + brak oporu emocjonalnego | -| 4 | Która kreacja zostaje w pamięci? | ET+FC | uwaga + pobudzenie (High Arousal) | -| 5 | Która kreacja najlepiej buduje markę? | ET+FC | uwaga na logo + pozytywna walencja | -| 6 | Czy kreacja budzi negatywne reakcje? | FC (opc. ET+FC) | Negative Valence + High Arousal na elemencie | -| 7 | Czy przekaz jest zrozumiały? | ET (opc. ET+FC) | logiczna ścieżka, brak chaosu/powrotów | -| 8 | Czy kreacja działa od pierwszych sekund? | ET+FC | pierwsza fiksacja + impuls emocjonalny 1–3s | -| 9 | Czy kreacja angażuje, czy jest obojętna? | FC (opc. ET+FC) | aktywacja vs Low Arousal / Neutral | -| 10 | Który styl komunikacji działa lepiej? | ET+FC | rozkład uwagi tekst/obraz + profil emocji | -| 11 | Które opakowanie lepiej przyciąga klienta? | ET+FC | marka/wariant/benefit + atrakcyjność | -| 12 | Czy ekran prowadzi użytkownika do celu? | ET+FC | ścieżka do akcji + komfort/frustracja | -| 13 | Która kreacja najlepiej pasuje do grupy docelowej? | ET+FC | różnice między segmentami | -| 14 | Która kreacja jest najbezpieczniejsza? | ET+FC | niska negatywność/ambiwalencja, czytelność | -| 15 | Która kreacja najbardziej się wyróżnia? | ET+FC | siła pierwszej fiksacji + aktywacja | - -**Zasada interpretacji wspólna dla wszystkich celów:** raport rozróżnia warianty -**pozytywne / neutralne / ryzykowne** (np. „wyróżnialność pozytywna" vs „ryzykowna"), -a rekomendacja zależy od **kontekstu kampanii** (performance vs wizerunek) i **grupy docelowej**. - ---- - -## 9. Warstwa AI — proces analizy - -Sekcja opiera się na `Specyfikacja-procesu-AI.md` — opisie logiki procesu niezależnym od -narzędzia orkiestrującego. Proces jest **bezstanowy**: jedno wejście (obraz) → jeden komplet wyników. - -### 9.1. Pipeline i usługi - -``` - Wejście: obraz (PNG/JPEG) - │ preprocessing → bytes + base64 + mime + (w,h) - ┌──────────────┼───────────────┬───────────────┬───────────────┐ - ▼ (łańcuch A, sekwencyjny) ▼ (B) ▼ (C) ▼ (D) -┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐ -│ LLaVA │ etykiety │ DeepGaze │ │ UNISAL │ │ ASM (PNS) │ -│ (VLM) │───┐ │(saliency)│ │(saliency)│ │ 2× saliency │ -└──────────┘ ▼ └────┬─────┘ └────┬─────┘ └──────┬───────┘ - ┌─────────────┐ │ │ │ - │ Grounding │ └──────────────┴────────────────┘ - │ DINO (boxy) │ │ agregacja saliency - └─────┬───────┘ ▼ - ▼ ┌─────────────────────────────┐ - detekcja obiektów │ Artefakty: overlay boxów · │ - │ nakładka heatmapy (suwak) · │ - │ porównanie 2×2 (walid. krzyż)│ - └─────────────────────────────┘ -``` - -**Pięć modeli / procesów (wg specyfikacji procesu AI):** - -| # | Model | Proces | Endpoint (wzorzec) | Auth | -|---|---|---|---|---| -| 1 | **LLaVA** | ekstrakcja typów obiektów (open-vocabulary) | `/llava-api/v1/get-object-types` | Bearer | -| 2 | **Grounding DINO** | detekcja / bounding boxy | `/grounding-dino-api/v1/get-objects-bboxes` | Bearer | -| 3 | **DeepGaze** | predykcja saliency | `/v1/predict-heatmap` | Bearer | -| 4 | **UNISAL** | predykcja saliency (porównawcza) | `/unisal/process-image?as_base64=true` | X-API-Key | -| 5 | **ASM (PNS)** | 2× saliency, warunkowane promptem marketingowym | `/asmModel/process-image?prompt=…` | X-API-Key | - -**Zależności i równoległość:** -- Łańcuch A jest **sekwencyjny** (Grounding DINO potrzebuje etykiet z LLaVA). -- Gałęzie A, B, C, D są **niezależne** → wykonywane **równolegle**; czas ≈ najwolniejsza gałąź. -- **Odporność:** awaria jednej gałęzi nie przerywa całości — degradacja stopniowa - (`return_exceptions` / per-task `try/except`); pozostałe artefakty powstają normalnie. - -### 9.2. Model danych wyników (z §4 specyfikacji) - -``` -AnalysisResult { - image : ImageInput { bytes, base64, mime, width, height } - detection : DetectionResult { objects: [{ object_type, bbox_xyxy, score }] } - saliency : SaliencyMap[] // deepgaze, unisal, asm_detailed, asm_general -} -``` - -### 9.3. Artefakty wizualizacyjne (warstwa prezentacji) - -1. **Overlay detekcji** — ramki per obiekt, kolor per typ, podpis `typ + score%`, - pozycje w procentach wymiarów (responsywność). -2. **Nakładka heatmapy** — pojedyncza mapa uwagi + suwak przezroczystości 0–100%. -3. **Porównanie 2×2** — DeepGaze / UNISAL / ASM detailed / ASM general; wspólny suwak, - technika „inwersji" (blend luminancji: biel = wysoka uwaga → efekt reflektora). - -### 9.4. Mapowanie: technologie badawcze (produkt) ↔ usługi AI (pipeline) - -| Warstwa produktu | Realizacja w AI | Status | -|---|---|:--:| -| **Eye Tracking** — mapy uwagi, udział uwagi na AOI | DeepGaze · UNISAL · ASM (saliency statyczna) | ✅ jest | -| Rozumienie treści — obiekty, opis | LLaVA + Grounding DINO | ✅ jest | -| **ET czasowy** — mapy dynamiczne 1–20s | saliency w interwałach czasu | 🟡 roadmapa | -| **ET** — ścieżki fiksacji (scanpath) | model scanpath | 🟡 roadmapa | -| **Facial Coding** — walencja, pobudzenie, frustracja… | mapa emocji | 🟡 roadmapa | -| **Analiza kognitywna** — rekomendacja z uzasadnieniem | warstwa interpretacji (LLM nad metrykami) | 🔵 do zbudowania | -| **Predykcje per grupa docelowa** | warunkowanie modelu demografią | 🟡 do zaprojektowania | - -> Legenda: ✅ objęte specyfikacją procesu (modele dostępne) · 🟡 roadmapa (§11 specyfikacji) · 🔵 nowy komponent. - -### 9.5. Macierz wykonalności metryk w MVP (najważniejsza sekcja inżynierska) - -Większość metryk z `Opis celów…` wymaga komponentów, których **nie ma** w obecnym -pipeline. To rozgraniczenie jest krytyczne dla zakresu MVP. - -| Metryka (z celów) | Czego wymaga | Wykonalne w MVP? | -|---|---|:--:| -| Udział uwagi na AOI (%) | saliency statyczna ∩ AOI | ✅ tak | -| Ranking AOI wg uwagi | saliency ∩ AOI | ✅ tak | -| Mapa cieplna statyczna | saliency | ✅ tak | -| Porównanie kreacji wg uwagi | saliency × N kreacji | ✅ tak | -| Czas do pierwszej fiksacji | scanpath (wymiar czasu) | ❌ roadmapa | -| Kolejność kontaktu z AOI / „ścieżka AOI" | scanpath | ❌ roadmapa* | -| Liczba powrotów wzroku | scanpath | ❌ roadmapa | -| Mapy dynamiczne 1–20s | saliency czasowa | ❌ roadmapa | -| Ścieżki fiksacji | model scanpath | ❌ roadmapa | -| Positive/Negative Valence, Arousal, Frustration, Ambivalence, Comfort… | model emocji (FC) | ❌ roadmapa | -| Różnice metryk między segmentami | warunkowanie demografią | ❌ do zaprojektowania | - -\* „Ścieżkę AOI" można w MVP **przybliżyć** rankingiem AOI wg intensywności saliency -(kolejność „od najsilniejszego"), zaznaczając, że to heurystyka, a nie prawdziwa sekwencja -fiksacji. **[?]** - -**Wniosek:** w MVP z obecnym pipeline'em wiarygodnie policzymy metryki **udziału uwagi na -AOI** i ich **porównanie między wariantami** (cele silnie ET, np. #2, #7, częściowo #1, #3). -Cele oparte na **emocjach** (#6, #9) i **wymiarze czasu** (#8) wymagają roadmapowych modeli -FC / saliency czasowej, albo świadomego **ograniczenia zakresu MVP**. → decyzja właściciela -produktu (`Pytania do koncepcji.md`). - ---- - -## 10. Wymienialność modeli AI (Proces ↔ Model) - -Wymaganie z `info.md`: w MVP 1.0 musi istnieć możliwość **zmiany modelu realizującego dany -proces** na inny (np. publiczny **Gemini**, **Opus**), z poziomu panelu administracyjnego. - -### 10.1. Zasada: rozdzielenie procesu od modelu - -``` -PROCES (stały, zamknięta lista) MODEL (wymienny) USŁUGA (endpoint) -───────────────────────────── ───────────────── ───────────────── -Ekstrakcja typów obiektów ──► LLaVA ──► http://{LLaVA}/llava-api/... - ╲─► [Gemini Vision] ──► adapter → API Gemini -Detekcja obiektów (boxy) ──► Grounding DINO ──► .../get-objects-bboxes -Predykcja saliency #1 ──► DeepGaze ──► /v1/predict-heatmap -Predykcja saliency #2 ──► UNISAL ──► /unisal/process-image -Predykcja saliency (centralna) ──► ASM (PNS) ──► /asmModel/process-image -[Mapa emocji — roadmapa] ──► [FC model] ──► … -``` - -Każdy **proces** ma zdefiniowany **kontrakt** (wejście: obraz [+ parametry]; wyjście: -ustandaryzowany typ — `labels[]`, `bboxes[]`, `SaliencyMap`). Model jest podpięty przez -**adapter** tłumaczący kontrakt procesu na konkretne API. Dzięki temu podmiana -LLaVA→Gemini nie zmienia reszty pipeline'u. - -### 10.2. Wzorzec adaptera - -Aby podpiąć nowy model (np. Gemini/Opus) trzeba dostarczyć **adapter** = kod realizujący: -1. **mapowanie wejścia** procesu → format żądania modelu (multipart / JSON, prompt, parametry), -2. **wywołanie** (URL, schemat auth: Bearer vs X-API-Key vs klucz dostawcy), -3. **mapowanie wyjścia** modelu → ustandaryzowany typ procesu (np. `labels[]`). - -To realizuje zdanie z `info.md`: „powinien być dodany kod, który realizuje usługę". -Każdy proces = interfejs; każdy model = jego implementacja (adapter). - -### 10.3. Panel „Proces i modele AI" (rozszerzenie) - -Ekran administracyjny prezentuje **zamkniętą listę procesów** i pozwala dla każdego: - -- wybrać **aktywny model** (z listy zarejestrowanych adapterów), -- skonfigurować **endpoint / klucze / parametry** (host, token, prompt ASM, `max_objects`, - `temperature`…) — przechowywane jako sekrety (Supabase / vault), nie w kodzie, -- wykonać **test połączenia** (health-check) i podgląd przykładowego wyniku, -- (zalecane) **wersjonować** przypisanie model↔proces, aby logi eksperymentu wskazywały, - którym modelem policzono dany raport (powtarzalność, audyt — §7.5). - -> W MVP konfiguracja modeli (adresy URL, token/klucz, parametry) jest zarządzana z panelu -> administracyjnego i przechowywana w magazynie sekretów (Supabase / vault), nie w kodzie. - -### 10.4. Modele własne vs publiczne - -- **Własne (mikroserwisy):** LLaVA, Grounding DINO, DeepGaze, UNISAL, ASM (PNS) — pełna - kontrola, model ASM jest rdzeniem przewagi produktu. -- **Publiczne (API dostawców):** Gemini, Opus (Anthropic) i inne — przydatne dla procesów - „rozumienia treści" (opis kreacji, lista obiektów) jako alternatywa/fallback dla LLaVA. - **Uwaga:** modele saliency (predykcja uwagi) i FC są wyspecjalizowane — publiczne LLM-y - ogólnego przeznaczenia ich **nie zastąpią 1:1**; wymienialność ma największy sens dla - procesów językowo-wizualnych (etykiety, opis), a nie dla rdzennej predykcji uwagi. **[?]** - ---- - -## 11. Struktura i generowanie raportu - -### 11.1. Komponenty raportu i ich źródła (macierz śledzenia) - -| Komponent raportu | Źródło danych (proces/model) | Status MVP | -|---|---|:--:| -| Opis ogólny kreacji | LLaVA / opis (ew. ASM prompt) | ✅ | -| Lista obiektów | LLaVA + Grounding DINO | ✅ | -| Lista i opis AOI | użytkownik (Studio) ± mapowanie z obiektów | 🟡 częściowo | -| Mapy cieplne — statyczne (1/3/5/10/15/20s) | DeepGaze/UNISAL/ASM (1 mapa = 1 klatka) | ✅ (jedna klatka)* | -| Mapy cieplne — dynamiczne 1–20s | saliency czasowa | 🟡 roadmapa | -| Ścieżki fiksacji — statyczne/dynamiczne | model scanpath | 🟡 roadmapa | -| Ścieżka AOI | scanpath (lub przybliżenie rankingiem) | 🟡 / heurystyka | -| Analiza kognitywna (rekomendacja) | warstwa interpretacji (cel + metryki → tekst) | 🔵 do zbudowania | -| Tabela porównawcza z metrykami | warstwa metryk (saliency ∩ AOI) | ✅ (zakres ET-static) | - -\* obecne modele zwracają **jedną** mapę saliency; „statyczne 1/3/5/10/15/20s" są realne -dopiero z saliency czasową — w MVP można pokazać jedną mapę zagregowaną. **[?]** - -### 11.2. Warianty A / AB / ABC - -- Komponenty raportu powielają się per kreacja: **AB** → 2 kreacje, **ABC** → 3 kreacje. -- Sednem jest **zestawienie porównawcze** i rekomendacja „który wariant wygrywa i dlaczego", - z rozbiciem na zwycięzcę ogólnego i zwycięzcę dla grupy docelowej (cel #13). - -### 11.3. Eksport i udostępnianie - -- **Eksport:** PDF (raport). Use case 2 dodaje **XLS** (tabele metryk) i **AVI** (dynamiczne - mapy/ścieżki) — zależne od roadmapy czasowej. **[?]** -- **Udostępnianie:** wg uprawnień projektu; **link do eksperymentu** (Editor / Viewer). - Doprecyzować: link publiczny czy wymaga konta. **[?]** -- **Klonowanie:** „Zmień ten eksperyment" / „Edytuj" → prośba o nową nazwę → przekierowanie - do Kroku 1 z prekonfiguracją z eksperymentu bazowego (wersjonowanie — §12, [?]). - ---- - -## 12. Propozycja modelu danych (Supabase) - -Szkic encji do walidacji (nazwy robocze). Klucze obce uproszczone. - -``` -organizations(id, name, status[active|inactive|archived], credits_balance, - storage_quota_mb, created_at) -users(id, email, display_name, locale, created_at) -memberships(id, org_id, user_id, role[admin|member|guest]) // M:N user↔org -projects(id, org_id, name, type[ET|FC|ET_FC], created_by, created_at) -project_permissions(id, project_id, user_id, role[editor|viewer]) -creatives(id, org_id, project_id?, storage_path, mime, width, height, created_by) -experiments(id, project_id, name, goal_id, test_type[A|AB|AC|BC|ABC], - analysis_type[ET|FC|ET_FC], observation_time_s, report_scope jsonb, - target_group jsonb, base_experiment_id?, status, created_by, created_at) -experiment_creatives(id, experiment_id, creative_id, slot[A|B|C]) -aois(id, experiment_id, creative_id, name, category, polygon jsonb, source[ai|user]) -objects(id, experiment_id, creative_id, object_type, bbox_xyxy jsonb, score, source) -ai_runs(id, experiment_id, process_key, model_key, request jsonb, response_ref, - status, duration_ms, created_at) // audyt: który model, jaki wynik -saliency_maps(id, ai_run_id, source[deepgaze|unisal|asm_detailed|asm_general], - storage_path, mime) -metrics(id, experiment_id, creative_id, aoi_id?, key, value) // policzone wskaźniki -reports(id, experiment_id, pdf_path?, xls_path?, generated_at) -ai_processes(key, name, contract) // zamknięta lista procesów -ai_models(key, name, kind[own|public], adapter, config_ref) // rejestr modeli -process_model_binding(process_key, model_key, active, version) // Proces ↔ Model (§10) -audit_logs(id, org_id?, user_id?, action, target, payload jsonb, created_at) -``` - -Kluczowe dla wymagań: -- `ai_runs` + `process_model_binding` → realizują **wymienialność modeli** i **audyt - predykcji** (logi eksperymentu, §7.5). -- `base_experiment_id` → realizuje **klonowanie** eksperymentu. -- `target_group jsonb` → przechowuje profil grupy (wejście dla przyszłego warunkowania). - ---- - -## 13. Kredyty, subskrypcje, przestrzeń dyskowa - -Z Koncepcji 0.1 wynika istnienie **kredytów/coinów** (globalnych i miesięcznych) oraz -**przestrzeni dyskowej** zależnej od subskrypcji i rozszerzalnej za punkty. Wymaga to -doprecyzowania modelu rozliczeń — propozycja ramowa (do potwierdzenia, **[?]**): - -| Element | Propozycja | -|---|---| -| Naliczanie za eksperyment | koszt zależny od typu analizy (ET < FC < ET+FC) i liczby kreacji (A/AB/ABC) | -| Kredyty miesięczne | pula odnawialna w cyklu rozliczeniowym (zarządzana przez Super Admina) | -| Kredyty globalne | pula dokupiona, nieodnawialna | -| Przestrzeń dyskowa | limit z planu; rozszerzenie za kredyty wg cennika przestrzeni | -| Plany subskrypcji | **niezdefiniowane w źródłach** — wymagają osobnej specyfikacji | - -Decyzje otwarte: cennik (ile kredytów za co), polityka wygasania kredytów, obsługa -przekroczenia limitów, fakturowanie. → `Pytania do koncepcji.md`. - ---- - -## 14. Logi i audyt - -Dwa poziomy: -- **Logi systemowe** (panel administracyjny) — filtrowanie po użytkowniku, organizacji, - zakresie dat, typie operacji. -- **Logi eksperymentu** (Super Admin) — pełen ślad: działania i ustawienia użytkownika + - **wszystkie dane wysłane/odebrane z modeli AI**. Powiązane z `ai_runs` (§12): każda - predykcja zapisuje proces, model, żądanie i referencję odpowiedzi → audyt i powtarzalność, - szczególnie po podmianie modelu (§10). - ---- - -## 15. Bezpieczeństwo, prywatność, zgodność - -- **Brak danych respondentów:** produkt generuje **predykcje AI**, nie zbiera danych od - realnych osób — to istotnie obniża ryzyko RODO względem klasycznego eye-trackingu. - Dane osobowe ograniczają się do **kont użytkowników** (auth Supabase). -- **Własność treści:** kreacje klientów to materiały chronione — kontrola dostępu na poziomie - organizacji/projektu; izolacja danych między organizacjami (RLS w Supabase — zalecane). -- **Sekrety:** klucze i hosty modeli poza kodem (vault / zmienne środowiskowe), nie w repo. -- **Dane wysyłane do modeli publicznych:** przy podmianie na Gemini/Opus kreacje opuszczają - infrastrukturę własną → wymagana zgoda klienta i zapis w politykach. **[?]** -- **Profile wrażliwe:** kategoria **neuroatypowość** (ASD/ADHD/depresja) to dane wrażliwe - w warstwie *konfiguracji predykcji* (nie dotyczą realnych osób), ale komunikacja wyników - powinna unikać sugestii diagnostycznych. **[?]** - ---- - -## 16. Internacjonalizacja - -- **Języki UI w MVP 1.0:** polski, angielski (kolejne w następnych wersjach). -- **Język raportu / interpretacji kognitywnej:** powinien podążać za locale użytkownika — - warstwa interpretacji (LLM) generuje tekst w wybranym języku. **[?]** -- **Prompt ASM:** obecnie po angielsku (`"Describe the image in the style of a polished - marketing ad."`) — traktowany jako **parametr konfigurowalny** (nie stała), niezależny od - języka UI. - ---- - -## 17. Przepływy użytkownika (use case'y) - -### UC1 — Eksperyment ABC bez zmian w Studio (obiekty/AOI z AI) - -1. Rejestracja → 2. Logowanie → 3. Utworzenie organizacji → 4. Dodanie kreacji do Galerii → -5. Nowy projekt → eksperyment: cel + grupa docelowa, typ **ABC** + 3 kreacje, parametry, -**bez** zmian w Studio → 6. Generowanie raportu → 7. Eksport **PDF** → 8. Udostępnienie -(Editor/Viewer) → 9. „Zmień ten eksperyment" → nowa nazwa → Krok 1 z prekonfiguracją. - -### UC2 — Eksperyment ABC ze zmianami w Studio + segment - -Jak UC1, z konkretną grupą docelową (np. Młodzież / Kobieta / miasto do 19 tys. / wyższe / -dochód średni / neurotypowy), celem „Która kreacja lepiej sprzedaje?", **ET+FC**, 3 kreacje, -obiekty/AOI wskazane przez AI (z możliwą korektą), eksport **PDF + XLS + AVI**, udostępnienie -1× Editor i 1× Viewer, oraz „Edytuj" jako baza kolejnego eksperymentu. - -> UC2 uruchamia komponenty roadmapowe (FC, XLS metryk, AVI dynamiczne) — w MVP zrealizowany -> w zakresie dostępnych metryk ET-static, z resztą oznaczoną jako „wkrótce". **[?]** - ---- - -## 18. Zakres MVP 1.0 vs roadmapa - -### ✅ W zakresie MVP 1.0 - -- Platforma SaaS: organizacje, role/uprawnienia, projekty, galeria (org + projekt), eksperymenty. -- Kreator eksperymentu (4 kroki), słowniki celów / obiektów / AOI / grup docelowych. -- Studio: ręczne i AI-wspomagane obiekty/AOI (LLaVA + Grounding DINO). -- Pipeline AI: detekcja obiektów + **saliency statyczna z 3 modeli** (DeepGaze, UNISAL, ASM) - z walidacją krzyżową i wizualizacjami (overlay, nakładka, porównanie 2×2). -- Metryki **udziału uwagi na AOI** i porównanie wariantów; raport + eksport PDF. -- Panel administracyjny: organizacje, użytkownicy, **wymiana modeli AI (Proces ↔ Model)**, logi. -- Warstwa interpretacji kognitywnej (rekomendacja z uzasadnieniem) — **do zbudowania**, ale - należy do rdzenia wartości MVP (bez niej raport jest zbiorem liczb). **[?] priorytet.** - -### 🟡 Roadmapa (kolejne wersje — §11 specyfikacji procesu AI) - -- **Facial Coding / mapa emocji** (walencja, pobudzenie, frustracja, ambiwalencja, komfort…). -- **Mapy cieplne dynamiczne 1–20s** (saliency w interwałach czasu). -- **Ścieżki fiksacji (scanpath)** i pełna **„ścieżka AOI"** z sekwencją czasową. -- **Predykcje różnicowane per grupa docelowa** (warunkowanie modelu demografią). -- Eksporty **XLS / AVI**, kolejne języki UI. - -### 🔑 Rekomendacja zakresowa - -MVP powinno **dowieźć pętlę wartości** dla podzbioru celów silnie ET (np. #2 „Czy odbiorca -widzi przekaz?", #7 „Czy przekaz jest zrozumiały?", częściowo #1/#3) — tam obecny pipeline -daje wiarygodne metryki. Cele zależne od emocji i czasu zaprezentować jako „wkrótce", aby nie -obiecywać wyników, których pipeline jeszcze nie liczy. Ostateczna lista celów MVP → -decyzja właściciela produktu. - ---- - -*Dokument roboczy v0.2. Miejsca [?] wymagają decyzji — zebrane w `Pytania do koncepcji.md`.* diff --git a/Pytania do koncepcji.md b/Pytania do koncepcji.md index 63c9fe6..3aee3fd 100644 --- a/Pytania do koncepcji.md +++ b/Pytania do koncepcji.md @@ -19,8 +19,7 @@ wyłącznie detekcję obiektów i predykcję uwagi (saliency); **mapa emocji jes **Pytanie:** Czy MVP 1.0 ma realnie liczyć metryki Facial Coding? Jeśli tak — jaki model/usługa je dostarczy i kiedy będzie dostępny? Jeśli nie — czy ukrywamy opcje FC/ET+FC, czy pokazujemy je jako „wkrótce"? -**Propozycja robocza:** MVP dostarcza **ET (saliency statyczna)**; opcje FC oznaczone „wkrótce". -*(§9.4, §9.5, §18)* +**Odp.:** Zostanie to dodane. Uruchomienie ma nastąpić w wersji MVP 1.0 ### Q2. Wymiar czasu — „czas obserwacji 1–20s", mapy dynamiczne, scanpath **Kontekst:** Obecne modele zwracają **jedną, statyczną** mapę uwagi. Raport zakłada @@ -28,7 +27,7 @@ jako „wkrótce"? wszystko to wymaga **saliency czasowej / scanpath**, które są w roadmapie. **Pytanie:** Czy parametr „czas obserwacji" i wizualizacje czasowe są w zakresie MVP? Jeśli nie — czy pokazujemy pojedynczą mapę zagregowaną i ukrywamy oś czasu? -**Propozycja robocza:** MVP = jedna mapa statyczna; oś czasu w roadmapie. *(§7.2, §9.5, §11.1)* +**Odp:** Zostanie to dodane do modeli. Uruchomienie ma nastąpić w wersji MVP 1.0 ### Q3. Predykcje per grupa docelowa — jak technicznie? **Kontekst:** Kreator zbiera bogaty profil grupy (wiek, płeć, miejsce, wykształcenie, dochód, @@ -38,8 +37,8 @@ ma takiego parametru. **Pytanie:** Jak grupa docelowa ma wpływać na wynik? Opcje: (a) przez `prompt` modelu ASM, (b) osobne wagi/warianty modelu per segment, (c) w MVP grupa jest tylko **metadanymi raportu** bez wpływu na predykcję. -**Propozycja robocza:** w MVP (c) — grupa opisuje kontekst i interpretację, nie zmienia mapy -uwagi; różnicowanie per segment → roadmapa. *(§7.1, §9.4, §9.5)* +**Odp:** Mogą następić zmiany, które spowodują, że dane profilowe będą brane pod uwagę. +Przykładowo model zewnętrzny działający na Gemini może korzystać z danych profilowych a wewnętrzne nie. ### Q4. „Analiza kognitywna" (rekomendacja z uzasadnieniem) — kto/co ją generuje? **Kontekst:** Rdzeń wartości produktu to zdanie typu „Wariant B wygrywa, ponieważ…". To **nowy @@ -47,14 +46,13 @@ komponent** (warstwa interpretacji LLM nad metrykami) — nie istnieje w pipelin **Pytanie:** Czy budujemy tę warstwę w MVP? Jaki model ją realizuje (ASM? publiczny LLM?), na jakich danych wejściowych (metryki + cel + grupa), z jakimi zabezpieczeniami przed „halucynacją" rekomendacji? -**Propozycja robocza:** TAK, to priorytet MVP; realizacja przez LLM z **ustrukturyzowanym -wejściem** (policzone metryki), nie przez „opowieść" o obrazie. *(§9.4, §11.1, §18)* +**Odp:** Wyniki z poszczególnych modeli mają określone wyniki. Model (prywatny lub publiczny) będzie mógł przeanalizować wyniki i na podstawie celu klienta wybrać jaka kreacja będzie lepsza. ### Q5. Zakres celów w MVP **Kontekst:** 15 celów; większość rekomenduje **ET+FC**. Bez FC i wymiaru czasu część celów nie jest w pełni wykonalna (§9.5). **Pytanie:** Które z 15 celów udostępniamy w MVP 1.0? -**Propozycja robocza:** start od celów silnie ET (#2, #7, #1, #3), reszta „wkrótce". *(§8, §18)* +**Odp:** FC należy zrealizwać jako model publiczny nawet jeśli nie będzie dostępny jako model prywatny. --- @@ -65,32 +63,32 @@ nie jest w pełni wykonalna (§9.5). AOI** — to komponent backendu, a nie wynik zwracany przez modele (modele dostarczają mapy uwagi). **Pytanie:** Potwierdzamy, że backend liczy metryki z map saliency (saliency ∩ AOI), a modele dostarczają wyłącznie mapy? Jaka jest dokładna lista wskaźników w MVP? -**Propozycja robocza:** tak; MVP liczy udział uwagi na AOI, ranking AOI i porównanie wariantów -(zakres ET-static). *(§9.5, §11.1)* +**Nie rozumiem. Wyjaśnij dokładniej** ### Q7. Zakres wymienialności modeli (info.md) **Kontekst:** Wymóg: zmiana modelu na inny (Gemini, Opus). Modele saliency/FC są jednak wyspecjalizowane — publiczny LLM nie zastąpi ich 1:1. **Pytanie:** Które procesy mają być wymienialne w MVP? Tylko „rozumienie treści” (etykiety/opis: LLaVA↔Gemini/Opus), czy też predykcja uwagi (co wymaga modeli saliency innego dostawcy)? -**Propozycja robocza:** wymienialność w MVP dla procesów językowo-wizualnych; predykcja uwagi -pozostaje na modelach własnych (ASM jako rdzeń). *(§10.1, §10.4)* +**Odp:** W każdym zakresie można wymienić model. Przy wymianie modelu trzeba również wymianić kod jaki relizuje dany krok, tak aby wymiana zachowała spójność poszczególnych kroków procesu. Możliwe, że sam kod dla modeli publicznych powinien być jako plugin w oprogramowaniu. +Przykładowo: +- Nasz mode prywatny dostępny przez API (bez pluginu) +- Model publiczny Gemini (plugin dla wskazania obiektów dla modeli publicznych) +- Model publiczny Opus (plugin dla wskazania obiektów dla modeli publicznych) ### Q8. Konfiguracja modeli — gdzie i jak zarządzana? **Kontekst:** Konfiguracja modeli (hosty, token/klucz, parametry) nie powinna być zaszyta w kodzie ani w konfiguracji testowej — w MVP zarządzana z panelu administracyjnego. **Pytanie:** Czy akceptujemy model „Proces ↔ Model" z adapterami, konfiguracją sekretów w panelu, testem połączenia i wersjonowaniem przypisania (dla audytu, który model policzył raport)? -**Propozycja robocza:** TAK (§10.2–10.3, encje `ai_processes` / `ai_models` / -`process_model_binding` w §12). *(§10, §12)* +**Nie rozumiem. Wyjaśnij dokładniej** ### Q9. Obiekty vs AOI — skąd biorą się AOI semantyczne? **Kontekst:** Pipeline wykrywa **obiekty** (LLaVA+DINO). AOI to **obszary marketingowe** (CTA, Logo…). To inna kategoria niż „osoba/butelka". **Pytanie:** AOI w MVP są: (a) wyłącznie ręczne (Studio), (b) AI sugeruje AOI osobnym modelem, (c) mapowane heurystycznie z wykrytych obiektów? -**Propozycja robocza:** MVP — AOI ręczne + ewentualne podpowiedzi z obiektów; pełna „AI-detekcja -AOI” to osobny model. *(§7.3, §11.1)* +**Odp:** MVP - automatycznie i ręcznie. Użytkownik na początku otrzymuje w Studio automatycznie wskzane AOI. Może je ręcznie zmienić AOI, wprowadzić nowe AOI. --- @@ -101,30 +99,53 @@ AOI” to osobny model. *(§7.3, §11.1)* pojawia się **A/AB/AC/BC/ABC**. **Pytanie:** Który zestaw obowiązuje? Czy potrzebne są wszystkie pary (AC, BC), czy slot A/B/C jest stały? -**Propozycja robocza:** pełny zestaw A/AB/AC/BC/ABC (większa elastyczność porównań). *(§7.2)* +**Odp:** Testy A, AB, A/AB/ABC ### Q11. Próg wieku „Seniorzy" **Kontekst:** W jednym miejscu „Seniorzy (66 i więcej)”, opis grup mówi „Dorośli 26–64” → luka 65 lat. -**Pytanie:** Ustalić progi bez luki (proponowane: Senior **65+**). *(§7.1)* +**Odp:** Seniorzy (65 i więcej) ### Q12. Limit „jednej nowej organizacji" na użytkownika **Kontekst:** „może dodać tylko jedną nową organizację”. **Pytanie:** Czy to limit **zakładanych** organizacji (1 własna), czy łącznej **przynależności**? Czy użytkownik może należeć do wielu organizacji przez zaproszenia? -**Propozycja robocza:** użytkownik zakłada max 1 organizację, ale może być członkiem wielu przez -zaproszenia. *(§3, §5, §6.2)* +**Odp:** Użytkownik zakłada max 1 organizację, ale może być członkiem wielu przez +zaproszenia. ### Q13. Rola „Gość" — zakres **Kontekst:** Gość wymieniony w strukturze, bez zdefiniowanych uprawnień. **Pytanie:** Co może gość? Propozycja: tylko podgląd udostępnionych raportów, bez tworzenia treści -i bez dostępu do rozliczeń. *(§5.1, §5.2)* +i bez dostępu do rozliczeń. +**Odp:** Rezygnujemy z gościa. Będzie to użytkownik. ### Q14. Role projektowe — ujednolicenie **Kontekst:** Koncepcja wymienia różne warianty („Editor/Viewer” oraz „usuwanie/edycja/ zapraszanie / edycja/zapraszanie / przeglądanie”). **Pytanie:** Ile ról projektowych i jakie dokładnie uprawnienia? Propozycja: **Editor** / **Viewer** (+ ewentualnie **Manager** z prawem usuwania i zarządzania dostępem). *(§5.2)* +**Odp:** Rezygunjemy z Editor/Viewer, zostawiamy tylko te ustalenia: +- Organizacja: + - Posiada Administratora + - Posiada Użytkowników + - Posiada Gości + - Posiada Projekty +- Role + - Super administrator - posiada dostęp do panelu administracyjnego, w którym może zarządzać organizacjami, użytkownikami, modelami AI. Super administrator może przejść do każdej z organizacji w systemie. Jeśli Super administrator wchodzi do organizacji to może w niej poruszać się tak jak Administrator. + - Administrator - Administrator organizacji powstaje podczas rejestracji Organizacji. Prawa administratora mogą zostać przekazane do innego użytkownika przez administratora. + - Użytkownik - Każdy użytkownik w platformie posiada własne niezależne konto. +- Uprawnienia + - Administrator - Posiada uprawnienia do każdego projektu, rozliczeń, planów i ustawień. Może tworzyć nowe projekty i eksperymenty bez ograniczeń. + - Użytkownik - może posiadać uprawnienia: + - Tworzenia nowych projektów + - Przeglądania wszystkich projektów + - Edytowania wszystkich projektów + - Usuwania wszystkich projektów + - Zapraszanie użytkowników do wszystkich projektów + - Użytkownik może również otrzymać uprawnienia w ramach projektu takie jak: + - Usuwanie, edycja i zapraszanie użytkowników + - Edycja i zapraszanie użytkowników + - Przeglądanie --- @@ -134,31 +155,50 @@ zapraszanie / edycja/zapraszanie / przeglądanie”). **Pytanie:** Cennik eksperymentu (zależny od ET/FC/ET+FC i liczby kreacji?), zasady kredytów miesięcznych vs globalnych, wygasanie, zachowanie przy przekroczeniu limitu, fakturowanie. Brak danych w źródłach. *(§13)* +**Odp:** Super administrator w panelu może zdefiniować plany. Plan może zawiera takie dane jak: +- Nazwa +- Opis +- Liczbę kredytów na start +- Liczbę kredytów miesięcznie +- Miejsce na dysku + +Plan jest dla całej organizacji. + +Kredyty są pobierane za poszczególne eksprymenty. Przykładowo: +- Eskeryment A dla krecji graicznej - 5 kredytów +- Eskeryment AB dla krecji graicznej - 10 kredytów +- Eskeryment ABC dla krecji graicznej - 15 kredytów ### Q16. Plany subskrypcji i przestrzeń dyskowa **Pytanie:** Jakie plany (nazwy, limity, ceny)? Cennik rozszerzenia dysku w kredytach? *(§13)* +**Odp:** jw. ### Q17. Eksport XLS / AVI **Kontekst:** Use case 2 wymaga XLS (tabele metryk) i AVI (dynamiczne mapy/ścieżki). **Pytanie:** Czy w MVP? AVI zależy od wizualizacji czasowych (Q2). Propozycja: PDF w MVP; XLS gdy są metryki tabelaryczne; AVI z roadmapą czasową. *(§11.3)* +**Odp:** Ignorujemy eksport XLS / AVI ### Q18. Udostępnianie raportu linkiem — publiczne czy z logowaniem? **Pytanie:** „Link do eksperymentu” to dostęp publiczny (każdy z linkiem), czy wymaga konta i nadanej roli (Editor/Viewer)? Implikacje dla bezpieczeństwa treści klienta. *(§11.3, §15)* +**Odp:** Można utworzyć link publiczny. Bez wymogu logowania. ### Q19. Dane wysyłane do modeli publicznych (Gemini/Opus) **Kontekst:** Podmiana na publiczny model = kreacje opuszczają infrastrukturę własną. **Pytanie:** Czy wymagana zgoda klienta / oznaczenie w organizacji, że dany proces korzysta z modelu zewnętrznego? *(§10.4, §15)* +**Odp:** Nie, klient nie decyduje na jakim modelu pracuje. To Super administrator decyduje jakie model i plugin jest stosowany dla danego procesu. ### Q20. Kategoria „neuroatypowość” — komunikacja i zgodność **Pytanie:** Jak prezentować wyniki dla profili ASD/ADHD/depresja, by nie sugerować diagnozy? Czy model w ogóle różnicuje predykcje wg neuroatypowości (powiązane z Q3)? *(§7.1, §15)* +**Odp:** Nie robimy takiego rozróżnienia ### Q21. Język raportu i interpretacji **Pytanie:** Czy tekst rekomendacji (warstwa kognitywna) podąża za locale użytkownika (PL/EN)? Czy prompt ASM zależy od języka, czy pozostaje stały (obecnie EN)? *(§16)* +**Odp:** Tak, jest dopasowana do języka w jaki wybrał użytkownik --- @@ -168,19 +208,23 @@ Czy prompt ASM zależy od języka, czy pozostaje stały (obecnie EN)? *(§16)* W `Specyfikacja-procesu-AI.md` kształty odpowiedzi oznaczono „(wnioskowane)”. **Pytanie:** Czy istnieje dokumentacja/realne odpowiedzi usług (LLaVA, DINO, DeepGaze, UNISAL, ASM) do potwierdzenia pól (`labels`, `objects_bboxes`, `heatmap_b64`, `data`, `image_detailed/general`)? +**Odp:** Zostanie dostarczona ### Q23. Model ASM PNS — faktyczny zakres **Kontekst:** ASM zwraca **2 mapy uwagi** (detailed/general), ale `Opis celów…` przypisuje mu też predykcję **pobudzenia emocjonalnego / zapamiętywalności**. **Pytanie:** Co dokładnie ASM PNS potrafi dziś, a co jest planem? Czy „detailed/general” odpowiadają jakimś pojęciom produktowym? +**Odp:** Zostanie dostrczony osobna dokumentacja modelu i ich możliwości ### Q24. Hosting i dostępność modeli **Kontekst:** UNISAL i ASM współdzielą jeden host (`1.208.108.242:58951`). **Pytanie:** Jaka jest docelowa infrastruktura produkcyjna (SLA, skalowanie, lokalizacja danych)? +**Odp:** jw ### Q25. „Ścieżka AOI” w MVP — przybliżenie czy nic? **Pytanie:** Czy akceptujemy przybliżenie „ścieżki AOI” rankingiem AOI wg intensywności saliency (z adnotacją, że to nie jest prawdziwy scanpath), czy komponent czeka na model scanpath? *(§9.5)* +**Wyjaśnij dokładniej** ---