Co dzieje się pod maską, kiedy zadajesz pytanie
Nie znajdziesz tu kodu. Znajdziesz historię — krok po kroku — jak Twoje pytanie wędruje przez kilka „pomieszczeń" i wraca z odpowiedzią. Tak jak list w starej poczcie: trafia do jednego okienka, potem do drugiego, ekspedycja, kurier, znowu okienko — aż wraca do Ciebie.
Czterech aktorów
Cały system to czworo rozmówców, którzy nigdy nie widzą się nawzajem, ale przesyłają sobie wiadomości w określonej kolejności. Każdy ma swoją rolę.
To okno, w którym piszesz pytanie i widzisz odpowiedź. Strona analiza.html w Chrome / Safari. Niczego nie wie sama z siebie — jest jak telefon: dzwoni do kogoś, kto wie.
Mały program na Twoim komputerze (port 8093). Przyjmuje pytanie z przeglądarki, dorzuca instrukcje (CLAUDE.md) i opis narzędzi, dzwoni do GPT. Potem oddaje odpowiedź z powrotem.
Model językowy OpenAI, gdzieś w chmurze. Czyta Twoje pytanie + instrukcje + opis narzędzi. Jeśli czegoś nie wie, prosi Telefonistkę o sprawdzenie w słowniku. Pisze ostateczną odpowiedź.
Wielka karteka — 9263 hebrajskich słów, każde z polskim znaczeniem, hebrajskim zapisem, statystykami z całego ST. Nie mówi sama — odpowiada tylko, gdy ktoś zapyta o konkretne hasło.
Co się dzieje od kliknięcia do odpowiedzi
Wyobraź sobie, że pytasz: „Co właściwie znaczy słowo elohim?". Oto co dzieje się w siedmiu krokach.
Piszesz pytanie i klikasz „wyślij"
Twoja przeglądarka pakuje pytanie w „kopertę" cyfrową razem z całą wcześniejszą rozmową (żeby GPT pamiętał kontekst). Wysyła ją na adres localhost:8093/chat — czyli do Telefonistki na Twoim własnym komputerze.
Dodaje instrukcje i opis narzędzi
Telefonistka NIE wysyła pytania do GPT samego. Najpierw dorzuca: instrukcję „jak masz odpowiadać" (cała treść pliku CLAUDE.md — m.in. „pisz dla 15-latka, nie używaj żargonu, niebiosa to otwarta przestrzeń, nie kopuła") oraz opis dwóch narzędzi, które GPT może wywołać, jeśli potrzebuje sprawdzić coś w słowniku.
Czyta wszystko i decyduje: „muszę sprawdzić w słowniku"
GPT widzi pytanie i instrukcje. Wie, że nie ma w swojej głowie aktualnych danych korpusowych z Twojego projektu. Zamiast zgadywać — używa udostępnionego mu narzędzia: search_words("elohim"). To jak gdyby powiedział: „Telefonistko, sprawdź dla mnie, jak elohim wygląda w słowniku".
Telefonistka idzie do karteki
Telefonistka otrzymuje prośbę „znajdź elohim". Otwiera master.json (wielką karteke 9263 słów) i wyciąga kartę H430: hebrajski zapis, transliterację, polskie znaczenie, ile razy występuje w Starym Testamencie. Pakuje to w odpowiedź i odsyła GPT.
Prosi o pełen wpis (jeśli potrzebuje)
Jeśli GPT chce pójść głębiej, woła drugie narzędzie: get_word_details("H430"). Wtedy dostaje wszystko: obraz słowa, „odkrycie" (co tradycja myli), klucz interpretacyjny, klasy semantyczne, pełną analizę. Telefonistka znowu wyciąga to z karteki i odsyła.
Pisze odpowiedź zgodnie z instrukcjami
Teraz GPT ma wszystko: Twoje pytanie, instrukcje (prosty język, stanowiska redakcyjne), dane ze słownika. Pisze odpowiedź po polsku, dla 15-latka, bez żargonu, w stylu projektu. Wysyła ją do Telefonistki.
Twoje okno rysuje odpowiedź
Telefonistka oddaje gotową odpowiedź Twojej przeglądarce. Ta formatuje tekst (pogrubienia, kursywy, kod), rysuje bąbelek czatu i przewija ekran. Zapisuje też rozmowę w pamięci (localStorage), żebyś mógł do niej wrócić.
Cała trasa w jednym obrazku
Dlaczego tak, a nie prościej
„Czemu nie wysłać po prostu pytania bezpośrednio do GPT?" — to dobre pytanie. Powodów jest kilka.
GPT nie zna Twojego słownika
GPT jest ogólnym ekspertem od języka — wie dużo, ale nie zna Twoich konkretnych danych: master.json z 9263 słowami, opisami z metody Johnsona, stanowisk redakcyjnych projektu. Telefonistka dorzuca te dane w locie, żeby GPT miał z czego pisać.
Klucz API musi siedzieć bezpiecznie
Żeby rozmawiać z GPT, potrzebny jest klucz dostępu (jak hasło). Gdybyśmy wpisali go bezpośrednio w stronę HTML, każdy odwiedzający mógłby go zobaczyć i użyć na Twoje konto. Telefonistka trzyma klucz u siebie (w pamięci Twojego komputera) i nie pokazuje go nikomu.
Słownik jest za duży, żeby wysyłać go cały za każdym razem
Master.json ma 24 megabajty. Wysyłanie go w całości do GPT przy każdym pytaniu byłoby powolne i drogie (płacisz za każdy „kawałek" tekstu wysłany do GPT). Zamiast tego GPT pyta tylko o to, co mu potrzebne — jak czytelnik biblioteki, który prosi bibliotekarkę o konkretną książkę zamiast nieść do domu cały regał.
Instrukcje (CLAUDE.md) trzymają GPT na właściwym torze
Bez instrukcji GPT pisze „neutralnie chrześcijańsko" — tradycyjnymi wytartymi formułkami. Plik CLAUDE.md uczy go stylu projektu: pisz dla 15-latka, nie używaj żargonu „sufiks zaimkowy", niebiosa to otwarta przestrzeń (nie kopuła), duchy zmarłych to upadli aniołowie. Telefonistka dorzuca ten plik do każdego pytania, żeby GPT konsekwentnie trzymał ten kierunek.
Łatwiejsza metafora: kuchnia
Jeśli ciągle Ci się myli, kto z kim się dogaduje — pomyśl o tym jak o kuchni w restauracji.
Siedzi przy stoliku, składa zamówienie kelnerce.
Przyjmuje zamówienie, przekazuje do kuchni, dodaje notatkę z przepisem („bez glutenu, dla dziecka").
Zna ogólnie kuchnię, ale konkretne składniki musi wziąć ze spiżarni.
Stoi w piwnicy, ma wszystko, czego trzeba — kucharz mówi pomocnikowi „przynieś mi pomidor", a ten przynosi.
Ty nie widzisz, jak kucharz rozmawia ze spiżarnią — to dzieje się za kulisami. Dostajesz gotowe danie przyniesione przez kelnerkę. Tak samo z czatem korpusowym: Ty piszesz pytanie, dostajesz odpowiedź. Reszta — kelnerka, kucharz, spiżarnia — robi się sama.
Kto za to płaci i czy jest bezpiecznie
Każde pytanie kosztuje ułamek grosza
GPT (od OpenAI) liczy pieniądze za każdy „kawałek" tekstu: ten, który wysyłasz (Twoje pytanie + instrukcje), i ten, który dostajesz (odpowiedź). Dzięki sprytnej organizacji (słownik jako narzędzie zamiast jako pełen załącznik) jedno pytanie kosztuje około 0,0003 USD — czyli na dolar możesz zadać 3 tysiące pytań. Pieniądze schodzą z Twojego konta OpenAI (osobnego od subskrypcji ChatGPT).
Wszystko zostaje na Twoim komputerze
Telefonistka (serve_chat.py) działa tylko na 127.0.0.1 — to adres „tylko ja sam ze sobą", nikt z zewnątrz nie dosięgnie. Klucz API siedzi w zmiennej środowiskowej Twojego komputera, nigdy nie wycieka do strony. Rozmowy są zapisywane tylko w pamięci Twojej przeglądarki (localStorage), nie na żadnym serwerze.
A co działa bez GPT?
Wbudowany tryb Korpus (domyślny) nie potrzebuje GPT ani Telefonistki — szuka bezpośrednio w słowniku, w przeglądarce, lokalnie. Działa nawet bez internetu.
Wpisujesz słowo → przeglądarka znajduje je w master.json (który raz pobiera) i pokazuje kartę. Zero kosztów, zero internetu, zero zależności.
Wpisujesz pytanie (zdanie, rozmowę) → cała opisana wcześniej trasa. Płatne, wymaga internetu i klucza.
Co siedzi w skrypcie serve_chat.py
To „telefonistka" — plik Python, 200 linii, który łączy Twoją przeglądarkę z GPT. Tu opowiadam co robi po kolei, gdy go uruchamiasz — z perspektywy zwykłego człowieka, nie programisty.
Sprawdza, czy ma wszystko, co potrzebne
Pierwsza rzecz, jaką robi skrypt po uruchomieniu: sprawdza, czy w jego „torbie" są wszystkie narzędzia (biblioteki Python: openai, fastapi, uvicorn). Jeśli czegoś brakuje, mówi: „brak narzędzia X, zainstaluj komendą Y" i kończy działanie. Bezpiecznik — nie zaczyna pracy bez kompletu.
Wyciąga klucz do GPT
Następnie szuka klucza OPENAI_API_KEY — bez niego nie ma dostępu do GPT. Najpierw zerka do pliku .env w katalogu projektu, potem do zmiennych systemowych Twojego komputera. Jeśli nie znajdzie — zatrzymuje się i mówi: „brak klucza, dodaj go do .env". Klucz jest jak hasło do banku — bez niego nic nie zrobi.
Otwiera słownik i robi „spis treści"
Wczytuje plik data/master.json — wielką karteke 9263 hebrajskich słów (24 megabajty). Z każdej karty wyciąga najważniejsze rzeczy: Strong#, hebrajski zapis, transliterację, polskie znaczenie, częstotliwość. Tworzy z tego „spis treści" — szybki indeks (~1 megabajt). Pełne karty zostają w pamięci na później, na żądanie.
Czyta instrukcje stylu (CLAUDE.md)
Wczytuje plik CLAUDE.md z katalogu projektu. Zawiera on zasady redakcyjne: pisz dla 15-latka, nie używaj żargonu „sufiks zaimkowy", niebiosa to otwarta przestrzeń (nie kopuła), duchy zmarłych to upadli aniołowie. Te zasady trafią do GPT przy każdym pytaniu, żeby pisał w stylu projektu.
Buduje „instrukcję dla GPT" i opisuje narzędzia
Skleja razem: (1) zasady z CLAUDE.md, (2) opis dwóch narzędzi które GPT może wywołać. Dwa narzędzia to: search_words("elohim") — szuka słów po nazwie, i get_word_details("H430") — wyciąga pełną kartę konkretnego słowa. Cały ten zestaw to system prompt — instrukcja, którą GPT czyta przed każdą odpowiedzią.
Uruchamia „pocztę" na porcie 8093
Otwiera „pocztę" na adresie 127.0.0.1:8093 — to lokalny adres na Twoim komputerze, niewidoczny z internetu. Wystawia jeden „guzik": POST /chat. Czeka, aż przeglądarka coś wyśle. Wypisuje na ekranie: „Serwer startuje, model gpt-4o-mini, 9263 słów" i przechodzi w tryb nasłuchu.
Przeglądarka puka: „mam pytanie"
Klikasz „wyślij" w czacie. Przeglądarka pakuje Twoje pytanie i całą historię rozmowy w kopertę cyfrową i wysyła ją na adres 127.0.0.1:8093/chat. Skrypt Python odbiera — i tu zaczyna się prawdziwa praca.
Wysyła pytanie + instrukcje do GPT
Skrypt skleja razem: instrukcję stylu + Twoje pytanie + opis narzędzi. Tę całą paczkę wysyła do GPT przez Internet (do OpenAI). Mówi: „Oto pytanie, oto reguły. Jeśli czegoś nie wiesz, możesz wywołać te dwa narzędzia, ja odpowiem".
Słucha co GPT odpowie
GPT może odpowiedzieć na dwa sposoby:
(A) Od razu napisać odpowiedź → skrypt ją bierze i odsyła do przeglądarki. Koniec.
(B) Powiedzieć: „chcę najpierw sprawdzić to słowo w słowniku" → wtedy skrypt:
- odczytuje, którego słowa GPT szuka (np. „elohim")
- zerka do swojego spisu treści — znajduje H430
- jeśli GPT poprosi o pełną kartę — wyciąga ją z master.json
- odsyła GPT te dane
- czeka znowu na odpowiedź — może być znowu A albo B (pętla, maks. 4 razy)
Pakuje odpowiedź i odsyła
Gdy GPT skończy, skrypt pakuje gotowy tekst odpowiedzi w „kopertę zwrotną" — razem z informacją, ile tokenów zużyło (czyli ile to kosztowało) — i odsyła to przeglądarce. Przeglądarka rysuje odpowiedź jako bąbelek czatu. Skrypt zapisuje w swoim dzienniku: „obsłużone pytanie, 487 tokenów wejście, 312 wyjście".
Czeka na następne pytanie
Skrypt nie kończy działania — wraca do trybu nasłuchu. Może obsłużyć kolejne pytanie, i kolejne, i kolejne — dopóki Ty go nie zamkniesz (Ctrl+C w terminalu) albo nie wyłączysz komputera. Każda kolejna rozmowa jest niezależna od poprzedniej — przeglądarka wysyła pełną historię w każdej kopercie.
Dlaczego skrypt wygląda właśnie tak
Indeks zamiast całego słownika w „instrukcji"
Gdyby skrypt wysłał do GPT cały master.json przy każdym pytaniu, GPT widziałby 156 tysięcy tokenów kontekstu — to przekraczałoby jego limit (128 tys.) i każde pytanie kosztowałoby ok. 2 centy. Zamiast tego skrypt wysyła tylko spis treści (1 tys. tokenów) i pozwala GPT poprosić o szczegóły. Efekt: tańsze ~60×, działa.
Pętla narzędzi — GPT może pytać kilka razy
GPT może chcieć najpierw wyszukać słowo, potem zobaczyć pełną kartę, potem jeszcze inne słowo. Skrypt obsługuje to w pętli — odpowiada GPT, czeka na kolejną prośbę, znowu odpowiada. Maksymalnie 4 cykle (zabezpieczenie przed zapętleniem). Jak długa rozmowa kucharza z pomocnikiem: „daj pomidor… teraz cebulę… teraz sól".
Tylko lokalny adres — bez internetu na zewnątrz
Skrypt słucha pod 127.0.0.1:8093, nie pod publicznym adresem. To znaczy, że tylko Ty z Twojego komputera możesz się do niego dobić. Nikt z internetu nie odpali Ci niespodziewanego rachunku w OpenAI. Klucz API zostaje zamknięty w pamięci procesu, nigdy nie idzie do przeglądarki.
CORS — przepustka tylko dla Twojej strony
Przeglądarki domyślnie blokują wysyłanie danych z jednej strony do drugiej (zabezpieczenie). Skrypt mówi wprost: „akceptuję połączenia z localhost:8092 (twoja strona)" — i przepuszcza tylko Twoją przeglądarkę. Reszta zostaje zatrzymana.
FastAPI + Uvicorn — szybko i nowocześnie
Skrypt używa biblioteki FastAPI do obsługi „poczty" (przyjmowania pytań) i Uvicorn do uruchamiania serwera. To nowoczesny, asynchroniczny zestaw — może obsłużyć kilka pytań jednocześnie (np. dwie zakładki przeglądarki) bez blokowania. Plus: kod jest krótki i czytelny.
Skrypt opowiedziany jak zwykłą historię
Bez kodu, w jednym akapicie:
„Cześć, jestem Telefonistka. Po uruchomieniu sprawdzam, czy mam wszystkie potrzebne narzędzia. Szukam klucza do GPT — bez niego nie zaczynam. Otwieram słownik 9263 słów i wyciągam z niego spis treści, żeby było szybko. Czytam plik z zasadami stylu i pakuję go razem z opisem dwóch narzędzi w jedną instrukcję — to mój skrypt rozmowy.
Potem siedzę i czekam. Gdy przyjdzie pytanie z przeglądarki — biorę je, doklejam instrukcję, wysyłam do GPT przez internet. GPT może mi odpisać od razu albo poprosić o sprawdzenie konkretnego słowa w słowniku. Wtedy szybko zaglądam do mojego spisu treści (albo do pełnego słownika, jeśli pyta o szczegóły) i odsyłam to GPT. Robimy tak parę razy, aż GPT skończy. Wtedy biorę gotową odpowiedź, pakuję ją z powrotem do przeglądarki, i wracam do nasłuchu.
Działam tylko dla Twojego komputera, klucza nie pokazuję nikomu, każda rozmowa kosztuje ułamek grosza. Działam, dopóki mnie nie wyłączysz."
Skąd się bierze słownik 9263 słów
Słownik (master.json, 24 megabajty) nie powstał magicznie. Jest produkowany przez około 20 skryptów Python, które po kolei czytają źródła, liczą statystyki, generują opisy, sklejają wszystko w jedną wielką karteke. Tu opowiadam ten proces tak, jakbyś zaglądał do fabryki przez okno.
Cztery etapy produkcji:
- Surowiec — wczytanie księgi Johnsona (PDF), tekstu hebrajskiego (manuskrypty), klasycznych słowników
- Liczenie — dla każdego słowa: ile razy w Biblii, gdzie, w jakich kontekstach
- Pisanie kart — z pomocą GPT generujemy opisy w prostym języku
- Składanie — wszystko trafia do jednego wielkiego pliku (master.json)
Etap 1 — Surowiec
Wyciąga analizy z 17 tomów Johnsona
Skrypt otwiera 17 plików PDF z dziełami amerykańskiego biblisty Johnsona (XIX/XX w.). Czyta je strona po stronie, rozpoznaje gdzie zaczyna się analiza hebrajskiego słowa (np. „BARA, H1254"), wycina ten kawałek i zapisuje jako osobny rekord. Tak powstaje surowa baza ~3000 wpisów Johnsona — to jest oryginalny materiał, na którym buduje się resztę.
Buduje rekonstrukcję tekstu Starego Testamentu
Porównuje dwa najstarsze świadectwa: Westminster Leningrad Codex (hebrajski masorecki, X w.) i Septuagintę (grecki przekład z III w. p.n.e.). Tam, gdzie się zgadzają — pewność wysoka. Tam, gdzie się różnią — flaguje miejsce do oceny. Wynik: krytyczny tekst ST, do którego mapowane są wszystkie słowa.
Wczytuje klasyczne słowniki
Pobiera publicznie dostępne słowniki naukowe — Gesenius (XIX w., niemiecki standard hebrajskiego) i Jastrow (słownik aramejski-żydowski). Wyciąga z nich definicje, formy gramatyczne, odniesienia do wersetów. To klasyczny aparat naukowy, który dorzucamy obok analiz Johnsona — żeby mieć porównanie.
Etap 2 — Liczenie
Dla każdego słowa liczy „ile, gdzie, kiedy"
Dla wszystkich 9263 słów hebrajskich liczy:
- ile razy występuje w całym Starym Testamencie (np. elohim — 2600 razy)
- w ilu księgach (np. 39 ksiąg = cały kanon, vs 2 księgi = rzadkie)
- w ilu wersetach (czasem w jednym wersecie kilka razy)
- gdzie pierwszy raz (np. bara — Rdz 1:1)
- w jakich księgach najczęściej (np. shamayim — Psalmy 70×, Genesis 39×, Powtórzonego Prawa 38×)
Bez tego nie da się powiedzieć „bara to słowo rzadkie" (53 razy w 23 księgach) ani „elohim to słowo bardzo częste". Liczby są fundamentem metody Johnsona — z nich wynika reszta.
Szuka wzorców i niespodzianek
Idzie krok dalej — szuka nietypowych zbiegów w korpusie. Na przykład: które słowa występują tylko w jednej księdze (specjalista)? Które tylko w określonych kontekstach (np. chesed — głównie w Psalmach)? Które są hapax legomena (występują dokładnie raz w całej Biblii, jak ḥăthullāh z Hi 38:9 — „powijak")? Te statystyczne odkrycia trafiają potem do kart jako „ciekawostka" albo „klucz interpretacyjny".
Etap 3 — Pisanie kart (z pomocą GPT)
Pyta GPT o polskie znaczenie każdego słowa
Bierze listę 9263 słów hebrajskich i jedno po drugim wysyła do GPT: „daj polskie znaczenie tego słowa, w prostym języku, dla 15-latka". GPT odpowiada, skrypt zapisuje. To masowa praca — kosztuje kilka dolarów (płaci się za każde zapytanie), trwa kilka godzin. Wynik: każde hasło ma krótkie, czytelne polskie tłumaczenie.
Generuje pełne karty metodą Johnsona
Dla najważniejszych słów (top N — kilkaset) generuje pełne karty w stylu Johnsona: nie tylko polskie znaczenie, ale też „obraz" (jaki obraz słowo niesie), „odkrycie" (co tradycja myli), „klucz interpretacyjny" (jak to zmienia czytanie), „klasy semantyczne" (różne odcienie sensu z procentami). Każda karta to ~3000 znaków — głęboka analiza. GPT pisze, skrypt zapisuje.
To jest kosztowny etap (ok. $50 dla 200 słów). Ale to tu rodzą się wpisy, które potem czytasz w słowniku.
Uzupełnia resztę słów (lżejsza wersja)
Dla wszystkich pozostałych słów (~9000) generuje krótsze karty — tylko podstawowe pola, bez pełnej analizy Johnsona. To tańsza wersja dla słów rzadszych lub mniej teologicznie istotnych. Dzięki temu każde z 9263 słów ma jakiś wpis w słowniku, nawet jeśli nie zostało jeszcze ręcznie pogłębione.
Silnik 5 kroków metody Johnsona
To biblioteka używana przez powyższe skrypty. Implementuje pięć kroków metody Johnsona:
- Zebranie wszystkich wystąpień słowa w ST (z compute_stats)
- Klasyfikacja na „determinate" (gdzie sens jest jednoznaczny) vs „indeterminate" (gdzie sens sporny)
- Eliminacja — szukamy znaczenia, które pasuje do WSZYSTKICH determinate przypadków bez wyjątku
- Test — sprawdzamy, czy znalezione znaczenie pasuje też do indeterminate
- Konfrontacja z tradycją — pokazujemy, gdzie tradycja czyta inaczej i dlaczego się myli
Te pięć kroków to logika używana przez skrypty AI — promptu trafia do GPT z tym schematem, żeby pisał zgodnie z indukcyjną metodą Johnsona, nie „od siebie".
Etap 4 — Składanie
Sklejać wszystko w jeden plik (master.json)
Ostatni krok. Skrypt bierze osobne pliki ze wszystkich poprzednich etapów:
- 22 pliki
letter_*.json(po jednym na hebrajską literę, w sumie 9263 wpisy ze szczegółami) - statystyki z
stats/H*.json(ile razy, w ilu księgach) - klasyczne słowniki
lexicon.jsonl,halot.db - analizy Johnsona
johnson_dictionary.json - tłumaczenia
biblia_2026_*.json,meanings_pl.json - mapowanie hebr. → grecki
h_to_g_extended.json
…i scala je w jedną wielką strukturę: każde z 9263 słów dostaje jedno hasło ze wszystkimi danymi. Wynikiem jest plik data/master.json — 24 megabajty uporządkowanej wiedzy. To jest słownik, z którego korzysta cała reszta (czytaj.html, analiza.html, serve_chat.py).
Cały proces jak fabryka książek
Jeśli ciężko Ci śledzić, kto z kim się dogaduje — pomyśl o tym jak o fabryce, która produkuje wielką encyklopedię.
Stoją tu kontenery z surowcem: 17 tomów Johnsona, hebrajski tekst Biblii, klasyczne słowniki. Pracownicy (skrypty 1. etapu) rozpakowują kontenery i sortują surowiec.
Tu liczy się każdy element. „Ile razy?", „Gdzie?", „W jakim kontekście?". Wynik: tabele statystyk dla każdego słowa.
Tu siedzą redaktorzy (skrypty + GPT), którzy piszą opisy w prostym języku. Mają instrukcję stylu (CLAUDE.md) i dane z hali 2.
Tu wszystkie kawałki — surowiec, pomiary, opisy — zostają sklejone w jedną wielką encyklopedię. Produkt finalny: master.json.
Fabryka pracuje raz na jakiś czas — kiedy chcemy dodać nowe dane albo przebudować słownik. Każda zmiana w surowcu (np. nowy tom Johnsona) → przerabiamy hale 1-4, dostajemy nowy master.json. Reszta projektu (czytaj.html, analiza.html, serve_chat.py) po prostu czyta gotowy produkt — nie zastanawia się, jak powstał.
Liczby, które zaszły do master.json
Tyle waży gotowy słownik (jeden plik JSON). Mieści się w pamięci przeglądarki, ale jest zauważalny w pobieraniu.
Każde z numerem Stronga (np. H430), hebrajskim zapisem, transliteracją, polskim znaczeniem i statystykami.
Słów z pełną analizą metodą Johnsona (obraz, odkrycie, klucz, synth, klasy). Reszta ma podstawowe pola.
2094 słowa zweryfikowane (sure), 7043 z danymi ale jeszcze niezweryfikowane manualnie (partial).
Zasada dwóch świadków — filologiczny fundament
Skąd wiemy, że jakieś hebrajskie słowo brzmiało tak, a nie inaczej? Skąd pewność, że werset Iz 53:5 nie został przerobiony przez wieki kopiowania? Projekt opiera się na biblijnej zasadzie z Pwt 19:15: „na podstawie dwóch lub trzech świadków opiera się każda sprawa". Stosujemy ją do samego tekstu Biblii.
MT · DSS · LXX
Mamy trzy niezależne źródła tego samego Starego Testamentu, z różnych epok i tradycji. Jeśli się zgadzają — pewność wysoka. Jeśli się różnią — wiemy, gdzie szukać starszej / lepszej wersji.
Tekst standardowy hebrajski, zachowany przez Masoretów. Najlepiej udokumentowany rękopis: Codex Leningradensis (1008 r. n.e.) — najstarszy kompletny ST hebrajski. Plik: wlc_verses.jsonl (23 213 wersetów).
Zwoje znad Morza Martwego — odnaleziono w 1947 r. w jaskiniach Qumran. Najstarsze fragmenty hebrajskiej Biblii (np. Wielki Zwój Izajasza, 1QIsaa). Świadek tysiąc lat starszy od Masorety. Plik: dss_biblical.jsonl (7 945 wersetów).
Pierwszy grecki przekład ST, dokonany w Aleksandrii przez 70 tłumaczy żydowskich (stąd „Siedemdziesięciu"). Cytowany przez Jezusa i apostołów. Świadek jaką wersję hebrajskiego tłumaczy — czasem inną niż MT. Plik: lxx_verses.jsonl (30 325 wersetów).
Cały korpus został przeanalizowany w pliku two_witnesses.json. Wyniki porównania DSS vs MT w 7 945 wersetach:
Identyczne — DSS = MT co do litery. Tekst tysiąc lat starszy zgadza się z masoretami.
Ortograficzne — różnice tylko w pisowni (waw plene/defective), bez zmiany znaczenia. Sens taki sam.
Warianty merytoryczne — DSS i MT mają różne słowa lub zdania (25 230 różnic). Tutaj projekt ostrożnie ocenia, który świadek jest pierwotny.
Każde słowo dostaje confidence: confirmed_3 (3 świadków zgodnych) · corroborated (≥2) · confirmed_dss · wlc_standard (tylko MT) · orthographic · lacuna (brak).
Praktycznie: jeśli wpis w słowniku cytuje werset jako kluczowy dowód, my sprawdzamy, ilu świadków go potwierdza. „1 Krl 8:9 mówi, że w Arce były TYLKO tablice" — czy DSS i LXX też tak mają? Jeśli tak — confirmed_3, mocny dowód. Jeśli tylko MT — słabszy, zaznaczamy w karcie. To uczciwa metoda, nie wybiórcze cytowanie tylko tych źródeł, które pasują do tezy.
Z jakich słowników korzysta projekt
Nie zmyślamy znaczeń. Każde hebrajskie słowo jest sprawdzane w siedmiu klasycznych słownikach naukowych — od XIX wieku po XXI. Razem tworzą filologiczny fundament, na którym GPT pisze opisy w prostym języku.
Brown–Driver–Briggs (1906). Klasyczny słownik hebrajsko-angielski, do dziś standard. Etymologia, definicje, cytaty wersetów. 8 091 wpisów w pełnej (niedrukowanej) wersji.
Hebrew and Aramaic Lexicon of the Old Testament (1994–2000). Najlepszy naukowy słownik XX w., polska wersja w PDF rozpoznana OCR-em. 7 577 haseł z indeksem pełnotekstowym (FTS5).
Numery Stronga (1890) — najsłynniejszy system identyfikacji słów (H1 do H8674). TBESH (Translators Brief Expanded Strong's Hebrew) — rozszerzone glosy. 9 887 wpisów.
Wilhelm Gesenius (XIX w.) — niemiecki standard gramatyki hebrajskiej. Punkty gramatyczne podlinkowane do konkretnych Strongów. 169 paragrafów. Klasyka, której uczy się każdy hebraista.
Marcus Jastrow (1903) — słownik Targumów (aramejskich parafraz Biblii) i Talmudu. Pokazuje, jak rabini rozumieli hebrajskie słowa. 107 lematów (głównie rzeczowniki).
Mapowanie greckich słów Septuaginty na hebrajskie Strongi. Pokazuje, jak Aleksandryjczycy tłumaczyli hebrajskie słowa na grecki. 14 176 mapowań, kluczowe dla NT.
Online'owy projekt żydowski — łączony BDB + Klein + Jastrow z transliteracji. Bonus: synonimy, pokrewne, gramatyka. Drugi opinia obok HALOT.
Analizy z 17 tomów Paula Johnsona (XIX/XX w.) — autor metody indukcyjnej, którą projekt stosuje. Surowy materiał wyciągnięty z PDF-ów, ~3000 wpisów. To NIE jest klasyczny słownik — to metoda.
Po co aż siedem słowników? Bo żaden pojedynczy nie jest doskonały. BDB jest klasyczny, ale stary (1906) — czasem przestarzały filologicznie. HALOT jest najlepszy naukowo, ale tylko po niemiecku i polsku. Sefaria i Jastrow dają perspektywę żydowską / talmudyczną. Stary Strong jest najprostszy, ale powierzchowny. Gesenius — gramatyka. LXX lexicon — kontekst grecki. Pokrycie kilkoma słownikami = większa pewność.
Manuskrypty — fizyczne źródła
Słowniki opisują słowa. Manuskrypty dostarczają sam tekst — jego konkretne litery. Te trzy korpusy są naszym fizycznym źródłem prawdy.
Westminster Leningrad Codex. Cyfrowa transkrypcja Codex Leningradensis (1008 r. n.e.) — najstarszego kompletnego ST hebrajskiego. Z masoreckimi punktami samogłoskowymi i akcentami kantylacyjnymi.
Zwoje znad Morza Martwego. ~900 fragmentów odnalezionych 1947-56 w jaskiniach. Zawierają każdą księgę ST oprócz Estery. Tysiąc lat starsze niż MT. Świadectwo „przed-masoreckie".
Septuaginta. Najstarszy grecki przekład ST, dokonany III-II w. p.n.e. w Aleksandrii. Najczęściej cytowany przez autorów NT (Mateusz, Łukasz, Paweł). Świadek hebrajskiego sprzed istniejących rękopisów hebrajskich.
Plik critical_text_full.json — rekonstrukcja powstała z porównania WLC ↔ DSS ↔ LXX. Każde słowo ma poziom pewności. Tu mieszka „tekst, który najpewniej napisał autor".
Dlaczego to ważne? Bo nikt nie ma „oryginału". Pierwsze odpisy Biblii zaginęły dawno temu. To, co mamy — to kopie kopii kopii. Im więcej niezależnych świadków zgadza się ze sobą, tym bliżej jesteśmy oryginału. Trzej powyżsi są od siebie tak różni (różne języki, różne kraje, różne stulecia), że ich zgodność = mocny argument na rzecz autentyczności tekstu.
Dodatkowe źródła pomocnicze
STEPBible-Data — morfologia (forma gramatyczna każdego słowa) i Strong# dla całego WLC.
MAM-parsed — drugi niezależny parsowany WLC do walidacji morfologii.
HebrewLexicon — BDB rozwinięty + Mickelson's Enhanced Strong's.
STEPBible NT manuskrypty — dla Nowego Testamentu (greckie) tę samą zasadę.