Fact-check статей Кодексов РК
29 апреля 2026, вечер. Критическая находка: все 3 топовые LLM (Perplexity, Claude Sonnet 4.5, Gemini 3.1 Pro) синхронно ошиблись в трактовке ст.156 ТК РК и ряда других статей. Подтверждено проверкой Камала на adilet.zan.kz + параллельной сессией Opus 4.7.
Ключевые открытия
1. Системный LLM bias на КЗ-кодексах
Все обучавшиеся на russian internet модели имеют баяс «ст.156 ≈ охрана труда» потому что: - В ТК РФ ст.156 из «Оплата труда в особых условиях» — тема близка к ОТ - HR-сайты часто связывают различные ст.156 в ОТ-контексте - Реальность: в ТК РК ст.156 = коллективные переговоры (из Главы 15)
Вывод: LLM-as-judge eval НЕ работает на фактологии КЗ-кодексов. Все судьи имеют общий source bias. Только ручная сверка с adilet.zan.kz даёт истину.
2. Карта проверенных статей ТК РК (Кодекс 414-V ОТ 23.11.2015)
Общее количество статей: 204 (Люми в проде сказала 190 — фантом).
Раздел 4. БЕЗОПАСНОСТЬ И ОХРАНА ТРУДА: - Глава 17. Государственное регулирование в области БиОТ — ст. 179–190 - Глава 18+ — продолжение Раздела 4 (точные границы уточнить)
| Статья | Реальная тема (adilet) | Что думали LLM | Статус |
|---|---|---|---|
| 156 | Стороны колдоговора, порядок ведения переговоров | «охрана труда» | ❌ все ошиблись |
| 157 | Содержание и структура колдоговора | «правила ОТ» | ❌ |
| 158 | Сроки, сфера действия колдоговора | «требования по безопасности» | ❌ |
| 159 | Порядок рассмотрения индивид. трудспора | «служба безопасности» | ❌ |
| 160 | Сроки обращения по индивид. спорам | «финансирование» | ❌ |
| 161 | Восстановление на работе работника | «общественный контроль» | ❌ |
| 162 | Понятия по КТС (Глава 16 — Коллективные трудовые споры) | «гарантии прав / СИЗ» | ❌ |
| 163 | Возникновение коллективного трудспора | «медосмотры» | ❌ |
| 164 | Органы по рассмотрению КТС | «обучение/инструктаж» | ❌ |
| 165 | Примирительная комиссия | «обеспечение СИЗ» | ❌ |
| 181 | Права и обязанности работника в БиОТ | «общие положения» | ⚠ Частично |
| 182 | Права и обязанности работодателя в БиОТ | «обязанности работодателя / АРМ» | ✅ Правильно |
| 184 | Требования безопасности рабочих мест | «расследование НС» | ❌ все ошиблись! |
3. Другие кодексы
УК РК (226-V): - Ст.152 = Нарушение трудового законодательства РК - Ст.156 = Нарушение правил охраны труда — ограничение свободы до 7 лет ✅ Люми была права
КоАП РК (235-V) — всего ~920 статей: - Ст.462 = Воспрепятствование должностным лицам инспекций, НЕ про ОТ ❌ все ошибались
Экологический Кодекс РК (400-VI): - Ст.200 = Нормативы качества атмосферного воздуха - Ст.400 = Требования при обращении с серой при разведке углеводородов ✅ Gemini прав
Земельный Кодекс РК: - Ст.10 = Базовые ставки платы за земельные участки (Gemini ошибся — думал «фонд») ❌
Новый класс багов: Cross-code confusion
Открытие Opus 4.7: Люми в проде НЕ «галлюцинирует что ст.156 НЕ существует» — она путает кодексы:
Юзер пишет «ст. 156 тк рк»
↓
LLM bias: «156 = охрана труда» (из training data)
↓
Retrieval ищет «охрана труда + ТК» → находит раздел БиОТ (ст.179-198)
↓
Реальный чанк ст.156 (колдоговор) НЕ попадает в top-K
↓
LLM «в ТК РК ст.156 нет» (потому что в выданном контексте её нет)
↓
Одновременно: в УК РК ст.156 = охрана труда → LLM сваливает в УК
Это сильнее чем простая галлюцинация. Это structural ambiguity при одинаковых номерах в разных кодексах.
Решение в lookup_tool: парсер требует явного кодекса. Если в запросе «ст.156» без кодекса — bot СПРАШИВАЕТ уточнение вместо выбора.
Что сделано по итогам
1. Расширен блэклист в llm.py (LYUMI_SYSTEM_PROMPT)
Добавлена раздел «ANTI-BIAS» с таблицей 13 статей ТК/УК/КоАП/Эк/Зем и явное правило · «в ТК РК 204 статьи, НЕ 190». Деплоено в прод.
2. Обновлены 3 golden_retrieval сета
golden_retrieval_v1.jsonl— 5 правок + 7 новых cross-code disambiguation тестов (cc01-cc07)set_gemini31pro.jsonl— 12 правок (все ст.157-165 + 184 + Зем.код + КоАП)golden_retrieval_to_verify.jsonl— остаётся без изменений (там спорные приказы, все подтверждены)
3. Новые cross-code disambiguation тесты
- cc01 «ст. 156» (без кодекса) → expected: clarification
- cc02 «ст. 156 ТК РК» → expected: коллективные переговоры
- cc03 «ст. 156 УК РК» → expected: охрана труда (наказание)
- cc04 «ст. 184» (без кодекса) → expected: clarification
- cc05 «ст. 184 ТК РК» → expected: безопасность рабочих мест
- cc06 «ст. 152» (без кодекса) → expected: clarification
- cc07 «ст. 462 КоАП» → expected: воспрепятствование инспекциям
Задачи на субботу (re-extract)
Проверить полноту ТК РК в ChromaDB
Люми в проде сказала ·1в ТК РК всего 190 статей». Реально в ТК РК — 204 статьи. Гипотезы: - archive_extract.py урезал последние статьи при экстракции (PDF обрезался?) - В базе старая редакция (до поправок 2024-2026 где добавили 14 статей) - Чанки орязаны и ст.190+ не попали в ChromaDB
Действие в субботу: после re-extract проверить SELECT max(code_articles) FROM chunks WHERE doc_id='k1500000414'. Должно быть 204.
Metadata enrichment для cross-code disambiguation
Каждый чанк должен иметь metadata code_type: "ТК"|"УК"|"КоАП"|"Эк"|"Зем" и code_articles: [156]. Без этого lookup_tool не сможет развести ТК ст.156 vs УК ст.156.
Lookup_tool расширение парсера
Добавить в query_parser.py:
CODE_TYPE_PATTERNS = [
(r'\bТК\s*РК\b|\bтрудовой\s*кодекс\b', 'ТК'),
(r'\bУК\s*РК\b|\bуголовный\s*кодекс\b', 'УК'),
(r'\bКоАП\b|\bадминистративный\s*кодекс\b', 'КоАП'),
(r'\bэкологический\s*кодекс\b', 'Эк'),
(r'\bземельный\s*кодекс\b', 'Зем'),
]
Если в запросе «ст. X» без кодекса — возвращаем «none of codes» и bot спрашивает clarification.
Главный инженерный вывод
Принцип который вышел из этого опыта:
Без ручной проверки все тесты golden_retrieval измеряют не качество retrieval, а соответствие ответов LLM-консенсусу (который сам ошибочный).
Это фундаментальная проблема всех LLM-as-judge eval-методологий. Применимо к: - Eval-сетам для fine-tune - Synthetic data generation для training - LLM-judge оценке данных про региональные факты - Любым информационным базам где LLM зависят от (ошибочного) source bias
Словами Опус 4.7: «Это золотое предложение. Это принцип.»
Связанные
- [[lyumi/lookup_tool_design]] — решение этой проблемы через metadata-driven retrieval
- [[lyumi/work_log_apr28_29]] — полный журнал работ дня
- [[lyumi/strategy_2026]] — strategic roadmap
evals/FACT_CHECK_TODO.md— рабочий файл фактчека (заполнен Камалом)evals/FACT_CHECK_RESULTS.md— результаты Opus 4.7 (в папке у Камала)
Итог
Самый важный день с точки зрения инженерного понимания Люми. Совпавшие ошибки 3 разных лаб-LLM открыли фундаментальный лимит всех современных LLM-eval подходов. Решение — metadata-driven retrieval (lookup_tool) плюс ручный fact-check критичных фактов.