Комментарии 4
Все то же самое пишется за пару часов на чистом Python без всяких субагентов и псевдоинновационного вайб-воркинга, который здесь явно послужил лишь оправданием для накрутки охватов)
Как по мне - сейчас самая интересная тема, как раз тема оценки эффективности инструментов накрученных поверх llm. Хорошая статья. А ваши задачи без rag не решаются? Например положить все данные просто файлом рядом с моделью если это возможно. Интересно было бы ещё протестировать тут сценарий rag против cli в контексте затрат токенов. У меня в части задач выходило, что модель куда эффективнее сама искал необходимую часть документа базовыми unix инструментами, чем получая избыточные данные от rag, которые ей принудительно приходилось читать полностью.
Спасибо. Отличный вопрос!
А ваши задачи без rag не решаются? Например положить все данные просто файлом рядом с моделью если это возможно.
В API Anthropic есть система кеширования, кэш живёт 5 минут. Если мы работаем с одним и тем же документом, то его можно закешировать и сэкономить на токенах. Качество ответов будет выше, чем у простейшей RAG системы. Картинка с дашбордом как раз этот эффект показывает. Дело в том, что бенчмарк синтетический. Я его сделал на gemma4:31b. Она получала тему для вопроса, но видела весь документ целиком, поэтому RAG уступает по качеству там, где в метрике используется "правильный" ответ.
модель куда эффективнее сама искал необходимую часть документа базовыми unix инструментами, чем получая избыточные данные от rag
Если RAG - просто векторный поиск, так скорее всего и будет. Сравнительно новые архитектуры предполагают использование в RAG агентов и LLM-судьи. В зависимости от его решения может адаптивно меняться количество чанков в выдаче, переформулироваться и дополняться вопрос, или вообще отключаться выдача, если LLM-судья решил, что для этого вопроса RAG не нужен.

Как мы с Claude Code учились оценивать качество RAG системы