Проверка качества эталонов
В режимах PRIZMA и SLOI серверу нужны эталоны: тексты, которые описывают ваши семантические ядра. Эталоны задают систему координат для автоматического sign_auto, core_mix, семантических мостов и диагностики дрейфа.
Хороший эталон описывает область как рабочий контекст: задачи, термины, методы, типичные материалы и границы. Одних ключевых слов недостаточно. Если ядро называется Бизнес, эталон должен говорить про рынок, клиентов, продажи, упаковку и экономику продукта. Если ядро называется Инженерия, эталон должен говорить про код, архитектуру, инфраструктуру, тесты и эксплуатацию.
После запуска calibrate_cores сервер выводит попарные косинусы между эталонами в двух вариантах: сырые и после центрирования.
Анизотропия эмбеддингов
Трансформерные эмбеддинги часто страдают от анизотропии: осмысленные тексты собираются в общий векторный фон, и косинусы между разными текстами выглядят завышенными. Поэтому сырые значения могут быть похожими даже у разных доменов.
Mean-centering вычитает общий центр эталонов и показывает, расходятся ли домены относительно собственной системы координат базы.
μ = mean(S, D, E)
S' = S - μ
D' = D - μ
E' = E - μПосле такого сдвига общий фон уходит на второй план, и различия между выбранными ядрами становятся видимыми.
Реальный пример расчёта
Ниже сохранённый результат calibrate_cores для стартовых эталонов S/D/E из config.template.yaml с моделью text-embedding-granite-embedding-278m-multilingual через LM Studio.
S/D/E здесь служат переносимым примером трёх хорошо различимых областей:
- S — Systems Analysis: обратные связи, эмерджентность, кибернетика, сложные системы.
- D — Data & Science: физика, космология, материя, энергия, пространство-время.
- E — Engineering: код, ML, инфраструктура, деплой, рабочие системы.
=== Pairwise Cosine (raw) ===
S-D: 0.5894 S-E: 0.5862 D-E: 0.6022
S-S: 1.0000 D-D: 1.0000 E-E: 1.0000
=== Pairwise Cosine (mean-centered) ===
S-D: -0.5059 S-E: -0.5117 D-E: -0.4822
S-S: 1.0000 D-D: 1.0000 E-E: 1.0000Сырые значения около 0.59-0.60 показывают общий embedding-фон, после центрирования междоменные значения стали отрицательными: эталоны разошлись в разные стороны.
Smoke test эталонов
Следующая проверка показывает, узнает ли классификатор собственные эталоны. Это не вероятность и не оценка всей базы: эталон проходит тот же путь, что и обычная заметка, затем сравнивается со всем набором доменов. Сервер переводит scores в проценты через spread-normalization.
| Эталон | S % | D % | E % | Доминанта | Spread |
|---|---|---|---|---|---|
| S (Systems Analysis) | 99.6 | 0.4 | 0.0 | S | 1.5117 |
| D (Data & Science) | 0.0 | 98.5 | 1.5 | D | 1.5059 |
| E (Engineering) | 0.0 | 1.9 | 98.1 | E | 1.5117 |
Все три эталона возвращаются к своему знаку выше 98%. Значения spread около 1.5 сильно выше стандартного порога sign_spread = 0.05, поэтому базовая цепочка расчета работает устойчиво.
Как классифицируется заметка
Для новой заметки сервер использует тот же центр эталонов:
note' = note - μ
score_S = cosine(note', S')
score_D = cosine(note', D')
score_E = cosine(note', E')Важно, что из заметки вычитается тот же μ, который был посчитан по исходным эталонам. Так заметка и эталоны оказываются в одной системе координат.
Дальше сервер считает разброс:
spread = max(score) - min(score)Если spread < sign_spread, заметка слишком одинаково похожа на все ядра, и уверенный доменный знак не назначается. Если разброс достаточный, scores переводятся в проценты. Домен попадает в sign_auto, если проходит pattern_second_sign_threshold; результат считается уверенным, если ведущий домен проходит confident_spread.
sign_auto не заменяет ручной sign. Он показывает, как текст выглядит относительно эталонов. Ручная онтология остаётся главным слоем, а автоматика помогает увидеть совпадения, слабые места и дрейф.
Плохой результат
Условный слабый набор эталонов может выглядеть так:
=== Pairwise Cosine (mean-centered) ===
S-D: 0.08 S-E: -0.03 D-E: 0.05Такой результат — тревожный сигнал: после центрирования домены почти не разошлись. Обычно причина в том, что тексты эталонов говорят одними и теми же общими словами: «система», «модель», «структура», «процесс».
Плохой smoke test выглядел бы так:
| Эталон | S % | D % | E % | Доминанта | Spread |
|---|---|---|---|---|---|
| S | 42 | 31 | 27 | S | 0.1500 |
| D | 35 | 40 | 25 | D | 0.1400 |
| E | 30 | 28 | 42 | E | 0.1600 |
Доминанта есть формально, но классификатор почти не различает домены. Решение простое: убрать общие слова, добавить предметный язык и явно обозначить границы между соседними областями.
Целевые значения
| Метрика | Цель |
|---|---|
| Междоменные после центрирования | < 0.3; отрицательные значения лучше |
| Косинус эталона с самим собой | 1.0 как проверка расчёта |
| Сырые междоменные | 0.5-0.75 нормально для трансформерных embeddings |
| Smoke test эталонов | > 90% для каждого эталона |
| Spread | заметно выше sign_spread |
Эти значения работают как ориентиры для диагностики. После смены embedding-модели или текстов эталонов числа нужно пересчитать.
Как воспроизвести расчёт
Для проверки используйте те же тексты эталонов и ту же модель эмбеддингов:
nouz-calc-etalons --config config.yamlДля LM Studio можно явно задать endpoint и модель:
set EMBED_API_URL=http://127.0.0.1:1234/v1
set EMBED_MODEL=text-embedding-granite-embedding-278m-multilingual
nouz-calc-etalons --config config.yamlЕсли меняете домены, модель или язык базы, старые косинусы уже не доказывают качество нового набора.