Комментарии 6
А что в итоге оказалось слабым местом? качество чанкинга, поиск по embeddings или сбор контекста перед запросом к llm? По опыту именно на этом этапе RAG чаще всего начинает ехать.
Да, на этом этапе RAG чаще всего и начинает “ехать”. В моём случае по скорости слабым местом была generation: retrieval занимал около 2 секунд, а локальная llm могла отвечать десятки секунд.
По качеству слабое место оказалось на границе retrieval/filtering: semantic search что то находит почти всегда, но похожий chunk не всегда даёт достаточный контекст для ответа. Поэтому добавил strong/borderline пороги, negative tests и exact-term guard для технических токенов, то есть backend должен не просто собрать prompt, а сначала решить есть ли вообще смысл вызывать llm.
Немного не понял, вы локально на ноуте запустили gpt-oss:20b?
у вас в конфиге олламы "num_gpu": 20, это не влезет ну никак на Радеон от ноута , оллама принудительно сбросит все слои в ram и генерация будет 1 токен/с. Для квантовой модели которую вы используете нужно минимум 11 Гб vram)
Уточню, num_gpu в ollama это не количество gpu, а число слоёв модели которые пробуются для offload на gpu. В статье это действительно можно было подписать явнее.
При этом мой запуск был не на дискретной видеокарте с отдельной vram, а на Radeon 780M в составе r7 260 то есть на igpu со shared memory. Поэтому сценарий не совсем такой же как “модель целиком должна влезть в dedicated vram” часть нагрузки уходила в cpu/ram, часть в gpu/shared memory и это как раз видно по приведённой загрузке системы.
Скорость в среднем 13 т/с получил не как теоретическую оценку, а из локального запуска на этой конфигурации. Согласен что для чистого бенчмарка лучше отдельно показать eval_count / eval_duration из ответа ollama и вывод ollama ps, чтобы было видно фактическое распределение. Добавлю это уточнение чтобы не было впечатления что num_gpu: 20 означает “20 видеокарт” или гарантированный full gpu offload.

Локальный RAG без магии: sources, timings, request_id и отказ от генерации