Dostawa systemu GraphRAG Medyczny

Usługi informatyczne: konsultacyjne, opracowywania oprogramowania, internetowe i wsparcia, w tym dostawy

Tryb zamówienia	Zapytanie ofertowe
Rodzaj zamówienia	Dostawy
Tytuł	Dostawa systemu GraphRAG Medyczny
Zamawiający	Dostępne dla zalogowanych
Miejsce realizacji	Łódź
Data publikacji	2026-05-26
Data składania ofert	03/06/2026, Godzina 23:59
Dokumenty do pobrania	Dostępne dla zalogowanych
Kod CPV	480000008 Pakiety oprogramowania i systemy informatyczne 487000005 Pakiety oprogramowania użytkowego 486000004 Pakiety oprogramowania dla baz danych i operacyjne
Numer przetargu	7192150

<div>
 <h1>Dostawa systemu GraphRAG Medyczny w ramach realizacji przedsięwzięcia pt. „PRU UMED - Poprawa warunków studiowania w Uniwersytecie Medycznym w Łodzi, poprzez budowę, rozbudowę, modernizację i doposażenie obiektów Uczelni, mających na celu zwiększenie liczby studentów na kierunkach medycznych”</h1>

<h2>Załączniki</h2>
 <ul>
 <li>Wzór umowy - Zał. nr 3.pdf</li>
 <li>OPZ - Zał. nr 2.pdf</li>
 <li>Załącznik nr 1 formularz ofertowy.docx</li>
 <li>Zapytanie ofertowe GraphRAG MEdyczny.pdf</li>
 </ul>
 
 <h2>Części zamówienia</h2>

<h3>Dostawa systemu GraphRAG Medyczny</h3>
 Przedmioty zamówienia
 Przedmiotem zamówienia jest kompleksowa dostawa systemu pn.: „GraphRAG Medyczny” (System), 
obejmująca konfigurację, wdrożenie, dokumentację, szkolenie, testy odbiorowe oraz wsparcie powdrożeniowe. 
W ramach przedmiotu zamówienia Wykonawca: 
• Dostarczy i zainstaluje w infrastrukturze Zamawiającego System, w środowisku kontrolowanym przez 
Zamawiającego, z zachowaniem wymagań bezpieczeństwa, kontroli dostępu, audytowalności, ochrony 
danych oraz jakości odpowiedzi. Wykonawca zobowiązany jest przedstawić kompletne wymagania 
sprzętowe i środowiskowe konieczne do poprawnego działania systemu. 
• Wytworzy i uruchomi Bazy wiedzy: KB-A i KB-B poprzez zaindeksowanie materiałów źródłowych 
wskazanych przez Zamawiającego oraz ich ingestię do Baz wiedzy.. 
• Sparametryzuje i uruchomi dwukierunkowe REST API z autoryzacją Bearer, endpointami zapytań i 
capabilities, 
• Dostarczy dokumentację Systemu: instrukcje użytkownika, dokumentację API, procedury utrzymaniowe, 
• Przeprowadzi szkolenia dla pracowników wskazanych przez Zamawiającego, mających pełnić funkcję 
administratora Systemu, w formie szkoleń zdalnych, realizowanych z wykorzystaniem Microsoft Teams, w 
wymiarze 4h, w terminie uzgodnionym z Zamawiającym, nie później jednak niż do 22.06.2026 r. 
BAZY WIEDZY 
• System musi umożliwiać tworzenie, konfigurację, zasilanie, aktualizację, podgląd i usuwanie Baz wiedzy. 
• Baza wiedzy powinna być jednostką logiczną przypisaną do konta Zamawiającego, z możliwością 
rozróżnienia baz produkcyjnych i testowych. 
• Przyjmuje się, że podstawowy panel Baz Wiedzy powinien umożliwiać obserwację limitów, tworzenie nowej 
Bazy wiedzy, wejście w szczegóły istniejącej bazy oraz przejście do dokumentów. 
• W widoku szczegółowym Bazy Wiedzy prezentowane powinny byćstatystyki liczby dokumentów, liczby 
znaków, liczby chunków, ekstrakcji oraz stan ostatniej ingestii. 
• Moduł Baz wiedzy powinien zawierać: 
o Listę Baz wiedzy: prezentacja produkcyjnych i testowych Baz wiedzy wraz z ich nazwą, statusem, datą, 
liczbą znaków i liczbą ingestii; 
o Szczegóły Bazy wiedzy: liczba dokumentów, liczba znaków, liczba ekstrakcji, użycie AI, wykorzystanie 
limitów, status ingestii, status ekstrakcji, status błędów i komunikaty diagnostyczne; 
o Ingestia: kreator importu materiałów źródłowych; 
o Dokumenty: lista dokumentów i folderów z datą modyfikacji, autorem, rozmiarem, liczbą chunków i 
poziomem dostępu; 
o Eksport: pobieranie danych bez wektorów oraz pobieranie danych z wektorami, jeśli uprawnienia i 
konfiguracja na to pozwalają; 
• Struktura zaindeksowanej wiedzy: 
o Metadane zwykłe: nazwa pliku, autorzy, daty, liczba stron, liczba obrazów, liczba znaków, format pliku; 
o Metadane złożone: ekstrakcje zagadnień medycznych, klasyfikacje tematyczne, słowa kluczowe, 
relacje, wersje publikacji, kontekst dydaktyczny; 
o Obrazy: wycięte obrazy z dokumentów, zapisane jako pliki, wraz z opisem traktowanym jako parent; 
o Leafy: małe fragmenty tekstu używane do wyszukiwania semantycznego 
o Parenty: większe jednostki kontekstowe obejmujące leafy, rozdziały, podrozdziały, opisy obrazów lub 
sekcje dokumentu. 
o Embeddingi: wektory leafów, opisów obrazów oraz wybranych metadanych złożonych 
o Graf wiedzy: relacje między dokumentami, pojęciami, rozdziałami, obrazami, sylabusami i pytaniami. 
• Ingestia dokumentów 
o Proces ingestii musi być powtarzalny, monitorowany i raportowany. 
o System powinien umożliwiać import plików lokalnych oraz być gotowy do integracji z repozytoriami 
dokumentów używanymi przez Zamawiającego. 
o Minimalnie system musi obsługiwać pliki EPUB, PDF, DOCX, ODT, TXT, XML, HTML oraz obrazy JPG, PNG 
i TIFF, jeśli są używane jako załączniki lub źródła pytań. 
o Każda ingestia musi kończyć się raportem zawierającym liczbę przetworzonych plików, liczbę znaków, 
liczbę obrazów, liczbę utworzonych chunków, błędy przetwarzania oraz status końcowy. 
o Dla dokumentów zbyt dużych do podglądu inline system powinien umożliwiać pobranie danych, w tym 
wariantu bez wektorów oraz wariantu z wektorami, zgodnie z polityką bezpieczeństwa. 
o W przypadku formatów graficznych (JPG, PNG, TIFF) System powinien posiadać funkcjonalność OCR 
(Optical Character Recognition) 
• W przypadku materiałów chronionych prawem autorskim Wykonawca zobowiązany jest wdrożyć 
rozwiązanie techniczne w sposób zgodny z uprawnieniami Zamawiającego do korzystania z materiałów. 
• System powinien umożliwiać ograniczanie dostępu do dokumentów, źródeł, obrazów i kontekstów 
wyłącznie do uprawnionych użytkowników. 
WYMAGANIA WOBEC API 
• System musi udostępniać zewnętrzne REST API umożliwiające zadawanie pytań do Baz wiedzy, pobieranie 
odpowiedzi, identyfikowanie dostępnych Baz wiedzy oraz monitorowanie wykorzystania. 
• API powinno być zabezpieczone mechanizmem OAuth 2.0 Office 365 (Microsoft 365) używanym u Zamawiającego. 
• API musi być zabezpieczone protokołem HTTPS oraz wykorzystywać format JSON do przekazywania 
informacji. 
• Na podstawie widoku referencyjnego API przyjmuje się, że dokumentacja API powinna zawierać adres 
bazowy, sposób uwierzytelniania, przykłady wywołań curl, opisy żądań i odpowiedzi oraz co najmniej 
endpoint Capabilities, zwracający listę dostępnych baz wiedzy i zewnętrznych API przypisanych do tenanta. 
• Obszary API: 
o Capabilities: Lista dostępnych baz wiedzy, ich identyfikatorów, uprawnień i ewentualnych zewnętrznych 
źródeł 
o Query: Przyjęcie pytania, załączników lub referencji do załączników oraz parametrów odpowiedzi 
o Response: Odpowiedź tekstowa, cytowania, źródła, kontekst, obrazy lub referencje do obrazów 
o Usage: Liczba zapytań, limity, metryki użycia API i GUI 
o Audyt: Identyfikator zapytania, użytkownik/klient API, czas, baza wiedzy, status i błędy 
 
Szczegółowy opis przedmiotu zamówienia stanowi załącznik nr 2 do zapytania ofertowego.

<h2>Kryteria oceny</h2>
 Kryterium nr 1. - cena (C) obliczane jest wg wzoru: 
C = (Cmin/Cn) x ….. [%] 
gdzie: 
Cmin – cena najniższa, Cn - cena badana
 
 <h2>Warunki zmiany umowy</h2>

Możliwości zmiany umowy zostały zawarte we wzorze umowy
 </div>