Tematy projektów WSHOP -- wiosna 2025/2026

• : Possibility of extending it to master thesis
• : Quick project
• : Linked to international scientific project
• : Linked to JU-internal scientific project

• Student:
• Namespace in the wiki: FIXME
• The goal of the project:
• Technology:
• Description:
• Links:
  • 

• Student:
• Namespace in the wiki:
• The goal of the project: Conducting a experiment, to gather data from 100-150 participants
• Technology: Set of sensors (eyetracker, EDA, ECG), in-house procedure for gathering data including sets of stimuli and afective game(ShroomDoom)
• Description: Assistance in conducting an experiment on affective computing. The aim of the experiment is to perform fundamental research to collect data for studies on the recognition of the affective states of subjects in the context of measurements from sensors with different modalities.
• Links: https://afcai.re/pub:biraffe:biraffe3

• Student: Justyna Gargula,
• Namespace in the wiki: FIXME
• The goal of the project: Development of a tool for generating thematic narratives based on JBC objects (social life documents) (part 2)
• Technology: Python, RDFLib, LLM/GPT API, Streamlit, Google GenAI (Gemini API), RDFLib, Plotly, Pandas, requests, opcjonalnie: Cornac, GeoNames API / geopy, NetworkX / PyVis, spaCy, ChromaDB / FAISS, Elasticsearch (ES)
• Description: This project integrates metadata from social life document collections of the JBC into a knowledge graph to create semantic connections between people, places, events, and objects. Using GPT-based methods, the system generates thematic, chronological, or stylistic narratives that present historical materials in the form of timelines, maps, or continuous digital stories, supporting contextual discovery in historical and educational research.The project also develops new exploration tools (e.g., character relationship maps), interactive storytelling features, GeoNames integration, text-based queries, recommendation and personalization mechanisms, and improved UI with micro-interactions. Additionally, a continuous UX evaluation module will enable users to provide immediate in-app feedback on generated stories and timelines.
• Links: https://jbc.bj.uj.edu.pl/dlibra/results?q=&action=SimpleSearchAction&type=-6&p=0&qf1=collections%3A188&qf2=Subject%3AKrak%C3%B3w%20%28Polska%20%3B%20region%29&qf3=Subject%3AII%20wojna%20%C5%9Bwiatowa%20%281939-1945%29&qf4=Subject%3Adruki%20ulotne%20z%20lat%201939-1945&qf5=Subject%3Adruki%20ulotne%2021%20w.&qf6=Subject%3Ateatr%20polski%2019%20w.&qf7=Subject%3Ateatr%2019%C2%A0w.&qf8=Subject%3ATeatr%20Polski%20%28Krak%C3%B3w%29&qf9=Subject%3ADrukarnia%20%E2%80%9ECzasu%E2%80%9D%20%28Krak%C3%B3w%29&qf10=Subject%3ATowarzystwo%20Artyst%C3%B3w%20Dramatycznych&qf11=Subject%3AMa%C5%82opolska%20%28Polska%20%3B%20wojew%C3%B3dztwo%29&qf12=Subject%3ATeatr%20%C5%81%C3%B3dzki%20%28Polska%29&qf13=Subject%3Aliteratura&qf14=Subject%3Aafisz%20muzyczny&ipp=50

• Student: Bartosz Majkowski, Kacper Mielniczek
• Namespace in the wiki: chcloud
• The goal of the project: Validate the usability of Wikidata as a central point of cultural heritage data cloud
• Technology: RDF/Semantic Web, some programming (Python preferred)
• Description: Wikidata has many links to external sources of information (URIs/foreign keys), but are these links correct? Can additional information be extracted from these sources, or do these pages not contain any data that can be processed automatically? Previous project (chcloud) started exploration of this topic (validation of some links, basic data extraction). Now, we want to continue it and: (a) check whether this process can be automated, (b) prepare a knowledge graph that will combine this data into a single cultural heritage data cloud [for the purposes of the project, we will probably limit it to individuals associated with the University], (c) evaluate such a graph (including comparison with a graph containing only data from Wikidata)

• Student: Adam Lisik, Kacper Kula, Rafał Bernacki
• Namespace in the wiki: iconclass
• The goal of the project: Extend the existing prototype of ICONCLASS-based classification and recommendation modules
• Technology: RDF/Semantic Web, Python, ML basics
• Description: Iconclass is a very complex system for classifying objects depicted in artworks, covering real objects, various scenes, and abstract concepts. It has been used for many years by experts to tag artworks. We want to help them do this, so we have created a prototype tool that first assigns tags (classification) and then recommends related artworks. As part of this project, we want to expand this tool. Directions for development: (a) Detection fine-tuning: find Iconclass-labeled datasets and fine-tune YOLO (or other object-detection model), (b) Multimodal classification: not only YOLO, but also textual metadata, iconographic labels, neural image features, and even visin-language embeddings like CLIP can help in better classification, (c) expand rule engine for abstract codes inference: rules can be mined semi-automatically from large Iconclass-labeled corpora (with frequent pattern mining over code co-occurrences), (d) recommendation module: create unified recommender (now, we have three recommenders), add explainability layer. There is also a place for your ideas :)
• Links:
  • Paper with current status: Iconographic Classification and Content-Based Recommendation for Digitized Artworks

• Student: Piotr Wójtowicz, Jakub Dziurka
• Namespace in the wiki: graphrecs
• The goal of the project: Extend the existing recommendation workflow to include expert knowledge, an evaluation interface with explanations for experts, and user interface for final users
• Technology: RDF/Semantic Web, SPARQL, Python, recommendation systems, knowledge graph embeddings, XAI
• Description: We have developed a prototypical recommendation system for cultural heritage knowledge graphs and evaluated it within CHExRISH project (see this paper). Even if the results obtained are promising, it turned out that our recommendations do not coincide with those of the experts (i.e., the experts propose different nodes in the graph than the model we prepared). Why? Are experts interested in specific relationships in the graph? Do experts focus only on the significant nodes? Or do experts use some knowledge that is not reflected in the graph? (a) Investigating this is the first goal of the project. In addition: (b) based on the results of the investigation, we want to extend the recommendation module to take them into account (this may require improving SPARQL-based filtering), © we want to prepare an interface for experts that will allow them to evaluate recommendations and enter their own recommendations (by selecting nodes in the graph), (d) the whole process may ultimately become a closed workflow that iteratively improves the model in accordance with the knowledge provided by experts. We also want to (e) prepare an interface for end users: based on the selected node, it suggests several related nodes.
• Links:
  • Paper with our recommender system: A Three-stage Neuro-symbolic Recommendation Pipeline for Cultural Heritage Knowledge Graphs

• Student: Witold Węglarz, Nikodem Piechulski
• Namespace in the wiki: graphpaths
• The goal of the project: Prepare a tool that visualizes connections between two or more nodes in a graph along with their relevant context
• Technology: RDF/Semantic Web, some programming (Python is preffered), vizualization, LLMs
• Description: At the input, we have an arbitrarily large knowledge graph in RDF format and two or more nodes, e.g., a target and its recommendation as in the project described in this paper. The goal of the project is to develop visualizations that will help the user understand the real connections between these nodes. As part of the project, we want to explore the following scenarios: (a) direct paths: find the shortest path and visualize it, (b) informed-shortest path: in the above-mentioned project, the recommendation module provides information why the following node was proposed; this information can be used in the visualization, © provide the context: check which nodes in the environment are relevant (e.g., using centrality measures) and add them to the visualization, (d) use more than two nodes: e.g., use target and more than one recommendation, (e) we also want to explore the possibility of using language models to summarize the generated paths/visualizations.
• Links:
  • Paper with our recommender system: A Three-stage Neuro-symbolic Recommendation Pipeline for Cultural Heritage Knowledge Graphs

• Student:
• Namespace in the wiki:
• The goal of the project: Applying KG discovery algorithms to digital humanities KG
• Technology: RDF, Python
• Description: This project applies KG discovery algorithms to find interesting and non-obvious relations within digital humanities KGs, using the CIDOC-CRM ontology as a case study. It explores serendipitous discovery, path evaluation, and pattern identification. Graph-based models enable this because they facilitate algorithmic exploration of linked cultural heritage data.
• Links:
  • Serendipitous knowledge discovery
  • Woolnet: finding and evaluating paths in knowledge graphs

• Student:
• Namespace in the wiki:
• The goal of the project: Applying network analysis to digital humanities KG
• Technology: RDF, Python
• Description: This project uses network analysis methods (degree, eigenvector, PageRank centrality, community detection) to reveal patterns, central entities, and relationships in cultural heritage KGs based on CHExNET (https://zenodo.org/records/18715362). The aim is to identify structural properties and key nodes to aid interpretation and support research within cultural heritage contexts.
• Links:
  • Network analysis in the humanities explained
  • Example network analysis

• Student:
• Namespace in the wiki:
• The goal of the project: Implementing a tool for automatic KG shortcut generation
• Technology: RDF, Python, LLM
• Description: This project automates the creation of KG “shortcuts,” which are derived relations that simplify navigation, querying, and graph algorithm usage in complex ontologies like CIDOC-CRM. Shortcuts may omit certain reifications or events, making knowledge graphs easier to traverse and analyse. The approach should be generalizable beyond CIDOC-CRM. LLLMs can perhaps be used for this task.
• Links:
  • CIDOC-CRM
  • Paths and shortcuts in knowledge graphs

• Student:
• Namespace in the wiki:
• The goal of the project: Creating a scientifric report including short experiments on perplexity as agent evaluation metric
• Technology: Python, LLM
• Description: Understanding what metrics are used for evaluating LLM-based agents, experimenting with some models, evluating if adding perplexity metrics to the evaluation can increase the explanation of the evaluations, discover other metrics that are also related to “training data” that are perhaps more effective, studying the limitations of usinf perplexity metrics.
• Links:
  • Perplexity measure and prompt quality
  • More about perplexity

• Student:
• Namespace in the wiki: tgnnx
• The goal of the project: Celem projektu jest integracja algorytmu ACFX do generowania wyjaśnień kontrfaktyczncyh z grafowymi sieciami neuronotymi dla szergów czasowych.
• Technology: Python

* Description:

• Wybór problemu i danych (przykladowy zbiór i implementacja będą dane, ale możliwa zmiana na coś prostszego): prosta klasyfikacja/regresja na grafach czasowych (np. ruch/obciążenie, prosty syntetyczny graf czasowy lub mały benchmark z PyG-Temporal).
• Model bazowy: implementacja prostego TGN
• Adapter ACFX:
  • zdefiniowanie celu kontrfaktu (zmiana klasy / przesunięcie wartości wyjścia),
  • przestrzeń dozwolonych zmian (węzły, krawędzie, atrybuty; ograniczenia „realizmu”),
  • funkcja straty kontrfaktu (fidelity + sparsity + plausibility).
• Ewaluacja: fidelity/validity kontrfaktów, koszt (liczba zmienionych cech), stabilność w czasie (czy kontrfakt „utrzymuje” efekt w kolejnych krokach).
• Demo: notebook + krótkie CLI do wygenerowania kontrfaktu dla wskazanego węzła/czasu.

* Links:

• ACFX – dokumentacja
• PyTorch Geometric Temporal
• PyTorch Geometric

• Student:
  • GrupaA:
  • GrupaB:
  • GrupaTGNN:
• Namespace in the wiki: ecgA, ecgB, ecgtgnn
• The goal of the project: Stworzenie autoenkodera dla szeregów EKG i analiza latent‑space (UMAP/t‑SNE) pod kątem lokalizacji jednostek chorobowych, płci i innych metadanych; w drugiej części – prosta klasyfikacja na wektorach latentnych.
• Technology: Python
• Dane i preprocessing:
  • wybór publicznego zbioru (np. PTB‑XL) (dostępna wersja już po preprocesingu na łame chunk równej długości)
• Model:
  • 1D‑CNN/Transformer/LSTMConv autoencoder (rekonstrukcja sygnału),
  • ekstrakcja wektorów latentnych.
• Analiza latent‑space:
  • wizualizacja (UMAP/t‑SNE),
  • klasyfikacja/klasteryzacja (LR/SVM/MLP) na latentach dla: diagnoz, płci, wieku (jeśli dostępne).
• Ewaluacja:
  • rekonstrukcja (MSE/MAE),
  • klasyfikacja (Accuracy/F1/AUROC lub w przypad),
  • inspekcja „czytelności” latentów (separowalność klas).
• Deliverables: notebooki, raport PDF, wykresy latent‑space.

* Links:

• Publiczny zbiór danych (opis PTB‑XL)
• PTB‑XL na PhysioNet

• Student:
• Namespace in the wiki: tgnnx
• The goal of the project: Celem projektu jest dodanie funkcjonalności generowania kontrfaktów dla regresji do oprogramowania ACFX
• Technology: Python
• Description:
  • Specyfikacja regresyjna:
    • funkcja celu dla zmiany wartości wyjścia (np. osiągnięcie y\* lub przesunięcie o Δ),
  • Implementacja:
    • adapter/loss pod regresję juz istniejacego kodu (w praktyce bedzie koneiczna lekka modyfikacja juz istniejacej funkcji kosztu i wsparcie dla innego rodzaju modeli )
  • Ewaluacja:
    • zbiory tablicowe (np. UCI – małe, łatwe do replikacji),
    • metryki: validity (osiągnięcie celu), proximity, sparsity, czas obliczeń,
    • porównanie z prostymi baseline’ami (gradient/sign, DiCE – jeśli dostępny).
  • Demo: krótki notebook + integracja z dashboardem ACFX i przetestowanie czy aplikacja streamlit też działa z modelami regresyjnymi
• Links:
  • ACFX
  • Streamplit dashboard

• Student:
• Namespace in the wiki: tgnnx
• The goal of the project: Celem projektu jest zintegrowanie w całość ewaluacji generowania kontrfaktó dla algorytmów detekcji anonalii
• Technology: Python, PyTorch
• Description: W szczególności chodzi o integracje w jeden ewaluacyjny pipeline nastepujacych algorytmów i wykonanie analizy danych na bazie tej ewalyacji które pozwoli określić
  1. Algorytmy: RIAD, InTra, AMI-Net,FAIR,DFMGAN,AnoStyler.
  2. Algorytm detekcji anomalii PatchCore, Padim, DFM, i inne z paczki anomalib
  3. Budujemy detektor anomalii, nastepnie dla każdego detektora budujemy kontrfakty każym algorytmem wymienionym wopisie, następnie przeprowadzamy ewaluację wyników. Kontrfakty maja działąć w dwie strony (dl kalsy normal generują abnormal, dla klasy abnormal generują normal)
• Links:
  • Zestaw gotowych implementacji (prawie wszystkich)

• Student: Igor Zamojski, Jakub Budzyński
• Namespace in the wiki: winclipA winclipB
• The goal of the project: Zbudować prosty pipeline demonstracyjny, w którym model WinCLIP (zero-/few-shot na bazie CLIP) wykrywa i segmentuje anomalie na wybranych klasach z MVTec AD i/lub VisA, a wynik modelu jest od razu IRI węzła w małym grafie wiedzy (RDF). Następnie, z poziomu UI można wykonać zapytania (SPARQL) o zalecane działania/mitigacje dla danej anomalii
• Technology:
• Description:
  1. Wybór danych (mały wycinek): na start 2 klasy z MVTec AD (np. bottle, screw) lub z VisA (np. candle, capsules) – tak, by mieć parę typów defektów (np. scratch, contamination, missing part).
     1. Inference WinCLIP (zero-/few-shot): uruchomienie gotowej implementacji WinCLIP z prostą ensemble‑prompting dla stanów „normalny/anomalny + typ” (bez trenowania). Dla demonstracji wystarczy zero‑shot; ewentualnie few‑shot z 1–2 obrazami „good”.
     2. Mapowanie → węzeł KG: wynik (etykieta/typ defektu) zamieniamy na konkretny IRI, np. ex:defect/visa/scratch lub ex:defect/mvtec/contamination. W RDF tworzymy minimalne klasy:

    ex:DefectType (np. scratch, contamination),
    ex:Cause (np. abrasive_contact),
    ex:Action (np. line_stop, replace_guide_rail).
    

1. Zapytania / rekomendacje: proste kwerendy SPARQL: „podaj ex:recommendedAction dla danego ex:DefectType” + wyświetlenie w UI wraz z podglądem maski.
2. Ewaluacja (lekka): dla wybranej klasy raportujemy i‑AUROC/p‑AUROC oraz zrzuty ekranu; celem jest działający demo‑flow, nie bicie SOTA. (WinCLIP raportuje wysokie wyniki na MVTec/VisA w warunkach zero/few-shot – nasz cel to tylko potwierdzić działanie na małej próbce). ONtologia, rekomendacje/akcje – moga byc nieprawdziwe, chodzi tylkok o demo mozliwosci.

• Links:
  • WinCLIP (poszukaj arXiv/implementacji – do uzupełnienia)
  • MVTec AD
  • VisA
  • SOSA/SSN
  • SAREF4INMA
  • RDFLib
  • Apache Jena Fuseki
  • FOCUSING BY CONTRASTIVE ATTENTION: ENHANCING VLMS’ VISUAL REASONING

• Student: BRAK MIESC!
• Namespace in the wiki: xaifungiA, xaifungiB, xaifungiC, xaifungiD
• The goal of the project: Celem pracy jest wykorzystanie zbioru dancyh XAI-FUNGI do klasyfikacji grupy osób na bazie dialogów/akcji użytkownika.
• Technology: Python, text analysis,
• Description: Zbiór XAI-FUNGI zawiera transkrypcje wywaidów z ekspertami, studentami informatykami i studentami studiów nieinformatycznych. Każdy transkrypt jest plikiem CSV, z wydzielonymi fragmentami w których uczestnik analizuje na głos wybrany element charaktecryzujacy model do klasyfikacji grzybów. Celem jest zbudownaie klasyfikatora, który będzie staral się określić do jakiej grupy należy dany użytkownik, bazujać na tych transkrypcjach.
• Links:
  • XAI-FUNGI
  • Robimy forka tego repozytorium i pracujemy na forku!: Starting point GitHub

• Student:
• Namespace in the wiki: pytracker
• The goal of the project: Celem pracy jest przetestowanie funkconoalności narzędzia do mapowania wzroku (uwagi) użytkownika na różne modelaności (tekst, obraz, szeregi czasowe), oraz implementacja customowego daatsetu dla EKG,
• Technology: Python, Psychopy, Tobii Eyetracker
• Description: Nowy ECGTSDataset który będzie dziedziczył po istniejąceym TimeSereisDataset, ale skupiał sie będzie na poprawnej wizuzalizacji EKG z wykorzystaniem wizualizacji mitującej papier milimetrowy i z zachowaniem skali i odstępów niezb ednych do porpawnej analizy. Przykłady, wizualizacje, analizy wyników.
• Links:
  • TobiiPytracker

• Student:
• Namespace in the wiki: llm_ctx_attr
• The goal of the project: Zbudować działający pipeline do ilościowego i wizualnego badania, jak poprzednia tura (t‑1) wpływa na odpowiedź w turze (t) w LLM. Projekt łączy atrybucję gradientową (Integrated Gradients/SHAP, toolkit Inseq) z testami przyczynowymi (activation/causal patching na TransformerLens/causal‑tracer), raportując m.in. „udział t‑1” w logitach odpowiedzi oraz logit‑difference w testach interwencyjnych.
• Technology:
  • Hugging Face Transformers (małe modele dekoderowe; inference + logprobs/score)
  • Inseq – IG/Grad×Input dla LLM (wizualizacja atrybucji kontekst→odpowiedź)
  • TransformerLens – hooki, cache aktywacji; causal/activation patching (best‑practices)
  • causal‑tracer – „causal flow/patching” i heatmapy
• Description:
  • Dane (mały, kontrolowany korpus): pary *(t‑1, t)*, gdzie w *t‑1* znajduje się fakt/warunek potrzebny do odpowiedzi w *t* (np. „Hasło: ALFA” → „Podaj hasło”).
  • Modele i uruchomienie: niewielki model dekoderowy (GPT‑2‑klasa / mały LLaMA) z dostępem do aktywacji/logprobs.
  • Baseline zachowania (2 warianty):
    • (a) `[t‑1 || t]` (pełny kontekst),
    • (b) `[t]` (bez *t‑1*),
    • (c ) sesyjny z KV‑reuse (prefill *t‑1*, potem *t*)
  • Atrybucja IG/SHAP (Inseq): IG dla kluczowych tokenów odpowiedzi względem tokenów wejścia (w tym *t‑1*); metryka „udział t‑1” = % sumarycznej atrybucji przypisanej tokenom *t‑1*; heatmapy (kontekst→odpowiedź).
  • Causal/activation patching – test przyczynowy (faithfulness):
    • „Corrupt → Clean”: zaszum/wyzeruj kluczowe tokeny w *t‑1* (prompt „corrupt”), następnie patch czystych aktywacji tylko dla tych tokenów (per warstwa/głowa).
    • Metryka: logit‑difference dla poprawnych tokenów odpowiedzi; silny wzrost po patchingu = dowód przyczynowego użycia fragmentów *t‑1*.
• Porównanie: korelacja rankingów ważności tokenów *t‑1* (IG vs patching); różnice między (a)/(b).
  • Raport: metryki (udział t‑1, logit‑difference, zmiana logprobs, zgodność IGpatching )

Links:

• Inseq – feature attribution for generative LMs
• TransformerLens – mechanistic interpretability / hooki
• causal‑tracer – causal tracing/patching
• Logprobs – przykłady

• Student:
• Namespace in the wiki: decboundcomp
• The goal of the project: Badania nad różnymi metodami, które mogą być wykorzystane do opisu lub pomiaru różnic w granicy decyzyjnej klasyfikatora w kontekście danych syntetycznych
• Technology: Python
• Description: Mając dwa modele wytrenowane do tego samego zadania, jak wyjaśnić różnice pomiędzy nimi? Odnosi się to do problemu uchwycenia, zmierzenia i opisania Efektu Rashomona. To zadanie przenosimy teraz na dwa (lub więcej) modele wytrenowane na danych rzeczywistych oraz syntetycznych — co możemy powiedzieć o jakości danych syntetycznych, patrząc wyłącznie na własności zbioru Rashomona? Możemy zacząć od danych tabelarycznych, ale warto także spróbować na wizualnych zbiorach do detekcji anomalii (zobacz inny projekt dotyczący benchmarkowania kontrfaktycznych metod detekcji anomalii).
• Links:
  • RashomonEfect analysis
  • What’s Wrong with Your Synthetic Tabular Data?
  • Explainable Artificial Intelligence: xAI 2025 – Generative AI Meets XA
  • Explainable Artificial Intelligence for Deep Synthetic Data Generation (IEEE)

• Student:
• Namespace in the wiki: VKchallenge
• The goal of the project: Tune and prepare existing code for submission in an open challenge
• Technology: Python, spaCy, LightGBM, scikit-learn
• Description: “Given a (potentially obfuscated) text, decide whether it was written by a human or an AI. … Participants will submit their systems as Docker images through the Tira platform. It is not expected that submitted systems are actually trained on Tira, but they must be standalone and runnable on the platform without requiring contact to the outside world. The submitted software must be executable inside the container via a command line call.” You'll be provided with the last year's code and data. Your primary task is to incorporate at least one of the baselines into our own code and / or adding obfuscation to the training data.
• Important dates: May 07, 2026: software submission; May 28, 2026: participant notebook submission“
• Links:
  • Voight-Kampff Generative AI Detection 2026
  • Our last year's submission

• Student:
• Namespace in the wiki: MAPLE
• The goal of the project: Expand our dataset with parallel multilingual data in various domains and analyse the dataset quality
• Technology:
• Description: The dataset was developed as part of a master’s thesis project aimed at evaluating and comparing the quality of multilingual language model outputs, particularly focusing on low-/medium-resource languages. The dataset design is parallel, i.e., we want to maintain a considerable overlap between languages in terms of genres / topics / domains etc. at the level of individual texts. Currently, the dataset is based on Wikipedia summaries. The high priority goal is expanding the number of genres in a controlled way. You will be able to work on data collection, documentation, analysis, and quality assurance. The dataset will be openly available and citable at the OSF.io platform.

• Links:
  • View-only link of the dataset
  • Master thesis describing v1.0 of the dataset