Комментарии 6
Статья очень полезная, так как передает реальный опыт, и совершенно бесполезная, потому, что никто этот опыт применять не будет. Во всяком случае - пока. Слишком велико очарование ИИ. На трех уже проектах экспертствовал, и во всех одно и то же - это же ИИ, это же круто, зачем нам архитектура и инженерия, он сам во всем разберется, главное - хороший промпт написать. И не переубедишь, пока такой очарованный пару раз лбом не приложится.
"Реальных болей" вы бы хоть не палились так с llm-ным текстом.
Почему все нейронки так пишут - не знаю, но достало уже такое читать.
Бездушная статья от машины о машине
Эхх, кожаные, вы уже в плену или просто ленитесь?
Где тут проблемы разработки, не понял.
На первый взгляд столкнулись с очевидными проблемами, ллм глюки известная вещь. Добавили раг, семантический поиск все понятно. Но тут нужно следить за чанками, методы режутся посередине итп.
Что в голову приходит сразу сначала извлечь структуру детерминировано, начать с ast парсера, добавить раг, сделать jinja шаблон и только потом ллм как интерпретатор.
Проблемы структурного подхода тоже понятные: нужна переиндексация после изменений, хранилище, оркестратор который определяет что искать. В вашем случае вы использовали ллм которую позже заменили своим кодом. Можно дальше пойти и сделать эбмединг классификатор вместо ллм.
5 ошибок при разработке продукта с LLM под капотом – разбор реальных болей живого проекта