Комментарии 9
Если не секрет, какой на этом этапе получился расход токенов на всю систему?
Здесь основная проблема, правильно сформировать dataset для rag. Здесь нужно связать описание всех классов и методов в них, указать исполняемый код в каждом классе, сделать обычное и семантическое описание работающего кода в них. Построить графы зависимости между классами и методами. Затем взять весь остальной код , в котором это все используется и связать графами с предыдущими структурами, сделать семантический анализ работающего кода. Если есть документация, тоже привязать ко всему этому. Тогда по итогу получится полноценный rag по всем классам, методам и связанному с этим коду. Такие структуры по силам сделать современным ии типа claude.
Примерно к этому мы и идем - граф зависимостей код у нас уже есть, документация к классам тоже, а где нет, то генерируем. Плюс на днях добавили для LLM еще пару инструментов: один может по графу поискать зависимости интересующего класса, а второй имеет доступ к описанию модели данных (тип геообъекта плюс его возможные атрибуты и связи с другими типами). Ответы после этого стали еще лучше.
Только код в мастере стабильно отражает то, что реально работает на продакшне.
так как весь контекст держать в головах уже проблематично
Мне кажется, вы начинаете сползать в сторону классического "big ball of mud". Вам не нейронки нужны, а уменьшение связности и актуализация документации.
К сожалению, рост проекта и команды произошел слишком быстро и где-то мы за этим не успели. Как раз сейчас находимся в стадии разделения на две подкоманды, чтобы каждая занималась независимыми частями. Но ассистент уже помогает новичкам при ответах на их вопросы и аналитикам в том числе для актуализации документации. Одно другому не мешает.
Я правильно понимаю, что на постановку задачи ушло X времени, а затем разбор "что имел в виду автор" плюс Y времени?
Мне кажется, что с помощью LLM лучше один раз расписать задачу и больше не тратить времени.
Как это делаю я, когда ставлю задачу, что пишу:
текущая версия продукта, среда на которой обнаружен баг / потребность
Кто обратился (если есть инициатор)
Предыстория. Например, в задаче 1 мы реализовали CI/CD для dev окружения
Потребность / баг. Например: есть потребность гибко указывать какую среду разворачиваем / обнаружено, что при указании несуществующего файла окружения сборка валится не сообщал в чем конкретно заключалась проблема
Шаги что сделать. Например: что сделать - добавить параметр окружения / выводить сообщение о несуществующем файле
Всё! Весь контекст в задаче, нужно - добавить скриншот, видеозапись, указать какой класс из какого файла требует доработки. И люди все есть в задаче - иди и уточняй у них в случае чего. А никто не помнит, значит нет потребности в задачи. Нет?
То есть я к чему. В самом начале, при постановке - потратьте дополнительно 15 минут на описание. Не надо будет обращаться к этой статье и тыщу взаимосвязей строить, токены тратить
Это идеальная история, когда весь контекст в одной задаче. Но в реальности, по крайней мере в нашей, это не так. И даже в идеально расписанных тикетах надо как-то ориентироваться. И в коде написанном тоже. Не может у всех в команде быть в головах одинаковое знание проекта. Наличие бота не отменяет качественно поставленных задач, а помогает сориентироваться там, где знаний и понимания связей не хватает.
Если сейчас помощник знает как система работает на проде, то в теории можно дать задачу агенту, чтобы он шёл по Confluence, показывал где устарело, предлагал правки и что стоит дополнить. Эдакий selfhealing инструмент. А потом добавить как шаг после мёрджа в мастер, чтобы он показывал, что теперь требование противоречит реализации.
AI-ассистент для 15 000 файлов: быстрее, чем спросить у коллег