Статус: архивная экспериментальная версия / baseline
Дата заморозки: 24 сентября 2026
Следующая версия:
NOVA_v2
Основной язык документации: русский
Тип проекта: собственная decoder-only LLM + локальный AI-ассистент + RAG-эксперименты
- Финальный технический отчёт
- Данные, веса и ограничения публикации
- Teacher-forcing diagnostic
- No-RAG quality audit
- English final report
NOVA_v1 — это первая законченная экспериментальная версия моей собственной локальной языковой модели NOVA.
Изначальная цель проекта — не просто взять готовую большую модель вроде Qwen/Llama/Mistral, немного дообучить её и назвать своей. Идея NOVA — постепенно создать собственную LLM с нуля и построить вокруг неё персонального помощника со своим характером, технической специализацией, памятью, RAG, инструментами и в будущем голосовым интерфейсом.
NOVA_v1 стала первым полным инженерным циклом этой идеи:
данные
↓
токенизация
↓
собственная GPT-подобная модель
↓
pretraining
↓
checkpoint
↓
inference
↓
RAG
↓
SafeRetriever
↓
SFT
↓
evaluation
↓
диагностика ограничений
Важно: NOVA_v1 не является готовым надёжным ассистентом.
Она сохранена как исследовательская версия и baseline, потому что именно на ней были обнаружены важные ограничения первого подхода и сформулированы требования к NOVA_v2.
Подробный технический итог проекта находится в:
NOVA_v1_FINAL_REPORT.md
Если нужно быстро понять проект с нуля, рекомендуется читать файлы в таком порядке:
1. README.md
2. NOVA_v1_FINAL_REPORT.md
3. reports/sft_teacher_forcing_diagnostic.txt
4. reports/final_quality_audit.txt
5. reports/decoding_comparison.txt
NOVA_v1 технически научилась:
-
загружать собственный checkpoint;
-
генерировать текст локально;
-
работать на CUDA;
-
использовать BF16;
-
выполнять pretraining;
-
выполнять assistant-only SFT;
-
использовать FAISS;
-
использовать multilingual E5 embeddings;
-
работать с несколькими RAG-индексами;
-
маршрутизировать запросы через SafeRetriever;
-
возвращать trusted RAG-ответ напрямую;
-
работать через локальный Gradio-интерфейс;
-
проходить набор автоматических и ручных тестов.
Но независимые тесты показали, что модель пока ненадёжна как самостоятельный универсальный ассистент.
Главный экспериментальный вывод:
SFT уменьшает teacher-forced loss
и улучшает token accuracy,
но свободная autoregressive generation
остаётся нестабильной.
Поэтому дальнейшее «латание» v1 остановлено.
Следующая версия — NOVA_v2 — будет проектироваться заново с учётом результатов v1.
Планируемая система должна состоять из нескольких независимых уровней.
Собственная базовая языковая модель:
-
decoder-only Transformer;
-
русский язык как основной;
-
английский при необходимости;
-
генерация текста;
-
базовые знания;
-
понимание общего языка;
-
техническая база.
Поведение ассистента:
-
следование инструкциям;
-
помощь в обучении;
-
помощь с Python и AI-разработкой;
-
объяснение сложного простыми словами;
-
умение признавать неопределённость;
-
нормальный диалог.
Стабильный стиль и характер:
-
спокойствие;
-
рассудительность;
-
любознательность;
-
честность;
-
уважительный тон;
-
отсутствие снисходительности;
-
мягкий юмор;
-
способность обсуждать и технические, и обычные темы.
Изменяемая память должна быть отдельной системой, а не постоянным переобучением весов.
Например:
-
факты о пользователе;
-
история проектов;
-
заметки;
-
предпочтения;
-
важные события;
-
контекст прошлых разговоров.
Внешние знания:
-
техническая документация;
-
доверенные факты;
-
пользовательские документы;
-
базы знаний;
-
заметки.
В будущем:
-
чтение файлов;
-
поиск по проекту;
-
запуск Python;
-
работа с кодом;
-
безопасное изменение файлов;
-
другие локальные инструменты.
Планируемая схема:
speech-to-text
↓
NOVA
↓
text-to-speech
Финальная базовая модель — собственный GPT-подобный decoder-only Transformer.
Основные параметры:
vocab_size = 50 257
embedding size = 768
attention heads = 12
layers = 12
context = 512 tokens
weight tying = yes
parameters = 124 009 728
То есть приблизительно:
124M параметров
Это не Hugging Face causal-LM checkpoint и не LoRA поверх готовой модели.
Архитектура реализована внутри проекта на PyTorch.
Основные файлы:
model/
├── __init__.py
├── attention.py
└── model.py
Содержит causal self-attention.
Используется PyTorch scaled dot-product attention.
Содержит:
-
GPTBlock; -
GPT; -
token embeddings;
-
learned position embeddings;
-
LayerNorm;
-
feed-forward blocks;
-
GELU;
-
output head;
-
weight tying;
-
autoregressive generation;
-
конфигурацию AdamW;
-
загрузку checkpoint;
-
проверку tied/untied weights.
Архитектура использует pre-norm блоки:
x
│
├── LayerNorm
├── causal attention
└── residual
↓
├── LayerNorm
├── FFN
└── residual
Feed-forward часть:
768
↓
3072
↓ GELU
768
NOVA_v1 использует:
tiktoken.get_encoding("gpt2")Это GPT-2 byte-level BPE.
Размер словаря:
50 257 tokens
Плюсы:
-
стабильная готовая реализация;
-
можно кодировать произвольный Unicode;
-
нет классической проблемы неизвестного
<UNK>; -
хорошо подходит по формату к GPT-подобной архитектуре.
Минус для нашей задачи:
GPT-2 tokenizer не создавался специально под русский язык.
Русские слова могут разбиваться на менее эффективные byte/subword последовательности.
Важно: это не доказано как единственная причина проблем NOVA_v1. Это одна из гипотез, которую планируется отдельно проверить в NOVA_v2.
Для NOVA_v2 предполагается исследовать tokenizer на смеси:
русский
+
английский
+
Python/code
+
технические тексты
Контекст NOVA_v1:
512 tokens
Для короткого вопроса этого хватает.
Но для будущего ассистента 512 токенов мало, особенно когда в prompt одновременно входят:
-
вопрос пользователя;
-
кусок кода;
-
traceback;
-
RAG-контекст;
-
история диалога;
-
системные инструкции.
Поэтому увеличение context length является одним из направлений NOVA_v2.
Фактическое состояние архива NOVA_v1 на момент подготовки к публикации:
data/
├── pretrain_final/
│ └── train.txt
└── val.txt
Размеры файлов:
data/pretrain_final/train.txt: 116 602 874 bytes
data/val.txt: 18 008 668 bytes
SHA-256 текущего validation corpus:
25BED3A3C6543EBBB94B42AD9297FC9095A48C89FC7CAD61B4E9EDDE2F18F692
Train corpus содержит приблизительно:
66.6M GPT-2 tokens
Важно: в финальном архиве нет файла:
data/pretrain_final/val.txt
Validation corpus физически находится в:
data/val.txt
Дополнительная проверка показала, что два файла, которые могли бы хранить историческую конфигурацию подготовки pretraining data,
config/training/pretrain_config.py
scripts/prepare_pretrain_data.py
на момент архивации существуют, но имеют размер:
0 bytes
Поэтому по сохранённому состоянию NOVA_v1 невозможно достоверно восстановить, каким именно способом путь к validation corpus передавался во время первоначального pretraining run.
Документация намеренно фиксирует то, что реально сохранилось, и не заполняет недостающую историческую информацию предположениями.
В ранних версиях проекта использовалась смесь:
- knowledge data;
- synthetic data;
- Alpaca/instruction-style data;
- автоматически сгенерированных диалогов;
- технических текстов.
Один из главных выводов NOVA_v1:
PRETRAINING DATA
≠
ASSISTANT SFT DATA
≠
PERSONALITY DATA
≠
RAG KNOWLEDGE
В NOVA_v2 эти типы данных должны быть разделены намного строже.
Большие pretraining-файлы не публикуются в GitHub и исключены через .gitignore.
GitHub-репозиторий нужен прежде всего для:
-
исходного кода;
-
конфигурации;
-
тестов;
-
скриптов;
-
документации;
-
небольших воспроизводимых datasets;
-
текстовых reports.
В GitHub не должны попадать:
-
.venv; -
большие
.ptcheckpoints; -
FAISS binary indices;
-
большие pretraining corpora;
-
caches;
-
временные файлы;
-
секреты/API keys;
-
персональная память;
-
приватные документы.
Поэтому часть файлов, описанных в README, будет отсутствовать после обычного git clone.
Это сделано намеренно.
Локальный путь внутри проекта:
out/final/best_final.pt
SHA-256:
765E3B02A8DA32E30D728BBE6A68F7B5130A5FA6726B0BA5775F22352D83231E
Метаданные:
iter_num = 45000
best_val_loss = 0.515568
architecture = tied weights
parameters ≈ 124.010M
out/candidate_sft/technical_v1_step20/best_candidate.pt
SHA-256:
19B88F804126B085AE70830E2654589EED2899E76DE65804968CE331302EDE90
Это экспериментальный checkpoint.
Он не заменяет FINAL.
out/candidate_sft/technical_v1_step120/best_candidate.pt
SHA-256:
3C1C3D89C81B16EDF6C982210BEDB33B04512FE25B7DF9BBFF6BFC10DDDD36A8
Метаданные:
iter_num ≈ 45120
SFT validation loss ≈ 1.0968
Это тоже экспериментальный checkpoint.
Checkpoints:
-
большие;
-
бинарные;
-
плохо подходят для обычной Git-истории;
-
создают огромные binary diff;
-
могут превысить ограничения GitHub.
Поэтому .pt, .pth, .ckpt, .safetensors исключаются через .gitignore.
Если понадобится отдельно опубликовать веса, лучше использовать:
-
GitHub Release;
-
Hugging Face Hub;
-
облачное хранилище;
-
model registry.
Основная финальная конфигурация:
batch_size = 4
gradient_accumulation_steps = 8
effective batch = 32 sequences
learning_rate = 1e-4
min_lr = 1e-5
weight_decay = 0.1
betas = (0.9, 0.95)
grad_clip = 1.0
max_iters = 50000
eval_interval = 1000
eval_iters = 50
save_interval = 2500
dtype = bfloat16
device = cuda
Лучший сохранённый checkpoint:
iteration 45000
best validation loss ≈ 0.515568
Важно:
pretraining validation loss нельзя напрямую сравнивать с SFT validation loss.
Это разные данные и разные режимы supervision.
RAG = Retrieval-Augmented Generation.
Упрощённая схема:
вопрос пользователя
↓
embedding
↓
поиск похожих документов
↓
найденный контекст
↓
ответ
В NOVA_v1 для embeddings используется:
intfloat/multilingual-e5-small
Размер embedding:
384
Для поиска используется FAISS.
Embedding — это числовой вектор, который представляет текст.
Условно:
"Что такое PostgreSQL?"
↓
[0.12, -0.84, 0.31, ...]
Похожие по смыслу тексты должны иметь близкие vector representations.
Это позволяет искать не только точное совпадение слов, но и смысловую близость.
FAISS — библиотека для быстрого поиска похожих vectors.
Она не является обычной SQL-базой.
Упрощённо:
тексты
↓
embeddings
↓
FAISS index
Для нового вопроса:
вопрос
↓
embedding
↓
FAISS search
↓
наиболее похожие vectors
↓
соответствующие тексты
В NOVA_v1 используется inner-product search по нормализованным embeddings.
В проекте создавались несколько экспериментальных индексов:
knowledge_index
knowledge_index_v2
technical_index
core_index
question_router
trusted_index
Binary .faiss файлы являются generated artifacts и не предназначены для обычного GitHub repository.
Большой knowledge index содержит примерно:
77 900 chunks
Вторая версия broad-index улучшала способ построения embeddings.
Но broad RAG остался экспериментальным.
Главная проблема:
retriever находит хороший контекст
↓
NOVA всё равно может
сгенерировать неправильный ответ
Technical dataset:
1 398 Q/A records
Темы включают:
-
Python;
-
Git;
-
Docker;
-
HTTP;
-
API;
-
SQL;
-
базы данных;
-
ML;
-
debugging;
-
безопасную работу с файлами и командами;
-
другие технические вопросы.
Technical retrieval в NOVA_v1 оставлен ручным режимом.
CORE — маленькая curated база доверенных ответов.
Размер:
12 records
CORE index строится по:
canonical question
+
aliases
Ответ не входит в embedding.
То есть embedding нужен, чтобы найти нужный вопрос, после чего система может вернуть заранее проверенный ответ.
В NOVA_v1 принят консервативный режим retrieval.
Логика AUTO:
AUTO
|
+--> CORE search
|
+--> score >= 0.83
| |
| +--> trusted CORE answer
|
+--> score < 0.83
|
+--> model fallback
Другие режимы:
TECHNICAL -> manual
BROAD -> manual experimental
OFF -> no RAG
Автоматический каскад:
CORE -> TECHNICAL -> BROAD
не включён намеренно.
Причина — недостаточно надёжная маршрутизация.
Первый вариант RAG работал классически:
retrieval
↓
context
↓
prompt
↓
NOVA generation
Но тесты показали:
даже если retrieval вернул правильный факт, модель может:
-
проигнорировать контекст;
-
перепутать факты;
-
переписать ответ неправильно;
-
начать галлюцинировать.
Поэтому для trusted sources появился путь:
trusted retrieval
↓
return stored answer directly
То есть модель не переписывает уже проверенный ответ.
Это один из наиболее успешных архитектурных результатов NOVA_v1.
app.py предоставляет локальный интерфейс.
Основные режимы:
Auto — безопасный
Technical — technical Q/A
Broad — экспериментальный
No RAG — только модель
UI также показывает diagnostic information и позволяет менять generation parameters.
Важно:
NOVA_v1 UI — single-turn интерфейс.
Полноценной долговременной памяти или настоящего multi-turn context пока нет.
Для проверки именно способностей FINAL checkpoint был создан тест без RAG.
Количество вопросов:
27
Generation settings:
temperature = 0
top_k = OFF
top_p = OFF
repetition penalty = 1
max_new_tokens = 160
Ручная строгая классификация:
normal = 1
partial = 5
wrong = 17
garbage = 4
Проблемы наблюдались на:
-
арифметике;
-
географии;
-
Python;
-
TCP/UDP;
-
REST;
-
Docker;
-
Git;
-
PostgreSQL;
-
SQL;
-
database concepts.
Один из более удачных участков — pandas / missing values.
Отчёт:
reports/final_quality_audit.txt
Была проверена гипотеза:
Может быть модель знает ответы, но generation settings выбраны плохо?
Были протестированы:
greedy
sampling seed 1337
sampling seed 2026
Менялись:
-
temperature;
-
top-k;
-
top-p;
-
repetition penalty.
Систематические ошибки остались.
Вывод:
decoding settings не являются основной причиной проблем.
Отчёт:
reports/decoding_comparison.txt
SFT = Supervised Fine-Tuning.
Цель — обучить pretrained модель отвечать как assistant.
Technical dataset:
total = 1398
train = 1258
val = 140
Prompt:
Пользователь: \<question>
Нова:
Loss считается только по assistant-части.
Prompt tokens маскируются:
ignore_index = -100
EOS остаётся supervised.
model.forward() не делает автоматический causal shift.
Поэтому SFT dataset строит:
sequence = prompt + answer + EOS
input_ids = sequence[:-1]
labels = sequence[1:]
Prompt labels заменяются на:
-100
Таким образом задача модели:
по текущему контексту
предсказывать следующий assistant token
Перед обучением был выполнен полный dataset test.
Результат:
TRAIN records = 1258
VAL records = 140
TRAIN truncated = 0
VAL truncated = 0
TRAIN RESULT = PASS
VAL RESULT = PASS
Среднее количество supervised tokens:
TRAIN ≈ 209.64
VAL ≈ 197.90
Отчёт:
reports/technical_sft_dataset_test.txt
Untouched FINAL:
SFT val loss = 1.561062
После 20 optimizer steps:
SFT val loss = 1.292469
Это подтвердило:
-
SFT pipeline работает;
-
gradients конечные;
-
BF16 работает;
-
checkpoint сохраняется;
-
loss уменьшается.
Но свободная generation всё ещё была плохой.
120-step run снова стартовал с исходного FINAL checkpoint.
Validation trajectory:
baseline = 1.561062
step 20 = 1.292469
step 40 = 1.201218
step 60 = 1.161714
step 80 = 1.134289
step 100 = 1.113712
step 120 = 1.096816
Loss стабильно уменьшался.
Gradients оставались нормальными.
То есть SFT-тренер не был сломан.
После 120 steps модель всё ещё ошибалась на:
-
isvs==; -
closure;
-
Docker stop vs kill;
-
COUNT / AVG;
-
простой арифметике;
-
PostgreSQL;
-
TCP/UDP;
-
REST;
-
других вопросах.
После этого был проведён главный финальный диагностический тест.
Это важно понимать.
Модель предсказывает следующий token, но предыдущие tokens в контексте являются правильными эталонными tokens.
То есть ошибка модели не портит последующий контекст.
Модель получает только prompt.
После этого каждый следующий token строится уже на основании собственных предыдущих predictions.
Если модель ошиблась:
правильный контекст
↓
ошибочный token
↓
контекст уже отличается
↓
следующая ошибка становится вероятнее
TRAIN:
examples = 1258
supervised tokens = 263724
token-weighted loss = 1.611952
perplexity = 5.0126
token accuracy = 64.51%
first-token accuracy = 63.83%
whole-answer exact = 0.00%
VAL:
examples = 140
supervised tokens = 27706
token-weighted loss = 1.557662
perplexity = 4.7477
token accuracy = 65.01%
first-token accuracy = 65.00%
whole-answer exact = 0.00%
TRAIN:
loss = 1.082352
perplexity = 2.9516
token accuracy = 70.80%
first-token accuracy = 67.65%
whole-answer exact = 0.00%
VAL:
loss = 1.100093
perplexity = 3.0044
token accuracy = 69.87%
first-token accuracy = 65.00%
whole-answer exact = 0.00%
TRAIN:
loss
1.611952 -> 1.082352
token accuracy
64.51% -> 70.80%
first-token accuracy
63.83% -> 67.65%
VAL:
loss
1.557662 -> 1.100093
token accuracy
65.01% -> 69.87%
first-token accuracy
65.00% -> 65.00%
То есть SFT действительно изменил модель и повысил вероятность правильных target tokens.
Но этого оказалось недостаточно для стабильной свободной generation.
Были взяты реальные TRAIN-вопросы, которые модель видела во время SFT.
Даже на них SFT-120 быстро уходила с правильной траектории.
Длина правильного token-prefix для восьми sample:
1
11
2
5
1
2
1
1
Пример:
правильный ответ:
Причина: ...
модель:
Причина: Причина: Причина: Причина: ...
Другой пример:
задача:
написать clamp()
модель правильно начинает как Python-код,
но затем уходит в нерелевантную функцию.
Например:
def add(x, y):
return x + yПолный отчёт:
reports/sft_teacher_forcing_diagnostic.txt
Экспериментально подтверждено:
SFT pipeline работает
↓
teacher-forced loss уменьшается
↓
teacher-forced token accuracy растёт
↓
НО
↓
autoregessive generation
остаётся нестабильной
Тесты не доказывают одну конкретную первопричину.
Вероятные факторы:
-
качество pretraining corpus;
-
объём качественных pretraining данных;
-
GPT-2 tokenizer для русского;
-
capacity модели;
-
context 512;
-
раннее смешение разных типов данных;
-
слишком большая задача для узкого technical SFT.
Нельзя утверждать без дополнительных экспериментов:
"во всём виноват tokenizer"
"124M всегда слишком мало"
"technical dataset плохой"
"SFT не работает"
Корректный вывод:
текущая комбинация base pretraining, tokenizer, model capacity, corpus и SFT strategy не дала надёжного standalone assistant behavior.
Потому что 120-step experiment уже показал:
-
стабильное обучение;
-
существенное улучшение teacher-forced metrics;
-
отсутствие сопоставимого улучшения free generation.
Продолжать увеличивать число шагов без изменения фундаментальных условий означало бы обучать вслепую.
Поэтому NOVA_v1 заморожена.
Основные направления:
1. новый анализ корпуса;
2. строгая очистка данных;
3. отдельный tokenizer для RU + EN + code;
4. более длинный context;
5. размер модели выбирается после оценки корпуса;
6. pretraining и SFT строго разделены;
7. base model оценивается ДО SFT;
8. general assistant SFT;
9. technical SFT;
10. personality SFT;
11. отдельная Memory;
12. RAG;
13. Tools / Agent;
14. Voice;
15. benchmark NOVA_v1 vs NOVA_v2.
Основные части:
NOVA_v1/
│
├── app.py
├── README.md
├── NOVA_v1_FINAL_REPORT.md
├── requirements.txt
├── .gitignore
│
├── config/
│ ├── runtime_config.py
│ └── training/
│
├── model/
│ ├── attention.py
│ └── model.py
│
├── inference/
│ ├── assistant.py
│ └── chat.py
│
├── rag/
│ ├── embedder.py
│ ├── vector_store.py
│ ├── retriever.py
│ ├── reranker.py
│ └── safe_retriever.py
│
├── train/
│ ├── dataset.py
│ ├── trainer.py
│ ├── technical_dataset.py
│ └── technical_trainer.py
│
├── data/
│ ├── pretrain_final/
│ ├── knowledge/
│ └── nova_technical_v1_1/
│
├── scripts/
├── tests/
├── reports/
├── out/
└── archive/
Точное дерево проекта на момент заморозки:
reports/nova_v1_final_tree.txt
Рекомендуемый порядок.
README.md
Сначала понять общую систему.
model/model.py
Здесь находится сама языковая модель.
model/attention.py
Здесь attention.
inference/assistant.py
Здесь checkpoint превращается в работающий assistant.
rag/embedder.py
rag/vector_store.py
rag/safe_retriever.py
Здесь retrieval.
train/technical_dataset.py
train/technical_trainer.py
Здесь assistant-only SFT.
tests/
reports/
Здесь видно, как проверялись гипотезы и почему принимались решения.
Если проект анализирует другая AI-система, полезный порядок:
1. README.md
2. NOVA_v1_FINAL_REPORT.md
3. model/model.py
4. model/attention.py
5. inference/assistant.py
6. rag/safe_retriever.py
7. train/technical_dataset.py
8. train/technical_trainer.py
9. reports/sft_teacher_forcing_diagnostic.txt
10. reports/final_quality_audit.txt
Важно сообщить AI:
-
NOVA_v1 заморожена;
-
SFT checkpoint не заменяет FINAL;
-
старые абсолютные пути в reports являются историческими;
-
большие weights/datasets намеренно отсутствуют в GitHub;
-
дальнейшее развитие идёт в NOVA_v2.
Перейти в проект:
cd G:\NOVA\NOVA_v1
Создать новое virtual environment:
python -m venv .venv
Активировать:
.\.venv\Scripts\Activate.ps1
Обновить pip:
python -m pip install --upgrade pip
Установить зависимости:
pip install -r requirements.txt
Проверить:
pip check
Важно: .venv не переносится через GitHub.
На каждом компьютере его нужно создавать заново.
Изначально clean-project назывался:
NOVA_project_NEW
После завершения экспериментов:
NOVA_v1
Поэтому старые reports/checkpoint metadata могут содержать:
G:\NOVA\NOVA_project_NEW
Это не ошибка.
Это исторический абсолютный путь на момент запуска соответствующего эксперимента.
Старые reports специально не переписываются задним числом.
GitHub repository по умолчанию не содержит .pt weights.
Для локального inference нужно отдельно поместить FINAL checkpoint:
out/final/best_final.pt
Затем проверить SHA-256:
Get-FileHash .\out\final\best_final.pt -Algorithm SHA256
Ожидаемый hash:
765E3B02A8DA32E30D728BBE6A68F7B5130A5FA6726B0BA5775F22352D83231E
Если hash отличается, это уже другой файл.
После установки dependencies и размещения checkpoint:
python .\app.py
Локальный адрес:
http://127.0.0.1:7860
Quality audit:
python .\tests\test_final_quality_audit.py
Decoding comparison:
python .\tests\test_decoding_comparison.py
SafeRetriever:
python .\tests\test_safe_retriever.py
Grounded answer path:
python .\tests\test_grounded_answer_path.py
Teacher-forcing diagnostic:
python .\tests\test_sft_teacher_forcing_diagnostic.py
Часть тестов требует локальные:
-
checkpoints;
-
datasets;
-
FAISS indices.
Если они исключены из GitHub, соответствующий тест без них закономерно не запустится.
reports/ — важная часть repository.
Это не временные logs.
Reports сохраняют экспериментальную историю:
-
что проверялось;
-
какими параметрами;
-
что получилось;
-
почему было принято следующее решение.
Особенно важны:
final_quality_audit.txt
decoding_comparison.txt
technical_sft_dataset_test.txt
technical_sft_training.txt
sft_candidate_comparison.txt
sft_teacher_forcing_diagnostic.txt
core_rag_build_report.txt
core_rag_test.txt
core_gate_test.txt
technical_rag_build_report.txt
technical_rag_test.txt
broad_vs_technical_rag.txt
safe_retriever_test.txt
assistant_safe_rag_test.txt
rag_prompt_modes_test.txt
grounded_answer_path_test.txt
Некоторые старые reports могут быть на английском.
Они сохранены без переписывания, чтобы не изменять исторические результаты экспериментов.
Новая документация проекта ведётся на русском.
Часть текста, с которой работает LLM.
Один token не обязательно равен одному слову.
Алгоритм:
текст -> token IDs
и обратно.
Byte Pair Encoding.
Один из способов построения tokenizer.
Сохранённое состояние модели.
Обычно содержит weights и training metadata.
Числовые параметры neural network.
Именно они изменяются во время обучения.
Базовое обучение language model предсказывать следующий token на большом corpus.
Supervised Fine-Tuning.
Дообучение pretrained модели на примерах:
instruction / question
↓
desired answer
Во время обучения/оценки модель получает правильные предыдущие target tokens.
Модель получает prompt, а затем использует собственные предыдущие predictions для генерации следующих tokens.
Числовой vector, представляющий текст.
Retrieval-Augmented Generation.
Система ищет внешние знания перед формированием ответа.
Библиотека для быстрого поиска похожих vectors.
Дополнительная модель, которая может переупорядочить найденные retrieval results.
Метрика language modeling.
Обычно меньшая perplexity лучше в рамках одного и того же evaluation setup.
Нельзя бездумно сравнивать perplexity на разных datasets/objectives.
Никогда не публиковать:
.env
API keys
access tokens
passwords
private keys
личную память
приватные документы
секретные конфиги
Если секрет случайно попал в публичный Git repository, недостаточно просто удалить файл следующим commit.
Нужно:
1. немедленно отозвать/rotate secret;
2. затем очищать Git history.
.gitignore не удаляет уже tracked files.
Он только говорит Git:
новые подходящие файлы не нужно автоматически добавлять.
Поэтому перед первым push необходимо проверить:
git status
И после git add обязательно:
git diff --cached --name-only
Эта команда показывает, что именно попадёт в следующий commit.
Reports относительно маленькие и позволяют восстановить логику проекта.
По ним другой разработчик или AI может увидеть:
-
реальные результаты;
-
неудачные эксперименты;
-
успешные эксперименты;
-
параметры тестов;
-
причину появления NOVA_v2.
Поэтому текстовые reports являются частью проекта.
NOVA_v2 не создаётся по схеме:
copy NOVA_v1
rename
continue patching
Она начинается как новый проект.
Но отдельные проверенные идеи могут быть перенесены:
-
checkpoint validation;
-
atomic saving;
-
evaluation methodology;
-
SafeRetriever concept;
-
структура reports;
-
подход к тестированию.
Каждый переносимый компонент должен заново проверяться в v2.
Успех NOVA_v1 не означает:
"получился аналог ChatGPT"
Результат версии:
custom Transformer
+
собственный pretraining
+
реальные checkpoints
+
local inference
+
RAG
+
SFT
+
evaluation
+
диагностика failures
+
понятные требования к v2
Это законченная первая исследовательская итерация.
NOVA_v1
========
Custom LLM YES
Custom GPT implementation YES
Training from scratch YES
Local GPU inference YES
CUDA / BF16 YES
RAG YES
SafeRetriever YES
Gradio UI YES
Assistant-only SFT YES
Evaluation suite YES
Reliable standalone assistant NO
Reliable generative grounding NO
Stable SFT free generation NO
Development FROZEN
Role BASELINE / EXPERIMENT
Next NOVA_v2
Перед написанием основной модели NOVA_v2 будет создан отдельный design document:
NOVA_v2_DESIGN.md
В нём должны быть заранее определены:
-
цель модели;
-
corpus;
-
tokenizer;
-
architecture;
-
context length;
-
parameter count;
-
training budget;
-
throughput;
-
evaluation;
-
assistant SFT;
-
personality;
-
memory;
-
RAG;
-
tools;
-
voice.
Главное правило второй версии:
сначала данные, архитектурное обоснование и критерии проверки — потом длинное обучение.
NOVA_v1 — первая законченная попытка построить NOVA как собственную локальную LLM.
Она не достигла конечной цели универсального персонального AI-ассистента.
Но дала важный результат:
-
рабочий ML pipeline;
-
работающую custom architecture;
-
набор воспроизводимых экспериментов;
-
чёткие отрицательные результаты;
-
понимание границ v1;
-
требования к следующей версии.
Поэтому NOVA_v1 не удаляется и не переписывается задним числом.
Она остаётся неизменным baseline.
Дальнейшее развитие происходит в:
NOVA_v2