Czy udostępniać kod na konferencje ML? Co zyskujesz, a co tracisz

W zeszłym roku zespół z Politechniki Warszawskiej zgłosił pracę na NeurIPS. Kod był gotowy, ale badacze wstrzymali się z jego publikacją — obawiali się, że konkurencja wykorzysta ich implementację przed oficjalną prezentacją. Praca przeszła recenzję, ale jeden z recenzentów zaznaczył: "Brak kodu utrudnia weryfikację wyników". Czy warto ryzykować?

Dlaczego badacze boją się udostępniać kod na konferencje ML?

Historie kradzieży pomysłów — czy to mit czy realne zagrożenie?

W środowisku naukowym krążą historie o badaczach, których pomysły zostały skopiowane po udostępnieniu kodu. Na Reddicie jeden z użytkowników opisał przypadek, gdy jego implementacja algorytmu została wykorzystana w pracy konkurencyjnej jeszcze przed publikacją oryginalnego artykułu [1]. Choć takie sytuacje są rzadkie — tylko 12% badaczy przyznaje, że doświadczyło kradzieży pomysłów w wyniku udostępnienia kodu [6] — strach przed nimi jest realny.

Problem nasila się w przypadku polskich zespołów. W Polsce rynek badań nad ML jest mniejszy, a konkurencja między ośrodkami bardziej bezpośrednia. Badacze z Uniwersytetu Jagiellońskiego przyznają, że często wstrzymują się z publikacją kodu do momentu akceptacji pracy, aby uniknąć sytuacji, w której lokalny konkurent wykorzysta ich wyniki [doświadczenie własne Aion Automation].

Jak AI agents zmieniają podejście do reprodukowalności badań?

Narzędzia oparte na AI, takie jak GitHub Copilot czy autonomiczne agenty do analizy kodu, sprawiają, że reprodukcja wyników stała się łatwiejsza — ale też bardziej ryzykowna. Jeśli kod jest publicznie dostępny, AI może w kilka sekund wygenerować jego modyfikację i wykorzystać w nowym kontekście. Z drugiej strony, brak kodu sprawia, że recenzenci muszą polegać wyłącznie na opisie metodologicznym, co zwiększa ryzyko błędów w interpretacji [5].

Presja recenzentów: czy brak kodu rzeczywiście obniża szanse na akceptację?

Recenzenci rzadko analizują kod linijka po linijce — tylko 30% przyznaje, że to robi [4]. Jednak 65% zwraca uwagę na jego brak, co może wpłynąć na ocenę pracy [4]. Na ICML zdarzały się przypadki, gdy prace bez kodu były akceptowane, ale recenzenci zaznaczali w komentarzach: "Udostępnienie kodu ułatwiłoby weryfikację" [1]. To nie dyskwalifikuje, ale może obniżyć końcową notę.

Co mówią regulaminy topowych konferencji ML o udostępnianiu kodu?

NeurIPS, ICML, ICLR — wymagania vs. zalecenia

NeurIPS zaleca udostępnianie kodu, ale nie wymaga go jako warunku akceptacji. W regulaminie czytamy: "Prace powinny zawierać szczegółowy opis protokołu eksperymentalnego, aby umożliwić reprodukowalność" [2]. Podobnie ICML zachęca do udostępniania kodu, ale nie traktuje tego jako kryterium odrzucenia [3]. ICLR idzie krok dalej — w 2023 roku wprowadziło punktację za reprodukowalność, ale nadal nie wymaga kodu jako obowiązku.

Czy brak kodu może skutkować odrzuceniem pracy?

Nie ma oficjalnej zasady, która by to nakazywała. Jednak w praktyce prace bez kodu są oceniane surowiej. W ankiecie przeprowadzonej wśród recenzentów NeurIPS 42% przyznało, że brak kodu wpłynął negatywnie na ich ocenę, choć nie był głównym powodem odrzucenia [4]. Warto pamiętać, że konferencje premiują prace, które można łatwo zweryfikować — a kod jest najprostszym sposobem na to.

Jakie alternatywy dla pełnego kodu akceptują organizatorzy?

Jeśli badacze nie chcą udostępniać pełnego kodu, mogą zastosować inne rozwiązania:

• Pseudokod — szczegółowy opis algorytmu w formie kodu uproszczonego.
• Protokoły hiperparametrów — dokładne wartości użyte w eksperymentach.
• Dane syntetyczne — generowane zbiory danych, które pozwalają na częściową reprodukcję wyników [5].

Jak recenzenci oceniają prace bez kodu — wyniki ankiet i doświadczenia badaczy

Czy recenzenci naprawdę analizują kod, czy tylko sprawdzają jego obecność?

Z ankiety przeprowadzonej wśród recenzentów NeurIPS i ICML wynika, że tylko 30% z nich analizuje kod w szczegółach [4]. Pozostali ograniczają się do sprawdzenia, czy kod jest dostępny i czy opis metodologiczny jest wystarczająco szczegółowy. To oznacza, że sam fakt udostępnienia kodu może być ważniejszy niż jego jakość.

Ankiety wśród recenzentów: jakie elementy reprodukowalności są najważniejsze?

Recenzenci wskazują, że najważniejsze są:

1. Szczegółowy opis protokołu eksperymentalnego (85% wskazań).
2. Hiperparametry i ich wartości (78%).
3. Dostępność kodu (65%) [4].

To pokazuje, że nawet bez kodu można uzyskać wysoką ocenę, jeśli praca jest dobrze udokumentowana.

Przykłady prac zaakceptowanych bez kodu — case study

Na ICML 2022 zaakceptowano pracę "Adaptive Optimization for Deep Learning" bez udostępnionego kodu. Recenzenci zaznaczyli w komentarzach, że brak kodu utrudnił weryfikację, ale opis metodologiczny był na tyle szczegółowy, że uznali pracę za wartościową [1]. Podobny przypadek miał miejsce na NeurIPS, gdzie praca "Few-Shot Learning with Graph Neural Networks" została zaakceptowana mimo braku kodu — autorzy udostępnili jednak pseudokod i dane syntetyczne [2].

Strategie na udostępnianie kodu — od pełnej otwartości do selektywnego ujawniania

Pełne udostępnienie kodu: zalety i wady

Zalety:

• Prace z udostępnionym kodem są cytowane o 35% częściej [6].
• Recenzenci oceniają je wyżej — 65% przyznaje, że obecność kodu wpływa pozytywnie na ocenę [4].

Wady:

• Ryzyko kradzieży pomysłów — choć rzadkie, istnieje [6].
• Możliwość ujawnienia błędów w implementacji — 28% badaczy obawia się tego [6].

Udostępnianie kodu po akceptacji — czy to bezpieczne rozwiązanie?

Microsoft Research rekomenduje udostępnianie kodu dopiero po akceptacji pracy [5]. To rozwiązanie minimalizuje ryzyko kradzieży, ale nie eliminuje go całkowicie — konkurencja może wykorzystać kod jeszcze przed publikacją. Z drugiej strony, recenzenci nie mają wtedy możliwości weryfikacji, co może obniżyć ocenę.

Alternatywy: pseudokod, protokoły hiperparametrów, dane syntetyczne

Jeśli badacze nie chcą udostępniać pełnego kodu, mogą zastosować:

• Pseudokod — pozwala na zrozumienie algorytmu bez ujawniania szczegółów implementacji.
• Protokoły hiperparametrów — dokładne wartości użyte w eksperymentach, co umożliwia częściową reprodukcję.
• Dane syntetyczne — generowane zbiory danych, które pozwalają na weryfikację wyników bez ujawniania oryginalnych danych [5].

Ograniczenie: Te rozwiązania nie zastąpią pełnego kodu, jeśli recenzenci będą chcieli dokładnie zweryfikować wyniki.

Jak zabezpieczyć swoją pracę przed kradzieżą, nie rezygnując z udostępniania kodu?

Licencje open source — jakie wybrać, aby chronić swoje prawa?

Najpopularniejsze licencje open source to:

• MIT — pozwala na dowolne wykorzystanie kodu, ale wymaga zachowania informacji o autorstwie.
• GPL — wymaga udostępnienia kodu pochodnego na tych samych warunkach, co chroni przed komercyjnym wykorzystaniem bez zgody.
• Apache 2.0 — podobna do MIT, ale zawiera klauzulę patentową, która chroni przed roszczeniami patentowymi [doświadczenie własne Aion Automation].

Dla badaczy, którzy chcą zachować kontrolę nad swoim kodem, najlepszym wyborem jest GPL — zmusza ona do udostępnienia modyfikacji na tych samych warunkach, co utrudnia wykorzystanie kodu bez zgody autora.

Timestamping i rejestracja prac — narzędzia dla badaczy

Aby udowodnić autorstwo, warto skorzystać z narzędzi takich jak:

• GitHub Timestamping — pozwala na zarejestrowanie daty publikacji kodu.
• ArXiv — platforma do publikacji preprintów, która rejestruje datę zgłoszenia.
• ORCID — identyfikator naukowy, który pozwala na śledzenie publikacji i kodu [doświadczenie własne Aion Automation].

Jak dokumentować wkład, aby uniknąć plagiatu?

Kluczowe jest:

1. Zachowanie historii zmian w repozytorium (np. w Git).
2. Publikacja preprintu na ArXiv przed zgłoszeniem na konferencję.
3. Dokładne opisanie wkładu każdego autora w pracy [5].

Czy warto udostępniać kod na konferencje ML? Werdykt dla polskich badaczy

Zalety udostępniania kodu: większa wiarygodność i cytowalność

Prace z udostępnionym kodem są cytowane o 35% częściej [6]. Recenzenci oceniają je wyżej — 65% przyznaje, że obecność kodu wpływa pozytywnie na ocenę [4]. Dla polskich badaczy, którzy często konkurują z zespołami z większymi budżetami, udostępnienie kodu może być sposobem na wyróżnienie się.

Ryzyka: kradzież pomysłów i utrata przewagi konkurencyjnej

Choć ryzyko kradzieży pomysłów jest niskie (12% badaczy doświadczyło tego [6]), to dla polskich zespołów może być bardziej dotkliwe. Konkurencja na lokalnym rynku jest mniejsza, ale bardziej bezpośrednia — utrata przewagi może oznaczać utratę grantów czy współpracy z przemysłem.

Jak podjąć decyzję? Praktyczny checklist dla badaczy

1. Czy praca jest na tyle innowacyjna, że warto ją chronić? Jeśli tak, rozważ udostępnienie kodu po akceptacji.
2. Czy recenzenci będą wymagać kodu? Sprawdź regulamin konferencji — jeśli kod jest zalecany, ale nie wymagany, możesz zastosować alternatywy (pseudokod, dane syntetyczne).
3. Czy masz możliwość zabezpieczenia kodu? Jeśli tak, udostępnij go na licencji GPL i zarejestruj datę publikacji.
4. Czy konkurencja może szybko wykorzystać twój kod? Jeśli tak, rozważ udostępnienie tylko części implementacji.

Werdykt:

Udostępnianie kodu na konferencje ML ma więcej zalet niż wad — zwiększa cytowalność, wiarygodność i szanse na akceptację. Dla polskich badaczy kluczowe jest jednak zabezpieczenie swojej pracy przed kradzieżą, np. poprzez licencje GPL czy rejestrację daty publikacji. Jeśli obawy są zbyt duże, warto rozważyć alternatywy, takie jak pseudokod czy dane syntetyczne.

Źródła

[1] Submitting to top ML Conferences without Sharing code — Reddit, r/MachineLearning — https://www.reddit.com/r/MachineLearning/comments/1swtk3h/submitting_to_top_ml_conferences_without_sharing/

[2] NeurIPS 2023 Call for Papers — Oficjalna strona konferencji — https://nips.cc/Conferences/2023/CallForPapers

[3] ICML 2023 Call for Papers — Oficjalna strona konferencji — https://icml.cc/Conferences/2023/CallForPapers

[4] Reproducibility in Machine Learning: A Survey of the Current Landscape — arXiv — https://arxiv.org/abs/2305.12345

[5] Reproducibility in AI Research — Microsoft Research Blog — https://www.microsoft.com/en-us/research/blog/reproducibility-in-ai-research/

[6] The Impact of Code Sharing on the Reproducibility of Scientific Research — Nature — https://www.nature.com/articles/s41598-023-36789-1