Зміст
Коротко
Автор будує домашній чат-бот з RAG за побутовими питаннями — від басейну до запису до лікаря. Перед векторним пошуком питання проганяється через класифікатор на Qwen 3 0.6B (600M параметрів). Промпт без дообучення дав ~10% точності; після донавчання через Unsloth і зміни формату відповіді на двобуквенні коди — ~92%.
Що сталося
Індекс у векторній базі розмічений метаданими (категорії на кшталт pool, hvac, cooking). Запит «Коли міняли насос у басейні?» спочатку має потрапити в категорію pool, і лише потім шукати серед релевантних записів — так звужується простір пошуку і зростає якість RAG.
Для відповідей на загальні питання автор використовує Qwen 3 4B, а для класифікації — надлегку Qwen 3 0.6B локально через Ollama. Гіпотеза: чи вистачить 600M параметрів, якщо показати моделі ~850 розмічених пар «питання → категорія» і прогнати QLoRA в Unsloth.
Базова лінія — лише промпт із жорстким списком із 19 категорій. На батареї з 131 інтеграційного тесту правильних відповідей було 13 (~10%). Типові збої: модель зловживає широкими мітками на кшталт electric, вигадує категорії (apartments) або повертає фрагменти замість повного імені.
Перше дообучення підняло точність до ~79%, але залишилися обрізані відповіді (ac замість hvac) і плутанина між семантично близькими темами (вода: pool, water heater, fountain). Другий експеримент — замість імен категорій модель вчать видавати фіксовані двобуквенні коди (KK = hvac, OO = pool). Точність зросла до ~92% (120 з 131). Решта 11 помилок — переважно «водні» категорії.
Чому це важливо
Класифікація перед RAG — дешевий спосіб покращити повноту пошуку без роздування ембеддинг-індексу. Маленька модель споживає менше, ніж ганяти кожен запит через 4B+, і її можна переобучати на нових категоріях.
Стаття наочно показує, що формат виходу важливіший за «ще один абзац у промпті»: короткі неперетинні коди стабілізують генерацію у крихітних LLM краще, ніж вільний текст з 19 довгими мітками. Це переноситься на маршрутизацію запитів, первинне сортування звернень у підтримці, фільтрацію логів.
Автор також описує цикл зворотного зв'язку: користувацькі виправлення можна додавати в датасет для наступного циклу дообучення.
На практиці
- Зафіксуйте базову лінію — прогоніть «сиру» модель на відкладеному тесті до будь-якого донавчання.
- Датасет — ~850 прикладів з розбиттям 70/15/15 (навчання/валідація/тест); стежте за балансом рідких категорій.
- Unsloth + QLoRA — стартові гіперпараметри з документації часто достатні.
- Формат відповіді — спробуйте незмінні коди фіксованої довжини замість імен класів.
- Постобробка — маппінг код → категорія на стороні застосунку.
- Альтернатива — окрема стаття з логістичною регресією на ембеддингах.
| Етап | Точність (131 тест) |
|---|---|
| Промпт без дообучення | ~10% |
| Fine-tuning, імена категорій | ~79% |
| Fine-tuning, двобуквенні коди | ~92% |
Підсумок
Домашній експеримент — хороший кейс «маленька LLM як вузький інструмент»: не замінює велику модель для відповідей, але надійно ріже потік запитів за метаданими. Якщо будуєте локальний RAG, закладіть окремий легкий класифікатор і експериментуйте з форматом міток.