W związku z realizacją projektu współfinansowanego ze środków Unii Europejskiej zwracamy się z zapytaniem ofertowym na kompleksową usługę informatyczną opisaną poniżej.
1Kontekst projektu
Zamawiający realizuje projekt badawczo-rozwojowy, którego celem jest opracowanie systemu opartego na sztucznej inteligencji, automatyzującego pracę brokerów spedycyjnych w sektorze TSL – w szczególności obsługę zapytań transportowych oraz analizę dokumentacji przetargowej. System wykorzystuje model językowy dostrojony metodami PEFT/LoRA oraz architekturę RAG (Retrieval-Augmented Generation).
Wyniki prac badawczych i rozwojowych mają zostać przetestowane przez podmiot zewnętrzny.
2Przedmiot zamówienia
Przedmiotem zamówienia jest usługa przeprowadzenia testów zewnętrznych systemu AI, realizowana w dwóch etapach:
Etap 1 01.01.2027 – 31.01.2027
Weryfikacja zoptymalizowanego modelu AI
- 1.1. Weryfikacja metryki F1-score
- 1.2. Weryfikacja wskaźnika halucynacji
Etap 2 01.06.2027 – 30.06.2027
Weryfikacja prototypu systemu
- 2.1. Weryfikacja modułu obsługi zapytań transportowych
- 2.2. Weryfikacja modułu analizy dokumentacji przetargowej
- 2.3. Ocena interfejsu użytkownika
- 2.4. Testy integracyjne
Zamówienie obejmuje oba etapy łącznie. Zamawiający nie dopuszcza składania ofert częściowych.
3Opis prac (podzadania)
Metodykę testów, narzędzia, sposób automatyzacji i technologie dobiera Wykonawca według własnego uznania, z zachowaniem definicji wskazanych poniżej. Wykonawca opisuje przyjęte rozwiązania w raporcie.
Etap 1 – weryfikacja modelu AI
1.1. Weryfikacja metryki F1-score
Niezależna weryfikacja wartości metryki F1-score zoptymalizowanego modelu AI na zbiorze co najmniej 100 dokumentów testowych z branży TSL.
- Zamawiający przekazuje zbiór testowy obejmujący rzeczywiste dokumenty branżowe (zapytania transportowe, dokumenty przetargowe, umowy ramowe, zlecenia transportowe, korespondencja handlowa) wraz z określonymi dla każdego dokumentu kluczowymi polami informacyjnymi (np. parametry ładunku, trasa, terminy, warunki cenowe i kontraktowe) i ich wartościami wzorcowymi.
- Wykonawca samodzielnie uruchamia model na całym zbiorze testowym za pośrednictwem dostępu udostępnionego przez Zamawiającego i porównuje wyniki ekstrakcji z wartościami wzorcowymi.
- Wykonawca określa zasady uznawania wartości za zgodną z wzorcem (np. sposób traktowania różnic w zapisie dat, jednostek czy nazw miejscowości) oraz sposób agregacji wyniku F1-score i opisuje je w raporcie.
1.2. Weryfikacja wskaźnika halucynacji
Ekspercka weryfikacja wskaźnika halucynacji poprzez ocenę 100 zapytań testowych pod kątem zgodności odpowiedzi modelu z dokumentacją źródłową.
- Zamawiający przekazuje zestaw 100 zapytań testowych oraz dokumentację źródłową, na której opiera się baza wiedzy modelu (architektura RAG).
- Wykonawca samodzielnie zadaje zapytania modelowi i rejestruje odpowiedzi.
- Za halucynację uznaje się odpowiedź zawierającą informację niezgodną z dokumentacją źródłową lub nieznajdującą w niej oparcia.
- Wskaźnik halucynacji to udział odpowiedzi ocenionych jako halucynacja w liczbie wszystkich ocenionych odpowiedzi. Każda ocena negatywna zawiera krótkie uzasadnienie.
Etap 2 – weryfikacja prototypu systemu
2.1. Weryfikacja modułu obsługi zapytań transportowych
Weryfikacja skuteczności modułu na zbiorze 50 zapytań testowych.
- Zamawiający przekazuje 50 zapytań transportowych oraz, dla każdego z nich, informacje, które klient przekazałby w odpowiedzi na pytania uzupełniające systemu.
- Wykonawca samodzielnie przeprowadza każde zapytanie przez moduł, korzystając z interfejsu użytkownika – od wprowadzenia zapytania, przez odpowiedzi na pytania uzupełniające generowane przez system, do wygenerowania szkicu zlecenia.
- Kompletny szkic zlecenia to dokument zawierający wszystkie wymagane pola, tj. trasę, parametry ładunku oraz terminy, z wartościami zgodnymi z treścią zapytania i przekazanych uzupełnień.
- Skuteczność to udział kompletnych szkiców zleceń w liczbie wszystkich zapytań testowych.
2.2. Weryfikacja modułu analizy dokumentacji przetargowej
Weryfikacja skuteczności modułu na zbiorze 30 dokumentów przetargowych.
- Zamawiający przekazuje 30 dokumentów przetargowych.
- Wykonawca samodzielnie przeprowadza każdy dokument przez moduł, korzystając z interfejsu użytkownika, do wygenerowania szkicu zlecenia.
- Kompletny szkic zlecenia to dokument zawierający wszystkie wymagane pola, tj. trasę, parametry ładunku oraz terminy, z wartościami zgodnymi z treścią dokumentu przetargowego.
- Skuteczność to udział kompletnych szkiców zleceń w liczbie wszystkich dokumentów przetargowych.
2.3. Ocena interfejsu użytkownika
Ocena jakości interfejsu użytkownika pod kątem ergonomii i użyteczności dla brokerów spedycyjnych. Metodę oceny dobiera Wykonawca. Ocena obejmuje w szczególności:
- możliwość korzystania z obu modułów bez wiedzy technicznej,
- czytelność prezentacji wyników ekstrakcji danych,
- możliwość weryfikacji i ręcznej korekty danych przed ich zatwierdzeniem,
- przechodzenie między panelem obsługi zapytań, a panelem analizy przetargów.
Wynikiem jest ocena interfejsu wraz z listą zidentyfikowanych problemów i rekomendacji.
2.4. Testy integracyjne
Testy integracyjne weryfikujące współdziałanie komponentów systemu (frontend – backend – model AI). Wykonawca opracowuje scenariusze testowe obejmujące pełny przepływ danych w obu modułach – od wprowadzenia danych w interfejsie, przez przetworzenie w backendzie i modelu AI, do prezentacji wyniku użytkownikowi. Dla każdego scenariusza raport wskazuje wynik (pozytywny / negatywny) i opis wykrytych błędów.
Zasady przeprowadzenia testów
- Zamawiający przekazuje dostęp do środowiska testowego, zbiory testowe i dokumentację techniczną najpóźniej pierwszego dnia realizacji etapu.
- Testy prowadzone są niezależnie, Zamawiający nie ingeruje w przebieg testów ani w oceny.
Raport z testów
Rezultatem każdego etapu jest raport z testów w języku polskim, w formie PDF, zawierający między innymi:
- opis metodyki i przyjętych zasad oceny,
- wyniki testów,
- analizę błędów.
4Warunki realizacji
- Wykonawca nie musi zapewniać infrastruktury obliczeniowej – testowany system działa w środowisku Zamawiającego. Prace mogą być realizowane zdalnie.
- Odbiór każdego etapu następuje protokołem odbioru.
- Wynagrodzenie ryczałtowe, płatne po każdym etapie, w terminie 30 dni od otrzymania prawidłowo wystawionej faktury, wystawionej po podpisaniu protokołu odbioru.
5Zawartość oferty
Oferta powinna zawierać cenę netto i brutto dla etapu 1 i etapu 2.
6Termin składania ofert
Oferty należy przesyłać do 28.10.2026 do godziny 23:59 na adres administracja@shipeiro.com. Pytania dotyczące zapytania można kierować na ten sam adres.
7Informacje formalne
Zamówienie nie podlega przepisom ustawy Prawo zamówień publicznych. Zapytanie służy rozeznaniu rynku i nie stanowi oferty w rozumieniu art. 66 Kodeksu cywilnego ani zobowiązania do udzielenia zamówienia.
In connection with the implementation of a project co-financed by the European Union, we hereby submit a request for quotation for the comprehensive IT service described below.
1Project background
The Contracting Party is carrying out a research and development project aimed at developing an artificial intelligence-based system that automates the work of freight forwarding brokers in the TSL (transport, shipping and logistics) sector – in particular, handling transport enquiries and analysing tender documentation. The system uses a language model fine-tuned with PEFT/LoRA methods and a RAG (Retrieval-Augmented Generation) architecture.
The results of the research and development work are to be tested by an external entity.
2Subject of the contract
The subject of the contract is a service of external testing of the AI system, carried out in two stages:
Stage 1 01.01.2027 – 31.01.2027
Verification of the optimised AI model
- 1.1. Verification of the F1-score metric
- 1.2. Verification of the hallucination rate
Stage 2 01.06.2027 – 30.06.2027
Verification of the system prototype
- 2.1. Verification of the transport enquiry handling module
- 2.2. Verification of the tender documentation analysis module
- 2.3. User interface evaluation
- 2.4. Integration tests
The contract covers both stages jointly. The Contracting Party does not accept partial offers.
3Scope of work (sub-tasks)
The testing methodology, tools, method of automation and technologies are chosen by the Contractor at its own discretion, subject to the definitions specified below. The Contractor describes the adopted solutions in the report.
Stage 1 – verification of the AI model
1.1. Verification of the F1-score metric
Independent verification of the F1-score of the optimised AI model on a set of at least 100 test documents from the TSL sector.
- The Contracting Party provides a test set comprising real industry documents (transport enquiries, tender documents, framework agreements, transport orders, business correspondence), together with the key information fields defined for each document (e.g. cargo parameters, route, dates, pricing and contractual terms) and their reference values.
- The Contractor independently runs the model on the entire test set via access provided by the Contracting Party and compares the extraction results with the reference values.
- The Contractor defines the rules for deeming a value consistent with the reference (e.g. how differences in the notation of dates, units or place names are treated) and the method of aggregating the F1-score, and describes them in the report.
1.2. Verification of the hallucination rate
Expert verification of the hallucination rate by assessing 100 test queries for consistency of the model's answers with the source documentation.
- The Contracting Party provides a set of 100 test queries and the source documentation on which the model's knowledge base is built (RAG architecture).
- The Contractor independently submits the queries to the model and records the answers.
- A hallucination is an answer containing information that is inconsistent with the source documentation or not supported by it.
- The hallucination rate is the share of answers assessed as hallucinations in the total number of assessed answers. Each negative assessment includes a brief justification.
Stage 2 – verification of the system prototype
2.1. Verification of the transport enquiry handling module
Verification of the module's effectiveness on a set of 50 test enquiries.
- The Contracting Party provides 50 transport enquiries and, for each of them, the information the customer would give in reply to the system's follow-up questions.
- The Contractor independently runs each enquiry through the module using the user interface – from entering the enquiry, through answering the follow-up questions generated by the system, to generating a draft transport order.
- A complete draft order is a document containing all required fields, i.e. route, cargo parameters and dates, with values consistent with the content of the enquiry and the additional information provided.
- Effectiveness is the share of complete draft orders in the total number of test enquiries.
2.2. Verification of the tender documentation analysis module
Verification of the module's effectiveness on a set of 30 tender documents.
- The Contracting Party provides 30 tender documents.
- The Contractor independently runs each document through the module using the user interface, up to the generation of a draft transport order.
- A complete draft order is a document containing all required fields, i.e. route, cargo parameters and dates, with values consistent with the content of the tender document.
- Effectiveness is the share of complete draft orders in the total number of tender documents.
2.3. User interface evaluation
Evaluation of the quality of the user interface in terms of ergonomics and usability for freight forwarding brokers. The evaluation method is chosen by the Contractor. The evaluation covers in particular:
- the ability to use both modules without technical knowledge,
- the clarity of presentation of data extraction results,
- the ability to verify and manually correct data before approval,
- switching between the enquiry handling panel and the tender analysis panel.
The result is an evaluation of the interface together with a list of identified issues and recommendations.
2.4. Integration tests
Integration tests verifying the interaction of the system components (frontend – backend – AI model). The Contractor develops test scenarios covering the full data flow in both modules – from data entry in the interface, through processing in the backend and the AI model, to presentation of the result to the user. For each scenario, the report states the result (pass / fail) and a description of the errors found.
Testing rules
- The Contracting Party provides access to the test environment, the test sets and the technical documentation no later than on the first day of each stage.
- The tests are conducted independently; the Contracting Party does not interfere with the course of the tests or the assessments.
Test report
The deliverable of each stage is a test report in Polish, in PDF format, containing, among other things:
- a description of the methodology and the adopted assessment rules,
- the test results,
- an error analysis.
4Terms of performance
- The Contractor does not need to provide computing infrastructure – the tested system runs in the Contracting Party's environment. The work may be performed remotely.
- Each stage is accepted by means of an acceptance protocol.
- Lump-sum remuneration, payable after each stage, within 30 days of receipt of a correctly issued invoice, issued after the acceptance protocol has been signed.
5Contents of the offer
The offer should state the net and gross price for Stage 1 and Stage 2.
6Deadline for submitting offers
Offers should be sent by 28.10.2026, 11:59 pm to administracja@shipeiro.com. Questions regarding this request may be sent to the same address.
7Formal information
The contract is not subject to the Polish Public Procurement Law. This request serves as market research and does not constitute an offer within the meaning of Article 66 of the Polish Civil Code, nor an obligation to award the contract.
This English version is provided for information only. The Polish version is binding.
