[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 в сложных сценариях.

[Итоги канала за 2025 год]

Посмотрите какой прикольный сервис сделала @neural_prosecco.

С помощью него можно посмотреть:
- статистику канала
- небольшой анализ от LLM (прикольно)

Итого:
75 постов · ❤️ 342 реакций · 👁 7.7K просмотров · 🔄 16 репостов

(до сих пор удивляюсь репостам😄)

P.s. ниже прикладываю что LLM думала о канале во время анализа:

1. Проанализировал основные темы канала за 2025 год — в фокусе AI, DDD, разработка, продуктивность и тренировки.
2. Тон коммуникации живой, разговорный, иногда с мемным или легким самоироничным вайбом.
3. Канал разбирает сложные темы простым языком, добавляя личный опыт и лайфхаки.
4. Автор честно делится как техническими деталями, так и айтишным жизненным опытом.
5. Встречаются глубокие объяснения архитектуры, LLM, AI, плюс заметки из жизни и спорта.
6. Часто решения, примеры кода и обзоры инструментов — всё без заоблачного пафоса.
7. Образ автора — прагматик, исследователь и коллега, который делится инсайтами без пафоса.
8. Канал сочетает обучение с реальным опытом, разбирает ошибки и даёт конкретику.

P.s.s.
ссылка на сам сервис: https://tgwrapped.com/

[Новый опыт - frontend, ci/cd, k8s]

Хочу поделиться следующими новостями с работы:

1) Я завершил разработку основного функционала UI одного внутреннего пользовательского сервиса.

Предложили такой проект - я не отказался (правда интересно).
Для меня это новый опыт. До этого максимум вносил небольшие изменения в работающие сервисы.
А тут все с нуля. Для меня практически все было в новинку: TypeScript, React, Redux.
Из-за того, что сервис внутренний, то жестких требований к дизайну не было и можно было собрать страницы из компонентов корпоративной дизайн-системы (очень удобно). Дизайна как такового не было, но это не значит что можно было сделать тяп-ляп на глаз. Требовалось соблюдать требования дизайн-системы. Благодаря этому на выходе получился красивый UI, который не отличается от других корпоративных сервисов в плане внешнего вида.

Делал все с использованием LLM. Сначала Continue, потом Kilo Code.

Рабочая схема:
ии-агент + тестировщик + опытный наставник

Это связка позволяет довольно быстро:
- погрузиться в новое направление в разработке (учиться)
- получать ревью и советы по лучшим практикам от профессионала
- реализовать работающий сервис с нуля и до релиза (держим в уме что опыта в этом не было)

(при этом некоторая база как работает frontend у меня была)

2) Настроил CI/CD в кубер (впервые)

У нас в команде есть devops-ы, которые все сами настраивают. Но все ушли в отпуск до конца года.
Так как мне тоже это интересно и хотелось применить полученные ранее знания с обучения, решил сделать самостоятельно (тем более была цель выкатить сервис до НГ).

В качестве примера были соседние репозитории. Все делал по аналогии.
Сначала были некоторые проблемы со сборкой образа. Потом долго провозился с сетевыми настройками в кубере, чтобы все микросервисы могли взаимодействовать друг с другом. Очень помогли знания, которые получил пару месяцев назад на обучении.
Также, пришлось погрузиться в настройки keycloak. Была проблема что бэкенд не принимал токен из фронта.

На то, чтобы настроить работу сервиса на тесте я потратил 1 рабочий день.

В итоге получил работающий сервис и ценнейший опыт.
С таким интересом я давно не проводил время)
не шучу)

P.s. сегодня выполнил деплой на прод. Были также трудности с keycloak. Решили.
Есть небольшая проблема с одним из микросервисов бэкенда.
Вроде нашли причину и решение - нужно внести небольшие изменения в код на java.
Но это уже завтра.

[Вы знакомы с Expression Problem?]

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

"Expression Problem показывает фундаментальное ограничение как объектно-ориентированных, так и функциональных языков: ни один из них не поддерживает удобное расширение как по оси типов, так и по оси операций."
-- Philip Wadler, 12 November 1998

Обратите внимание на год.

Оказывается Expression Problem - это лакмусовая бумажка выразительности языка. Идеальный язык должен позволять:
- добавить новый тип данных, не трогая старые функции
- добавить новую операцию, не трогая старые классы

Если язык программирования имеет решение, то его называют expressive (выразительным).
В Python есть решение - структурная типизация через Protocol (добавили в 2017 году в версии 3.8).

Например, вот мой путь:
1️) ООП с наследованием (ABC) - легко добавлять новые типы, но операции сложно
2️) ФП с матчингом - легко добавлять новые функции, но типы сложно
3️) Protocols - золотая середина в Python

Если погрузиться в "PEP 544 – Protocols: Structural subtyping (static duck typing)", то можно сделать вывод что это по сути официальное решение Expression Problem в Python.

Лайфхак:
Когда проектируешь систему, нужно спросить себя: "Что вероятнее будет расширяться - типы данных или операции над ними?" Исходя из ответа, нужно выбирать один подход из перечисленных выше.

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

[Parse, Don't Validate]

Оказывается, привычка везде вставлять if (isValid(...)) - это системная ошибка.

Сегодня открыл для себя философию «Parse, Don't Validate».

Вместо того чтобы постоянно спрашивать «корректны ли данные?», нужно один раз на границе системы преобразовать их в гарантированно корректный, «богатый» тип. После этого можно просто ему доверять.

Как это работает:
1) На границе (API, форма, БД) мы парсим «сырые» данные.
2) Создаём объекты специальных типов (например, Email, NonEmptyList, PaidOrder), которые невозможно создать в некорректном состоянии.
3) Вся бизнес-логика внутри системы работает только с этими доверенными типами. Никаких if-ов.

Лайфхак:
Когда проектируешь систему, спроси себя: "Где настоящая граница моей системы?".
Именно там нужно парсить данные. Всё, что внутри - должно быть уже валидным.

Идеальная система должна:
- Преобразовывать сырые данные в "богатые" типы на границе
- Работать внутри только с гарантированно валидными данными
- Иметь 0 проверок в бизнес-логике

P.s.
Рекомендую прочитать статью-первоисточник: Parse, don’t validate