Итог
Читаю результаты прогона…
| Метрика | Разница | ||
|---|---|---|---|
| Recall@5 | |||
| MRR@10 | |||
| Фраза-ответ в первом чанке |
- Вопросы написаны людьми этого проекта и отражают их привычки, а не запросы всех будущих клиентов.
- Разница в один-два вопроса из набора, по которому считается метрика (все вопросы, а для фразы-ответа — только вопросы с фразой), — шум, а не превосходство.
- Мерено на локальной копии индекса, а не на проде: модель та же, но Ollama другой версии и на другой платформе — места на пограничных вопросах могут отличаться.
Как это работает
Поиск возвращает не один фрагмент, а несколько — по убыванию близости к вопросу: инструмент project.search отдаёт пять верхних фрагментов по умолчанию и до десяти, если клиент попросит больше. Что с ними делает модель — здесь это Claude в Claude Code, — устройство инструмента не предрешает: она может прочитать выданное и открыть файлы целиком. Ответ пишет модель, поиск только подбирает ей материал; как модель распорядилась выдачей, прогон не мерил.
Поэтому главный вопрос меры — попали ли верные документы вопроса в первую пятёрку фрагментов: это и считает Recall@5. Место, которое страница показывает в строке вопроса, — место первого из верных документов; первое место лучший случай, но не обязательный: если верный документ оказался третьим, модель его всё равно прочитает. MRR@10 добавляет к этому, насколько высоко он стоял.
У стратегий две оси. Первая — как резать документы на фрагменты: по размеру или по структуре. Её и мерил этот прогон. Вторая — как пользоваться найденным: взять k лучших фрагментов или искать агентно, несколькими запросами с чтением файлов. Вторую ось прогон не мерил: он сравнивает нарезку при одинаковом способе поиска.
Задание и корпус
Индексация документов. Возьмите набор документов: README / статьи / код / pdf → текст; минимум 20–30 страниц текста суммарно (или эквивалент в коде).
Реализуйте пайплайн индексации: разбиение на чанки (chunking); генерация эмбеддингов; сохранение индекса (FAISS / SQLite / JSON).
Усиление: добавьте метаданные к каждому чанку (source, title/file, section, chunk_id); сделайте минимум 2 стратегии chunking и сравните их — по фиксированному размеру и по структуре (заголовки/разделы/файлы).
Результат: локальный индекс документов с эмбеддингами + метаданные + сравнение 2 стратегий chunking.
В индекс взят сам проект: документация agent_docs, AGENTS.md, README.md единиц и код живых единиц — читаю результаты прогона…
Не взяты сданные дни, чужие скиллы и зависимости: сданные дни не поддерживаются, искать в них нечего.
Индекс — FAISS IndexFlatIP: точный полный перебор по косинусу. На три с небольшим тысячи фрагментов приближённый поиск не нужен — перебор занимает миллисекунды.
Две стратегии
Читаю результаты прогона…
Сто вопросов по одному
Число у каждой стратегии в строке — место первого верного документа в выдаче поиска по этому вопросу: 1 — он нашёлся первым, от 2 до 10 — ниже (меньше — лучше), «нет» — в первую десятку он не попал. MRR@10 в «Итоге» считается прямо по этим местам: среднее от 1/место, и «нет» входит в это среднее нулём. Recall@5 считается строже: у каждого вопроса берётся доля его верных документов, попавших в первую пятёрку найденных фрагментов, и эти доли усредняются по всем вопросам. Когда верный документ один, доля равна 1 или 0; когда их два, найденный один из двух даёт 0,5 — поэтому Recall@5 меньше, чем просто доля вопросов с местом не дальше пятого.
Показать
Читаю результаты прогона…