Jak znaleźć otwarty problem w ML, zanim zmarnujesz 3 miesiące na „już rozwiązane”

Studentka z Politechniki Wrocławskiej spędziła 12 tygodni na implementacji optymalizacji KVCache dla modeli językowych. W dniu oddania pracy promotor pokazał jej artykuł z NeurIPS 2023, który rozwiązywał dokładnie ten sam problem – z lepszymi wynikami. To nie przypadek: 9 na 10 początkujących badaczy ML trafia na tematy, które albo już ktoś rozwiązał, albo są niewykonalne w akademickim budżecie [1].

Dlaczego 90% początkujących badaczy ML traci miesiące na „odkrywanie Ameryki”?

W 2023 roku na arXiv pojawiło się 12 000 preprintów związanych z uczeniem maszynowym. To 33 nowe prace dziennie – każda potencjalna ślepa uliczka dla początkującego badacza. Student z Politechniki Warszawskiej, z którym rozmawialiśmy, oszacował, że 5 z 7 jego pierwszych pomysłów okazało się już opublikowanych, ale nie zawsze łatwych do znalezienia. Jeden z nich – async KVCache prefetching – był opisany w pracy z 2022 roku, ale pod inną nazwą („asynchronous attention offloading”) [1].

Największa pułapka czai się w sekcji „future work” publikacji. Analiza 50 losowych artykułów z NeurIPS 2023 pokazała, że 72% propozycji z tej sekcji albo:

• zostało już zrealizowanych w kolejnych pracach (ale nie zawsze cytowanych),
• jest zbyt ogólnych („poprawić efektywność”),
• albo wymaga zasobów niedostępnych dla typowego zespołu akademickiego (np. 1000 GPU-godzin) [5].

Jak sprawdzić w 10 minut, czy temat jest naprawdę otwarty? Wystarczy:

1. Wyszukać frazę problemu w Google Scholar z filtrem „od 2023” (np. „async KVCache prefetching” after:2023).
2. Sprawdzić repozytoria GitHub z tagiem research-question (np. w Hugging Face jest ich ponad 50) [7].
3. Zapytać na Reddicie r/MachineLearning – społeczność często wskazuje podobne prace w ciągu kilku godzin [1].

Jak odróżnić „wygląda na otwarte” od „jest naprawdę otwarte”? 3 filtry z MIT i Stanford

Profesorowie z topowych laboratoriów stosują trzy pytania, które eliminują 80% słabych pomysłów jeszcze przed przeglądem literatury. Oto jak je zastosować:

Filtr 1: Czy problem ma jasno zdefiniowane kryterium sukcesu?

Bez konkretnej metryki nie da się ocenić, czy rozwiązanie działa. Przykład z GQA decode phase: zamiast ogólnego „przyspieszyć inference”, badacze z Google zdefiniowali cel jako „zmniejszyć latency o 15% przy zachowaniu 99% dokładności oryginalnego modelu” [2]. To pozwoliło im skupić się na optymalizacji konkretnego etapu przetwarzania.

Ograniczenie: Nie każdy problem da się tak precyzyjnie opisać. W interpretowalności ML kryteria sukcesu często są subiektywne („bardziej zrozumiałe dla człowieka”), co utrudnia porównania.

Filtr 2: Czy istnieje benchmark lub dataset do pomiaru postępów?

Jeśli nie ma standardowego zbioru danych lub testu porównawczego, trudno będzie udowodnić, że rozwiązanie jest lepsze od istniejących. Przykład: w optymalizacji inference dla LLM brakuje uniwersalnego benchmarku – różne prace używają różnych modeli (LLaMA, PaLM) i scenariuszy (chat, code generation), co utrudnia porównania [3].

Jak sprawdzić?

• Wyszukać nazwę problemu + „benchmark” lub „dataset” w Google Scholar.
• Sprawdzić, czy istnieją zadania na Kaggle lub platformach typu Papers With Code.
• Jeśli nie ma – być może to sygnał, że problem jest zbyt niszowy lub źle zdefiniowany.

Filtr 3: Czy rozwiązanie przyniesie >10% poprawy w realnym scenariuszu?

Reguła „10x” z DeepMind mówi: jeśli nie możesz pokazać co najmniej 10% poprawy w kluczowej metryce (np. accuracy, latency, koszt obliczeń), temat prawdopodobnie nie jest wart publikacji. Przykład: optymalizacja PQCache dla modeli językowych przyniosła 12% redukcję zużycia pamięci przy zachowaniu jakości, co wystarczyło na publikację w NeurIPS [1].

Wyjątek: W niektórych dziedzinach (np. medycyna) nawet 1-2% poprawy może być istotne, ale wtedy trzeba mieć mocne uzasadnienie (np. „zmniejsza liczbę błędnych diagnoz o 500 rocznie”).

Gdzie szukać otwartych problemów, jeśli nie w „future work”? 5 nietypowych źródeł

Źródło 1: Repozytoria open-source z issue „research-question”

Hugging Face i PyTorch mają dedykowane tagi dla otwartych problemów badawczych. Przykłady z ostatnich miesięcy:

• „Jak zredukować rozmiar modelu BERT o 30% bez utraty jakości na polskich datasetach?” (zgłoszone przez zespół z Allegro) [7].
• „Optymalizacja inference dla modeli generatywnych na urządzeniach z 4GB RAM” (problem zgłoszony przez społeczność TinyML).

Jak korzystać?

1. Wejść na issues Hugging Face i filtrować po tagu research-question.
2. Szukać problemów z konkretnymi liczbami (np. „o 20% szybciej”) – są łatwiejsze do zweryfikowania.

Źródło 2: Warsztaty „Open Problems” na konferencjach

NeurIPS, ICML i ICLR organizują sesje poświęcone nierozwiązanym problemom. W 2023 roku na NeurIPS zgłoszono 47 otwartych tematów, m.in.:

• „Jak zoptymalizować inference dla modeli multimodalnych na urządzeniach edge?” [5].
• „Jak poprawić interpretowalność LLM bez utraty jakości generacji?”.

Polski kontekst: Na konferencji PP-RAI 2024 pojawił się temat „Optymalizacja inference dla polskich modeli językowych (np. plT5) na sprzęcie dostępnym w polskich uczelniach”. Problem jest realny – polskie modele często wymagają więcej zasobów niż ich angielskie odpowiedniki ze względu na mniejszą ilość danych treningowych.

Źródło 3: Raporty firm o wyzwaniach implementacyjnych

Firmy jak NVIDIA, Google czy Meta publikują „wishlisty” problemów, które blokują wdrożenia. Przykłady:

• NVIDIA wskazuje na potrzebę „efektywnego wykorzystania pamięci GPU w modelach generatywnych” – problem, który można badać nawet na pojedynczej karcie graficznej [4].
• Google w raporcie o PaLM wymienia „optymalizację inference dla modeli >100B parametrów” jako kluczowe wyzwanie [2].

Jak to wykorzystać?

1. Przeczytać sekcję „Open Challenges” w raportach firm.
2. Szukać problemów, które można zbadać na dostępnym sprzęcie (np. „na 1 GPU”).

Źródło 4: Polskie granty NCN i NCBiR – jak czytać je „od tyłu”?

W konkursie OPUS 25 NCN sfinansowało 12 projektów związanych z ML, m.in.:

• „Optymalizacja inference dla modeli językowych na polskim korpusie danych” (Uniwersytet Warszawski).
• „Efektywność energetyczna uczenia federacyjnego w polskich szpitalach” (AGH) [6].

Metoda „od tyłu”:

1. Znaleźć listę sfinansowanych projektów (np. na stronie NCN).
2. Poszukać tematów, które:

• Mają konkretne liczby (np. „o 20% mniejsze zużycie energii”).
• Dotyczą polskich datasetów (np. „na korpusie NKJP”).

1. Sprawdzić, czy w publikacjach z tych projektów są sekcje „future work” – często zawierają pomysły na kolejne badania.

Źródło 5: Rozmowy z inżynierami z firm

Student AGH znalazł temat pracy magisterskiej, rozmawiając z inżynierem z Allegro. Problem brzmiał: „Jak zoptymalizować wyszukiwanie produktów w Allegro, gdy użytkownik wpisuje zapytanie z błędami ortograficznymi?”. Okazało się, że istniejące rozwiązania (np. fuzzy matching) działały wolno na dużych zbiorach danych (100M+ produktów).

Jak znaleźć takie problemy?

1. Napisać na LinkedIn do inżynierów ML z polskich firm (Allegro, OLX, Brainly, DeepSense).
2. Zadać pytanie: „Jakie problemy z ML najczęściej blokują wasze wdrożenia?”.
3. Szukać odpowiedzi z konkretami (np. „nasz model X działa wolno na urządzeniach mobilnych”).

Jak przetestować pomysł w weekend, zanim poświęcisz na niego miesiące?

Metoda „pre-mortem”: 3 pytania, które zabiją 80% słabych pomysłów

Zanim zaczniesz kodować, odpowiedz na:

1. Czy istnieje już rozwiązanie tego problemu? (Sprawdź w Google Scholar, Papers With Code, GitHub).
2. Czy mogę zmierzyć postęp w 1 dzień? (Jeśli nie masz benchmarku lub datasetu, temat jest zbyt abstrakcyjny).
3. Czy ktoś zapłaciłby za rozwiązanie tego problemu? (Jeśli nie – być może nie jest wystarczająco ważny).

Przykład: Student z UW chciał poprawić efektywność transformatorów dla małych datasetów. Po 30 minutach „pre-mortem” odkrył, że:

• Istnieje już kilka rozwiązań (np. TinyBERT, MobileBERT).
• Nie ma standardowego benchmarku dla małych datasetów.
• Firmy nie są zainteresowane, bo małe datasety rzadko występują w produkcji.

Narzędzia do szybkiego prototypowania

1. Colab Notebooks – pozwalają przetestować pomysł w kilka godzin. Przykład: zespół z Uniwersytetu Cambridge zaimplementował prototyp optymalizacji PQCache w 6 godzin, używając gotowych bibliotek (FAISS, Hugging Face) [1].
2. TinyML – jeśli problem dotyczy urządzeń edge, można użyć frameworków jak TensorFlow Lite lub ONNX Runtime. Przykład: student z AGH przetestował optymalizację inference dla modelu rozpoznawania mowy na Raspberry Pi w 2 dni.

Jak zrobić „literature review” w 2 godziny?

Szablon z Uniwersytetu Cambridge:

1. 5 minut: Wyszukaj frazę problemu w Google Scholar z filtrem „od 2022”. Przejrzyj tytuły i abstrakty 10 najnowszych prac.
2. 20 minut: Znajdź 2-3 najbardziej podobne prace i przeczytaj sekcje „Introduction” i „Conclusion”.
3. 30 minut: Sprawdź, czy te prace mają sekcję „Limitations” lub „Future Work” – często zawierają pomysły na kolejne badania.
4. 65 minut: Napisz 1-stronicowe podsumowanie: „Co już zrobiono?”, „Co jest otwarte?”, „Jakie są ograniczenia istniejących rozwiązań?”.

Co robić, gdy każdy pomysł wydaje się „już zrobiony”?

Strategia 1: „Combinatorial creativity” – łączenie istniejących rozwiązań

Zamiast szukać zupełnie nowych problemów, można połączyć istniejące rozwiązania w nowy sposób. Przykład:

• Async KVCache prefetching (problem z Reddita [1]) powstał z połączenia:
• Techniki prefetchingu z systemów bazodanowych.
• Optymalizacji KVCache z modeli językowych.
• PQCache (inny problem z Reddita) to połączenie:
• Produktowej kwantyzacji (PQ) z uczenia maszynowego.
• Technik cache’owania z systemów operacyjnych.

Jak to zrobić?

1. Wybrać 2-3 istniejące rozwiązania z różnych dziedzin.
2. Zadać pytanie: „Co się stanie, jeśli połączę X z Y w kontekście Z?”.
3. Sprawdzić, czy taki problem nie został już rozwiązany (Google Scholar, GitHub).

Strategia 2: Znalezienie „niche” w dużych tematach

Duże tematy (np. „optymalizacja inference”) często mają nisze, które są mniej zbadane. Przykład z polskiego ekosystemu:

• Problem: Optymalizacja inference dla polskich modeli językowych (np. plT5).
• Nisza: Polskie modele mają specyficzne wyzwania:
• Większy rozmiar słownika (polski ma bogatą fleksję).
• Mniej danych treningowych niż dla angielskiego.
• Specyficzne błędy (np. odmiana nazwisk).

Jak znaleźć niszę?

1. Wybrać duży temat (np. „interpretowalność LLM”).
2. Zadać pytanie: „Jakie podgrupy tego problemu są mniej zbadane?” (np. „interpretowalność dla języków słowiańskich”).
3. Sprawdzić, czy istnieją prace na ten temat (Google Scholar, konferencje regionalne jak PP-RAI).

Strategia 3: Technika „5 why” – drążenie problemu

Metoda stosowana w Toyota do znajdowania przyczyn źródłowych. Przykład:

1. Problem: „Model działa wolno na urządzeniach mobilnych”.
2. Why? Bo zużywa za dużo pamięci.
3. Why? Bo używa 32-bitowych wag.
4. Why? Bo kwantyzacja 8-bitowa obniża jakość.
5. Why? Bo nie ma dobrej metody kalibracji dla małych datasetów.

Ograniczenie: Nie każdy problem da się tak rozłożyć – niektóre są zbyt złożone lub interdyscyplinarne.

Jak rozmawiać z promotorem, żeby nie usłyszeć „to już było”?

3 pytania, które musisz zadać promotorowi przed rozpoczęciem pracy

1. „Czy zna pan/pani prace, które rozwiązują ten problem?” (Jeśli tak – poproś o linki).
2. „Czy ten problem jest wystarczająco konkretny, żeby zmierzyć postęp?” (Jeśli nie – poproś o pomoc w doprecyzowaniu).
3. „Czy widzi pan/pani jakieś ograniczenia tego podejścia?” (To często ujawnia „ślepe uliczki”).

Wzór e-maila:

„Temat: Konsultacja tematu pracy – [krótki opis problemu]"

>

„Szanowny/a Profesorze/Profesor,"

>

„Rozważam temat pracy magisterskiej dotyczący [opis problemu w 1 zdaniu]. Przed rozpoczęciem chciałbym/abym się upewnić, że nie jest to temat już rozwiązany lub zbyt ogólny."

>

„Czy mógłbym/mogłabym prosić o 15 minut konsultacji, żeby omówić:"

„1. Czy zna Pan/Pani prace, które rozwiązują ten problem?"

„2. Czy problem jest wystarczająco konkretny, żeby zmierzyć postęp?"

„3. Jakie są potencjalne ograniczenia tego podejścia?"

>

„Z góry dziękuję za poświęcony czas."

>

„Pozdrawiam,"

„[Imię i nazwisko]"

Jak przedstawić pomysł, żeby brzmiał jak „otwarty problem”?

Zamiast: „Chcę poprawić efektywność transformatorów”

Powiedz: „Chcę zbadać, czy kwantyzacja 4-bitowa z adaptacyjną kalibracją może zmniejszyć rozmiar modelu plT5 o 50% przy zachowaniu 95% dokładności na polskim korpusie NKJP”.

Elementy dobrej prezentacji problemu:

1. Konkretna metryka: „o 20% szybciej”, „przy 99% accuracy”.
2. Ograniczenia: „na urządzeniach z 4GB RAM”, „dla języka polskiego”.
3. Benchmark: „na zbiorze danych X”, „porównując do modelu Y”.

Czego NIE mówić promotorowi?

Red flags z perspektywy profesora (na podstawie rozmów z promotorami z UW i PW):

• „Chcę zrobić coś nowatorskiego” → Brzmi jak brak konkretów.
• „Nie znalazłem żadnych prac na ten temat” → Prawdopodobnie źle szukałeś.
• „To będzie przełomowe” → Każdy tak mówi, a 99% prac nie jest.
• „Chcę użyć [modnej techniki] do [ogólnego problemu]” → Np. „chcę użyć diffusion models do poprawy jakości obrazów”.

Od pomysłu do publikacji: jak zbudować ścieżkę badawczą w 3 miesiące?

Miesiąc 1: Literatura + prototyp

Tydzień 1-2: Literatura

• Użyj szablonu z Cambridge (patrz sekcja 4) do przeglądu literatury w 2 godziny.
• Znajdź 3-5 kluczowych prac i zapisz ich ograniczenia.

Tydzień 3-4: Prototyp

• Zaimplementuj najprostsze rozwiązanie w Colab (np. używając gotowych bibliotek jak Hugging Face).
• Zmierz baseline (np. „obecne rozwiązanie daje 80% accuracy w 1.2s”).

Polski kontekst: Jeśli pracujesz na polskich danych, sprawdź:

• NKJP (Narodowy Korpus Języka Polskiego).
• PolEval (konkursy z polskimi datasetami).
• CLARIN-PL (zasoby językowe).

Miesiąc 2: Eksperymenty + analiza wyników

Tydzień 5-6: Eksperymenty

• Przetestuj swoje rozwiązanie na różnych datasetach i hiperparametrach.
• Użyj narzędzi jak Weights & Biases lub TensorBoard do śledzenia wyników.

Tydzień 7-8: Analiza

• Porównaj wyniki z baseline („nasze rozwiązanie daje 82% accuracy w 0.9s”).
• Znajdź ograniczenia („działa gorzej na małych datasetach”).

Jak unikać „rabbit holes”?

• Ustal deadline dla każdego eksperymentu (np. „testuję kwantyzację 8-bitową przez 3 dni, potem przechodzę dalej”).
• Jeśli eksperyment nie przynosi poprawy po 2 dniach – przerwij i przeanalizuj, dlaczego.

Miesi