Co się dzieje, gdy AI czyta specyfikację wymagań? Relacja z inżynierii kolejowej

Wprowadzenie

Co właściwie dzieje się, gdy systemowi AI przekazuje się specyfikację wymagań z 800 wymaganiami technicznymi i mówi: „Oceń to“? Odpowiedzią nie jest ani wizja science fiction w pełni zautomatyzowanej maszyny do tworzenia ofert, ani cyniczny wariant „nic użytecznego“. Rzeczywistość leży pomiędzy nimi i jest bardziej zniuansowana, niż sugeruje większość obietnic marketingowych dostawców AI.

W tym artykule krok po kroku opisujemy, co rzeczywiście dzieje się, gdy system AI przetwarza prawdziwą specyfikację wymagań z branży kolejowej. Tekst opiera się na doświadczeniach z realnymi dokumentami przetargowymi, w tym z miejscami, w których technologia działa, oraz tymi, w których zawodzi.

To pytanie nie jest akademickie. Według raportu Loopio 2025 RFP Response Trends & Benchmarks Report 68% zespołów ofertowych w różnych branżach korzysta już z generatywnej AI, czyli dwukrotnie więcej niż 34% w 2023 roku. Branża kolejowa jest w tym zakresie dopiero na początku drogi, mimo że wyspecjalizowane platformy, takie jak Tendric są skierowane właśnie do tego zastosowania. Coroczne warsztaty NLP4RE-Workshop (Natural Language Processing for Requirements Engineering) pokazują jednak, że automatyzacja analizy wymagań za pomocą NLP już dawno wyszła poza niszę.

Co widzi AI, gdy otwiera specyfikację wymagań?

Z perspektywy systemu AI specyfikacja wymagań jest przede wszystkim dokumentem: plikiem Excel z 8 arkuszami (LH1 do LH8), tysiącami wierszy i tuzinem kolumn. Albo PDF-em. Albo, w idealnym przypadku, ustrukturyzowanym zbiorem danych w formacie ReqIF-Format (Requirements Interchange Format), standardzie OMG do wymiany wymagań między narzędziami, wywodzącym się z branży motoryzacyjnej i coraz częściej stosowanym również w technice kolejowej.

Zanim będzie możliwe jakiekolwiek przetwarzanie treści, system musi rozwiązać trzy podstawowe zadania:

1. Rozpoznanie struktury: Które wiersze są wymaganiami, które śródtytułami, a które pustymi wierszami lub komentarzami? W przewodniku VDB dotyczącym zarządzania wymaganiami Niemieckie Stowarzyszenie Przemysłu Kolejowego zaleca jednolitą strukturę atrybutów specyfikacji wymagań. W praktyce rzeczywistość znacznie od niej odbiega.
2. Ekstrakcja pól: Gdzie znajduje się identyfikator wymagania, gdzie tekst, gdzie stopień wiążący (musi/powinno/opcja), a gdzie odniesienie do normy? Międzynarodowy standard ISO/IEC/IEEE 29148:2018 określa wprawdzie, jakie atrybuty powinno mieć wymaganie, lecz zamawiający w branży kolejowej rzadko stosują ten standard wprost.
3. Czyszczenie: Scalone komórki, podziały wiersza w środku tekstu, znaki specjalne Unicode (‰ zamiast %), różne formaty dat oraz semantycznie istotne formatowanie komórek (kolory, pogrubienie), które ginie przy zwykłym eksporcie tekstu.

To wstępne przetwarzanie brzmi trywialnie, ale takie nie jest. Każdy zamawiający strukturyzuje swoją specyfikację inaczej. Kolejność kolumn się różni, śródtytuły znajdują się w tej samej kolumnie co teksty wymagań, a niektórzy zamawiający używają kolorów lub formatowania jako informacji semantycznej, która ginie przy imporcie. Dziedzina badań Document Parsing opisuje dokładnie ten problem: dokumenty są „visually rich text data“. Ich znaczenie wynika nie tylko z tekstu, lecz także z układu, kroju pisma, struktury tabel i elementów wizualnych.

Etap 1: Ekstrakcja wymagań

Ekstrakcja pojedynczych wymagań z surowego dokumentu jest pierwszym i najbardziej krytycznym krokiem. Błędy na tym etapie przenoszą się przez wszystkie kolejne kroki przetwarzania. Błędnej ekstrakcji nie da się skompensować ani dobrą klasyfikacją, ani dobrym routingiem.

Ekstrakcja obejmuje kilka podetapów, z których każdy wiąże się z własnymi wyzwaniami:

• Rozpoznanie ID: Typowy format X.35.YYYY.ZZ jest identyfikowany przez rozpoznawanie wzorców. Skuteczność jest wysoka, dopóki zamawiający używa spójnego schematu ID. Problem pojawia się przy odmiennych formatach: niektórzy zamawiający stosują hierarchiczne identyfikatory (3.2.1.4), inni numery kolejnościowe (REQ-0412), a jeszcze inni całkowicie rezygnują z formalnych ID i pracują na numerach wierszy.
• Rozpoznanie wiążącego charakteru:„musi“, „powinno“, „może“, „ma być“, „ma obowiązek“ są rozpoznawane jako wskaźniki wiążącego charakteru. Wynika to z rozróżnienia zakotwiczonego w systematyce INCOSE-Systematik między sformułowaniami imperatywnymi a opcjonalnymi. Trudność pojawia się przy zależnych od kontekstu sformułowaniach typu „powinno w miarę możliwości“ (czy to „powinno“, czy „może“?) lub konstrukcjach biernych: „Zakłada się zgodność z normą“ nie zawiera wyraźnego „musi“, lecz jest jednoznacznie obowiązkowe.
• Ekstrakcja odniesień do norm:Identyfikacja standardów, takich jak „DIN EN 45545-2:2020+A1:2023“, wraz z numerem wersji i poprawkami. Także tutaj skuteczność jest wysoka dla ustandaryzowanej pisowni. Zamawiający czasem piszą jednak „zgodnie z normą przeciwpożarową“ bez konkretnego numeru normy albo odsyłają do „aktualnego wydania“ normy, które przy zawarciu umowy może być inne niż w chwili złożenia oferty.
• Kontekstowe granice wymagań:Gdzie kończy się jedno wymaganie, a zaczyna kolejne? W dokumentach swobodnego tekstu pojedynczy akapit czasem zawiera kilka domyślnych wymagań: „Pojazd musi móc poruszać się po trasie klasy D4, zachowując jednocześnie limity hałasu zgodnie z TSI Noise.“ Technicznie są to dwa niezależne wymagania (nacisk osi i hałas) zawarte w jednym zdaniu.

Etap 2: Propozycje klasyfikacji

Po ekstrakcji zaczyna się praca merytoryczna: każde wymaganie jest porównywane z wewnętrzną bazą wiedzy. W praktyce obecnie zazwyczaj realizuje się to za pomocą architektury RAG-Architektur (Retrieval-Augmented Generation): system przeszukuje karty danych produktów, specyfikacje producenta i rejestry norm pod kątem najistotniejszych fragmentów, przekazuje je wraz z wymaganiem do modelu językowego i otrzymuje propozycję klasyfikacji: OK, OKB, NOK, OKM lub R.

Dlaczego RAG? Zamiast pozwolić ogólnemu modelowi językowemu „odpowiadać swobodnie“ (co prowadzi do halucynacji), ogranicza się model do konkretnych dokumentów źródłowych. Może on korzystać wyłącznie z informacji faktycznie dostępnych w bazie wiedzy i musi poprzeć odpowiedź odniesieniami do źródeł. To ogranicza halucynacje, lecz ich nie eliminuje.

Jakość tych propozycji znacznie różni się zależnie od typu wymagania:

Szacowana trafność wstępnej klasyfikacji AI według typu wymagania (ocena jakościowa oparta na doświadczeniu praktycznym, nie stanowi benchmarku). Aktualne badania nad automatyczną klasyfikacją wymagań przez NLP pokazują podobne wzorce: wyniki F1 od 0,73–0,84 zależnie od podejścia metodologicznego (Nature Scientific Reports, 2024).

Gdzie działa dobrze

Wymagania parametryczne to idealny przypadek: „Prędkość maksymalna co najmniej 100 km/h“ jest porównywana z kartą danych produktu (nasza wartość: 100 km/h), stosowana jest logika porównania (≥ 100 → spełnione), a wynikiem jest uzasadnione „OK“ z odniesieniem do źródła. Działa to, ponieważ typ wymagania jest jednoznacznie ilościowy, operacja porównania jasna (≥, ≤, =), a dane źródłowe możliwe do odczytu maszynowego.

Podobnie dobrze działa porównanie wymagań normowych, gdy wewnętrzny rejestr norm jest utrzymywany: AI rozpoznaje odniesienie do normy w tekście wymagania, wyszukuje w rejestrze status zgodności i podaje klasyfikację wraz z numerem certyfikatu.

Gdzie robi się trudno

Wymagania jakościowe i nowatorskie sformułowania są słabym punktem. Gdy wymaganie brzmi: „Oferent musi przedstawić koncepcję utrzymania, która obejmuje cykl życia pojazdu przez 30 lat“, AI może:

• Rozpoznać, że dotyczy ono utrzymania (poprawnie)
• Przypisać obszar podsystemu „utrzymanie“ (poprawnie)
• Ustanowić związek z RAMS, czyli że wymaganie dotyczy wymiaru Maintainability w rozumieniu normy EN 50126 (RAMS) (poprawnie)
• Ale nie ocenić, czy firma ma taką koncepcję lub może ją opracować (zależy to od wiedzy wewnętrznej, która rzadko jest w pełni udokumentowana)

W takich przypadkach „R“ (wymagane pytanie wyjaśniające) jest najuczciwszą klasyfikacją. Dobry system AI powinien proponować właśnie to, zamiast halucynować nieuzasadnione „OK“. Badania nad halucynacjami LLM wskazują problem: modele językowe „uczą się pewnie zgadywać, zamiast wyrażać skalibrowaną niepewność“. W klasyfikacji wymagań jest to niebezpieczne, ponieważ błędne „OK“ ma bezpośrednie konsekwencje umowne.

Źródło: CONTACT Software, Pociąg osobowy do zarządzania wymaganiami. Ten cytat pochodzi z 2014 roku. Od tego czasu zagęszczenie wymagań nadal wzrosło. Aktualne przetargi na pojazdy regularnie obejmują 1.500–3.000 wymagań we wszystkich specyfikacjach cząstkowych.

Etap 3: Rozpoznawanie i łączenie norm

Automatyczne rozpoznawanie norm przynosi w praktyce największą oszczędność czasu. Typowa specyfikacja wymagania dla pojazdu szynowego odwołuje się bezpośrednio i pośrednio do trzycyfrowej liczby norm. Ekosystem norm w technice kolejowej jest na poziomie europejskim definiowany przez ERA (Agencję Kolejową Unii Europejskiej) poprzez Techniczne Specyfikacje Interoperacyjności (TSI)i wdrażany przez CEN/CENELEC w zharmonizowane normy europejskie.

Dla dostawcy oznacza to, że gdy specyfikacja wymaga „EN 45545-2“ (ochrona przeciwpożarowa), musi on znać nie tylko status tej jednej normy, lecz także:

• Powiązaną TSI SRT (Safety in Railway Tunnels), która określa ramy regulacyjne
• Metody badań w EN 45545-1 (wymagania ogólne)
• Klasyfikacje materiałów według EN 45545-2 (zachowanie w ogniu)
• Certyfikaty właściwe dla produktu i okres ich ważności

AI może uwidocznić te powiązania w czterech krokach:

Der Niemiecki Komitet Normalizacyjny ds. Infrastruktury i Pojazdów Szynowych (FSF) koordynuje opracowywanie i krajowe wdrażanie norm kolejowych. Powstały krajobraz norm obejmuje około 50–60 istotnych standardów dla pojazdów szynowych. Jako ustrukturyzowany katalog jest on możliwy do opanowania, jeśli zostanie raz zarejestrowany i utrzymywany. Problemem jest dynamika: normy są nowelizowane, publikowane są poprawki, a TSI aktualizowane. Sama ERA w 2025 roku opublikowała kilka zaktualizowanych TSI-Spezifikationen , w tym nowe TSI Telematics, które wejdzie w życie 2 marca 2026 roku i po raz pierwszy definiuje wymagania dotyczące jakości danych i cyberbezpieczeństwa dla transportu kolejowego.

Etap 4: Propozycje routingu do ekspertów

Na podstawie rozpoznanej tematyki i odniesień do norm AI może zaproponować, który dział merytoryczny powinien odpowiadać za każde wymaganie. Według raportu Loopio 2025 RFP Response Trends Report 48% zespołów ofertowych z różnych branż zgłasza trudności we współpracy z ekspertami merytorycznymi. Zautomatyzowany routing może przynajmniej częściowo temu zaradzić.

W branży kolejowej problem routingu jest szczególnie wyraźny. Specyfikacja dla pojazdu kolei głównej obejmuje 10–15 różnych podsystemów, od pudła pojazdu przez napęd i hamulec po informację pasażerską i dokumentację utrzymania. Właściwi eksperci merytoryczni pracują w różnych działach, czasem w różnych lokalizacjach. Bez ustrukturyzowanego routingu menedżer ofert spędza znaczną część czasu na ręcznym przypisywaniu wymagań właściwym osobom.

Jak AI działa technicznie: RAG i wyszukiwanie oparte na embeddingach

Dla czytelników z technicznym przygotowaniem warto zajrzeć pod maskę. Podstawowa zasada nowoczesnych systemów AI do pracy ze specyfikacjami wymagań opiera się na architekturze Retrieval-Augmented-Generation-Architektur (RAG), która łączy dwa komponenty:

1. Retrieval (wyszukiwanie):Wymaganie jest przekształcane w wektor numeryczny (embedding) i porównywane z bazą wektorową wewnętrznej bazy wiedzy. Wynikiem jest 5–10 najistotniejszych fragmentów tekstu z kart danych produktów, rejestrów norm i wcześniejszych ofert.
2. Generation (ocena): Large Language Model (LLM) otrzymuje wymaganie wraz ze znalezionymi dokumentami źródłowymi i generuje propozycję klasyfikacji wraz z uzasadnieniem i odniesieniem do źródła.

Przewaga nad „gołym“ LLM-em: system ma dostęp wyłącznie do informacji faktycznie dostępnych w bazie wiedzy. Jeśli nie znajdzie istotnego źródła, powinien uczciwie zaproponować „R“ (pytanie wyjaśniające), zamiast halucynować odpowiedź brzmiącą wiarygodnie, ale niemożliwą do udowodnienia.

Gdzie AI napotyka granice

Uczciwe spojrzenie na ograniczenia jest ważniejsze niż każdy komunikat o sukcesie. Systemy AI w pracy ze specyfikacjami wymagań napotykają dziś pięć systemowych ograniczeń:

1. Wiedza ukryta

Najcenniejsza wiedza w firmie często nie jest udokumentowana. Jeśli doświadczony inżynier wie, że konkretne wymaganie doprowadziło do wykluczenia w poprzednim przetargu i dlatego formułuje strategiczną odpowiedź, AI nie ma dostępu do tej informacji. Widzi jedynie dokumenty, które zostały jej udostępnione. Ta „Tacit Knowledge“ odgrywa dużą rolę w branży kolejowej, ponieważ środowisko jest niewielkie. Doświadczeni menedżerowie ofert znają preferencje i kryteria oceny konkretnych zamawiających z wieloletniej współpracy.

2. Ocena strategiczna

Klasyfikacja wymagania jako NOK bywa decyzją strategiczną, a nie czysto techniczną. Doświadczeni menedżerowie ofert celowo formułują pytania wyjaśniające, aby „złagodzić“ wymagania, na przykład pytając zamawiającego, dlaczego wymaganie jest surowsze niż leżąca u jego podstaw norma. Mogą też skorzystać z okazji, aby zaproponować bardziej innowacyjną alternatywę przekonującą zamawiającego. Ten rodzaj strategicznej komunikacji wykracza poza możliwości AI.

3. Jakość dokumentów

Jakość wyników AI zależy bezpośrednio od jakości wewnętrznych dokumentów. Nieaktualne karty danych produktów, niepełne rejestry norm lub sprzeczne specyfikacje producenta prowadzą do błędnych propozycji klasyfikacji. Zasada „Garbage in, garbage out“ obowiązuje bez ograniczeń. Paradoks polega na tym, że firmy dobrze utrzymujące dokumentację najmniej „potrzebują“ wsparcia AI. A te, które potrzebowałyby go najbardziej, mają najsłabszą podstawę danych.

4. Brak kontekstu negocjacyjnego

Specyfikacja wymagań nie jest dokumentem statycznym. To punkt wyjścia do negocjacji. Druga rewizja będzie zawierała inne wymagania niż pierwsza, na podstawie informacji zwrotnych od wszystkich oferentów. AI może przetworzyć aktualną wersję, ale nie może przewidzieć, które wymagania zamawiający prawdopodobnie złagodzi. Ten instynkt doświadczeni menedżerowie ofert wypracowują przez lata współpracy z konkretnymi zamawiającymi.

5. Ryzyko halucynacji

Również przy architekturze RAG istnieje ryzyko, że model językowy stworzy powiązania, które nie istnieją, albo zinterpretuje dokumenty źródłowe tak, że pozornie spełniają wymaganie, mimo że przy dokładniejszym spojrzeniu występują istotne różnice. Jeden z aktualnych przeglądów badań nad halucynacjami LLM opisuje problem: modele językowe są zoptymalizowane pod kątem generowania wiarygodnych odpowiedzi, a nie wyrażania skalibrowanej niepewności. W procesie ofertowym, w którym każda klasyfikacja oznacza zobowiązanie umowne, jest to realne ryzyko.

Co się zmienia: proces z AI i bez AI

Laut dem Loopio 2025 RFP Response Trends Report 68% zespołów ofertowych w różnych branżach korzysta już z generatywnej AI (czyli dwukrotnie więcej niż 34% w 2023 roku). 65% używa wyspecjalizowanego oprogramowania RFP (wobec 48% rok wcześniej), a średni wskaźnik wygranych wynosi 45%. Branża kolejowa, tradycyjnie bardziej powściągliwa w cyfrowym zarządzaniu wymaganiami, jest tu wciąż na początku drogi. Według Bidara wskaźnik ponownego wykorzystania treści w różnych branżach wynosi 66%. Większość firm kolejowych nie wykorzystuje tego potencjału z powodu braku przeszukiwalnej bazy wiedzy. Platformy takie jak Tendric rozwiązują ten problem, budując bazę wiedzy ponad projektami i czyniąc ją przeszukiwalną.

Wniosek

Co dzieje się, gdy AI czyta specyfikację wymagań? Wykonuje rutynową pracę: ekstrakcję, strukturyzację, porównanie parametrów, rozpoznawanie norm. Szybciej i pełniej niż proces ręczny. Dla 70–80% wymagań dostarcza użyteczną pierwszą propozycję z odniesieniem do źródła. Przy pozostałych 20–30%, czyli wymaganiach strategicznych, jakościowych i nowatorskich, poprawnie oznacza swoją niepewność i przekazuje sprawę ekspertowi.

To nie porażka, lecz sedno sprawy. AI daje ekspertowi merytorycznemu swobodę skoncentrowania się na wymaganiach, w których jego osąd rzeczywiście robi różnicę, zamiast spędzać godziny na wyszukiwaniu w kartach danych produktów. Grupa robocza INCOSE ds. AI Systems nazywa to „AI for SE“: AI do wspierania procesów inżynierii systemów.

Kolejnym zadaniem nie są lepsze modele. Są nim utrzymywane rejestry norm, aktualne karty danych produktów i przeszukiwalne archiwa wcześniejszych ofert. Narzędzia takie jak Tendric dotyczą właśnie tego: tworzą ustrukturyzowaną bazę danych, na której klasyfikacja wspierana przez AI w ogóle może działać niezawodnie.