Pierwsza faza obejmowała benchmarkowanie bazowych modeli językowych bez jakiegokolwiek fine-tuningu — celem było ustalenie linii bazowej i zrozumienie potencjału poszczególnych modeli przed rozpoczęciem treningu.

Phase 1 involved benchmarking baseline language models without any fine-tuning — the goal was to establish a baseline and understand the potential of each model before starting training.

Poniższy wykres przedstawia szacunkowe zapotrzebowanie na pamięć VRAM dla poszczególnych modeli w formacie FP16. Wartości obliczono jako ~2 bajty × liczba parametrów, co odpowiada minimalnej pamięci potrzebnej do załadowania modelu. Im niższy pasek, tym mniejsze wymagania sprzętowe — modele poniżej 6 GB można uruchomić na tańszych kartach GPU. Testy przeprowadzono na AMD 7900 24GB z 64GB RAM, Ubuntu 24.04 LTS.

The chart below shows estimated VRAM requirements for each model in FP16 format. Values are calculated as ~2 bytes × parameter count, representing the minimum memory needed to load the model. Lower bars indicate lower hardware requirements — models under 6 GB can run on more affordable GPUs. Tests were conducted on AMD 7900 24GB with 64GB RAM, Ubuntu 24.04 LTS.

Postawowym pytaniem, które pojawiło się na początku projektu, było: jak można określić 'wiedzę' modelu z danej dziedziny?

Przyjęta metodologia — benchmarking — została przeprowadzona poprzez generowanie przez modele zestawu pytań z danej dziedziny oraz odpowiedzi na cały zestaw pytań wygenerowanych przez wszystkie 6 modeli. Dzięki temu uzyskaliśmy spójny zbiór danych, który pozwala porównać wiedzę i umiejętności poszczególnych modeli w kontekście UK Highway Code.

The fundamental question that arose at the start of the project was: how can we measure a model's 'knowledge' in a given domain?

The adopted methodology — benchmarking — was conducted by having models generate a set of questions from a given domain and answers to the entire set of questions generated by all 6 models. This provided us with a consistent dataset that allows comparison of knowledge and capabilities of each model in the context of the UK Highway Code.

Modele przechodziły przez wiele rund generacji pytań — najpierw próba generacji JSON (2 rundy), a następnie format raw (1 runda). Tylko TinyLlama-1B wygenerował poprawny JSON; pozostałe 5 modeli nie zakończyło JSON-a (wyczerpanie tokenów), ale wszystkie 6 modeli pomyślnie wygenerowało pytania w formacie raw.

Models went through multiple rounds of question generation — first JSON format attempts (2 rounds), then raw format (1 round). Only TinyLlama-1B produced valid JSON output; the remaining 5 models failed JSON generation (token exhaustion), but all 6 models successfully generated questions in raw format.

Wszystkie wygenerowane pytania (z rund JSON + raw) zostały połączone w jeden zbiór i poddane analizie unikalności. Wynik: wysoka różnorodność przy minimalnej liczbie duplikatów.

All generated questions (from JSON + raw rounds) were merged into a single dataset and analyzed for uniqueness. Result: high diversity with minimal duplication.

Każdy model odpowiadał na wszystkie 834 unikalne pytania. Poniższe metryki pochodzą z surowych plików JSON benchmarku — dla wszystkich 6 modeli dostępne są pełne dane dotyczące czasu odpowiedzi i szybkości generowania tokenów.

Each model answered all 834 unique questions. The metrics below are extracted from raw JSON benchmark files — complete wall time and throughput data is available for all 6 models.

Zbiór 834 pytań został wygenerowany automatycznie przez modele LLM jako badanie rynku brytyjskiego na podstawie UK Highway Code. Badanie prowadzono w całości po angielsku — źródłowy materiał oraz wszystkie prompty dla modeli były w języku angielskim. Pytania pokrywają zakres tematyczny przepisów drogowych — znaki, pierwszeństwo, zaokrąglenia, prędkość, parking, procedury awaryjne, warunki atmosferyczne oraz wymagania dotyczące bezpieczeństwa pojazdów. Pełen zbiór 834 pytań został wykorzystany do benchmarku wszystkich 6 modeli.

The dataset of 834 questions was automatically generated by LLMs as a UK market study based on the UK Highway Code, with all source material and prompts provided in English. Questions cover a wide range of traffic topics — road signs, right-of-way, roundabouts, speed limits, parking, emergency procedures, weather conditions, and vehicle safety requirements. The full set of 834 questions was used to benchmark all 6 models.

Wykres porównuje wydajność 6 modeli bazowych bez fine-tuningu. Dwa wskaźniki zostały zmierzone: Total tok/s — całkowita przepustowość (włączając tokeny promptu), oraz Completion tok/s — przepustowość samego generowania odpowiedzi. Każdy model przetestowano na 834 pytaniach z UK Highway Code. Generowanie odbywało się pojedynczo, bez batchowania, na AMD 7900 24GB.

The chart compares performance of 6 baseline models without fine-tuning. Two metrics were measured: Total tok/s — total throughput (including prompt tokens), and Completion tok/s — response-only generation throughput. Each model was tested on 834 questions from the UK Highway Code dataset. Generation was performed individually, without batching, on AMD 7900 24GB.

W wyniku benchmarkowania przeprowadzonego w Fazie 1 otrzymaliśmy następujące zbiory danych:

• Zbiór pytań: 834 pytań z dziedziny UK Highway Code wygenerowanych przez 6 modeli LLM
• Zbiór odpowiedzi: odpowiedzi na 834 pytań wygenerowane przez każdy z 6 modeli (6 × 834 = 5 004 odpowiedzi)
• Dane wydajnościowe: pomiary przepustowości (tok/s) dla każdego modelu na każdym pytaniu

Do czego posłużą te zbiory w dalszych krokach?
Po treningu (LoRA/QLoRA fine-tuning, Fazy 2–3) model będzie używał tych danych do:

• Ewaluacji własnych odpowiedzi — model po treningu sam klasyfikuje i ocenia swoje odpowiedzi wygenerowane w Fazie 1
• Oceny krzyżowej — potencjalnie inny model (np. lepszy/większy) dokona oceny odpowiedzi modelu wytrenowanego
• Pomiaru postępu — porównanie jakości odpowiedzi przed i po treningu

As a result of benchmarking conducted in Phase 1, we obtained the following datasets:

• Questions dataset: 834 questions from the UK Highway Code domain generated by 6 LLM models
• Answers dataset: answers to 834 questions generated by each of the 6 models (6 × 834 = 5,004 answers)
• Performance data: throughput measurements (tok/s) for each model on each question

How will these datasets be used in subsequent steps?
After training (LoRA/QLoRA fine-tuning, Phases 2–3), the model will use these data for:

• Self-evaluation — the post-training model classifies and evaluates its own answers generated in Phase 1
• Cross-evaluation — potentially another model (e.g., better/larger) will evaluate the trained model's answers
• Progress measurement — comparison of answer quality before and after training

Zanim dane trafią do modeli embeddingowych, muszą przejść przez proces czyszczenia, segmentacji i formatowania. Ta faza obejmuje podział 31 dokumentów PDF UK Highway Code na 1,642 segmentów tekstowych (max 520 znaków), generowanie plików JSONL i metadanych, walidację gotowości danych oraz iteracyjny wybór modelu embeddingowego — wszystko w ramach przygotowania warstwy RAG (Retrieval-Augmented Generation).

Before data enters embedding models, it must go through cleaning, segmentation and formatting. This phase covers splitting 31 PDF documents of the UK Highway Code into 1,642 text segments (max 520 characters), generating JSONL files and metadata, validating data readiness, and iteratively selecting the embedding model — all as part of the RAG (Retrieval-Augmented Generation) layer preparation.

Ze względu na wykrycie 330 plików graficznych oraz ograniczenia modelu cpp-nomic-embed wyłącznie do tekstu, podjęto decyzję o wdrożeniu multimodalnego modelu embeddingowego zdolnego do jednoczesnego przetwarzania tekstu i obrazów we wspólnej przestrzeni wektorowej.

Due to the detection of 330 graphic files and the cpp-nomic-embed model's text-only limitation, a decision was made to implement a multimodal embedding model capable of processing both text and images in a shared vector space.

Retrieval-Augmented Generation (RAG) pozwala na rozszerzenie możliwości modeli językowych poprzez podłączanie zewnętrznych źródeł wiedzy. Ta faza koncentruje się na wyborze modeli embeddingowych i budowaniu pipeline'u RAG.

Retrieval-Augmented Generation (RAG) extends language model capabilities by connecting external knowledge sources. This phase focuses on selecting embedding models and building the RAG pipeline.

● Embedding model comparison — Porównanie modeli pod kątem rozmiaru, jakości i szybkości

● Vector database selection — ChromaDB vs FAISS: zalety, wady, wydajność

● Retrieval pipeline architecture — Projekt systemu od zapytania do odpowiedzi

● Chunking strategy for documents — Optymalny podział dokumentów na fragmenty

● RAG vs fine-tuning: when to use which — Kiedy wybrać RAG, a kiedy fine-tuning

● Embedding model comparison — Comparing models by size, quality, and speed

● Vector database selection — ChromaDB vs FAISS: pros, cons, performance

● Retrieval pipeline architecture — Designing the system from query to response

● Chunking strategy for documents — Optimal document splitting strategies

● RAG vs fine-tuning: when to use which — When to choose RAG vs fine-tuning

LoRA (Low-Rank Adaptation) i QLoRA (quantyzed LoRA) to metody efektywnego fine-tuningu, które pozwalają na dostosowanie dużych modeli przy użyciu minimalnej liczby parametrów i zasobów obliczeniowych.

LoRA (Low-Rank Adaptation) and QLoRA are efficient fine-tuning methods that enable adapting large models using minimal parameters and computational resources.

● LoRA vs QLoRA: trade-offs — Porównanie standardowej LoRA z kwantyzowaną wersją

● Rank, alpha, dropout configuration — Optymalne wartości parametrów treningowych

● Training duration and resource requirements — Czas i zasoby potrzebne do treningu

● Quantization levels (4-bit vs 8-bit) — Poziomy kwantyzacji i wpływ na jakość

● Tools: Unsloth, Axolotl, llama-factory — Narzędzia do automatyzacji treningu

● LoRA vs QLoRA: trade-offs — Comparing standard LoRA with quantized version

● Rank, alpha, dropout configuration — Optimal training parameter values

● Training duration and resource requirements — Time and resources needed for training

● Quantization levels (4-bit vs 8-bit) — Quantization levels and impact on quality

● Tools: Unsloth, Axolotl, llama-factory — Tools for training automation

Ostatnia faza to kompleksowa ocena wszystkich podejść — od bazowych modeli przez RAG po fine-tuning LoRA/QLoRA. Cel: wyznaczenie najlepszych konfiguracji dla różnych przypadków użycia.

The final phase is a comprehensive evaluation of all approaches — from baseline models through RAG to LoRA/QLoRA fine-tuning. Goal: identifying the best configurations for different use cases.

● Side-by-side comparison of all approaches — Bezpośrednie porównanie RAG, LoRA, QLoRA i modeli bazowych

● Before/after training metrics — Metryki przed i po treningu dla każdego modelu

● Cost-benefit analysis per method — Analiza kosztów i korzyści każdej metody

● Recommended configurations for different use cases — Rekomendacje dla różnych scenariuszy

● Lessons learned and best practices — Wnioski i najlepsze praktyki

● Side-by-side comparison of all approaches — Direct comparison of RAG, LoRA, QLoRA, and baseline models

● Before/after training metrics — Pre and post training metrics for each model

● Cost-benefit analysis per method — Cost and benefit analysis for each method

● Recommended configurations for different use cases — Recommendations for different scenarios

● Lessons learned and best practices — Key takeaways and best practices