[Cosine Similarity (косинусная близость)]

Продолжаю изучать векторы и эмбеддинг-модели.

Как рекомендовали сгенерировал 50 пар и указал флаг is_semantic_relevant.

Прогнал 2 модели:
- BAAI/bge-small-en-v1.5
- sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2

Наиболее интересным показался график распределения пар по косинусной близости (см. картинку). Он наглядно показывает распределение полученных векторов между релевантными и нерелевантными парами.

———
Косинусная близость (схожесть) - это мощная метрика для сравнения семантической близости текстов, изображений или других данных, представленных в виде векторов.

Если два текста похожи по смыслу, их векторы будут близки, и косинусная близость будет стремиться к 1.
Если тексты не похожи - будет стремиться к 0.

———
У модели sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2 наблюдается значительное разделение между релевантными и нерелевантными парами.

У модели BAAI/bge-small-en-v1.5 разделение менее выражено. А также есть пересечение. Как понимаю это очень нехороший показатель.

Вывод: sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2 лучше разделяет релевантные и нерелевантные пары.

В контексте построения RAG это означает, что система будет эффективно извлекать релевантные документы, так как их векторы четко отделены от нерелевантных. Вероятность извлечения нерелевантных документов (ложноположительных срабатываний) будет низкой.

Это в свою очередь улучшит качество ответов ИИ-приложения, так как LLM получит релевантный контекст.

[Only Vibe Coding. Первый опыт]

Решил протестировать сразу несколько вещей:
- разработку с Kilo Code целого проекта с нуля;
- новую модель от Mistral, которую зарелизили 2-го декабря;

Решил сделать браузерную игру, с помощью которой можно было бы наглядно увидеть принцип работы персептрона.

Что было сделано:
1) В несколько итераций создан довольно подробный промпт для агента с помощью DeepSeek
2) Создана новая директория для проекта
3) Запущен kilo code c mistral large 3 под капотом

В итоге агент выполнил реализацию за ~25 минут.

Внимание! Игра запустилась с первого раза.

Последний раз я пробовал провернуть что-то подобное год назад. Тогда я не смог запустить проект ни с первого, ни со второго раза), хотя проект был значительно скромнее.
После этого я для себя принял решение, что ИИ подходит только для точечной, жестко контролируемой со стороны человека разработки.

После текущего опыта у меня мнение немного изменилось.

Продолжаем эксперименты дальше.

P.s.
На какой итерации внесения изменений агент сломает проект?)

[Не сломает. kilo code + mistral large 3]

В посте выше я задал вопрос:
"На какой итерации внесения изменений агент сломает проект?)"

Отвечаю:
Не сломает.

Я почти 2 часа исправлял ошибки в расчетах игры. Были ошибки в алгоритме классификации точек, а также в отрисовке прямой (что было неочевидно).

На отладку и исправление ошибок я потратил в 2 раза больше токенов, чем на первоначальную реализацию. Но это не важно. Важно что ничего не сломалось и этим можно управлять.

Главный вывод:
С этим можно работать. Вдолгую. Проект не сыпется.
Я под сильным впечатлением.

P.s.
+ попросил подвести итоги работы над проектом за сегодня.

Агент указал точное время начала/завершения работы и дал подробное описание что было сделано.

Последний раз я был так удивлен, когда впервые открыл chatGPT.

1) Когда-нибудь электронные вычислительные машины (ЭВМ) будут сами составлять для себя программы или же мы будем писать их на естественном языке.
-- Денни Ван Тассел, 1978 год

2) Цель программирования - не создание
программы, а получение результатов
вычисления.
Кодирование, увы, само по себе ничего
не стоит - существенны результаты!
-- Денни Ван Тассел, 1978 год

[KiloCode + Mistral Large 3. Подвожу итоги]

Работать можно.

Сегодня удалось выделить время и добить до некоторого логического результата "Перцептрон-Классификатор".

Исправил все ошибки, написал README, попросил вывести статистику по выполненным работам.

Получил довольно подробную статистику:
- кол-во задач
- стоимость затрат
- время работ (часов, дней)
- структуру проекта
- кол-во строк кода
- даже перфоманс сборки
- и еще кучу информации в различном разрезе

Например, какую долю заняло исправление ошибок среди всех задач (по времени, в деньгах).
Даже степень критичности ошибок подсветил.

Я точечно проверил некоторые метрики. В целом информация похожа на правду.
Но по некоторым есть вопросы.

Попросил указать источники информации - любезно получил ответ.
Было интересно и познавательно. Есть над чем подумать.

Идем дальше.

P.s. на работе уже окончательно перешел на KiloCode.
Continue, спасибо! Было интересно!

[Kilo Code изучает Kilo Code]

Почему бы и нет?
Решил изучить плагин.

Что сделал:
- пообщался с chatGPT, DeepSeek указав ссылку на оф. сайт и предоставив им возможность поиска источников в интернете - в итоге получил общее представление;
- создал подробный промпт для изучения проекта с помощью DeepSeek;
- склонировал репозиторий и запустил Kilo Code с промптом;

Агент рассказал про:
- архитектуру
- основные компоненты
- управление задачами, подзадачами, контекстом, инструментами, чекпойнтами, историей
- механизм принятия решений,
- обработку ошибок
- параллельный режим
- и многое другое

Также, получил подробные комментарии что и зачем выполняется с ссылками на код (я проверил - все ссылки точные)

P.s.
Дополнительно собрал различную статистику по кодовой базе и получил краткие интересные комментарии к ней.

Раньше на такое погружение потребовалось бы несопоставимо больше времени. Я под сильным впечатлением. Получил неплохое понимание объемного проекта буквально за пару часов.

[Kilo Code. Изучаем работу агента с помощью Export Task]

Совершенно случайно нашел так скажем протокол сессии агента.

Это не просто диалог, который виден в окне плагина. Там гораздо больше интересной информации, изучив которую, можно больше понять процесс работы агента.

[Как устроен протокол задачи в Kilo Code?]

Изучил протокол и вот что выяснил.

При работе с Kilo Code каждая задача сохраняется в виде детализированного протокола kilo_code_task_*.md. Этот файл содержит полную историю взаимодействия с агентом, включая:

- Исходный запрос пользователя (тег <task>).
- Ход рассуждений ассистента (секция <thinking>).
- План действий с чек-листами (инструмент update_todo_list).
- Результаты выполнения команд (например, вывод read_file, search_files).
- Метаданные окружения <environment_details> (открытые файлы, текущий режим, стоимость сессии).

Что интересного?

Больше данных, чем в интерфейсе плагина:
В экспортированном файле сохраняются даже те детали, которые не всегда видны в окне VS Code (например, полный контекст окружения, промежуточные результаты).

Структурированный формат:
Протокол оформлен в Markdown с четкими разделителями (---), что упрощает анализ и повторное использование.

История принятия решений:
Видно, как агент пришел к финальному результату - от анализа задачи до применения инструментов.

Напоминания:
Явно указаны напоминания для LLM относительно плана работы. Именно поэтому агент не теряет фокус во время выполнения и продолжает придерживаться плана (хотя иногда теряет).

REMINDERS

Below is your current list of reminders for this task. Keep them updated as you progress.

Зачем это нужно?

1) Можно восстановить логику решений при отладке или ревью.

2) Протокол можно передать другому агенту или использовать как основу для новой задачи.

3) Удобно изучать паттерны работы LLM в сложных сценариях.