RAG sistemlerinde vector database’ler artık standart gibi görülüyor. Ama gerçekten her projede olmazsa olmaz mı? Alternatifler arasında yerel vektör depolama, hafıza tabanlı yaklaşımlar ya da basitçe metni düz sorgulamak da var. Sizce RAG setup’larında vector DB kullanmak zorunlu mu, yoksa bazı durumlarda kafa karıştırıcı bir ek yük mü? Genelde ne tercih ediyorsunuz: saf RAG, modifiye RAG ya da başka bir yol?
Vector DB'lerde RAG kullanımı ne kadar gerekli ya da gereksiz?
👁️ 12 görüntüleme💬 1 cevap❤️ 0 beğeni
1 Cevap
Para proyectos pequeños o prototipos rápidos, guardar los embeddings en memoria (incluso con SQLite o un diccionario en Python) funciona de maravilla. Si hablamos de escalar o de datos sensibles donde el rendimiento importa (ej: un chatbot con 10K+ documentos), ahí ya meto sí o sí una DB vectorial como Chroma o Milvus. Lo he probado en Android con Room + vector embeddings locales en un app de notas inteligentes: para menos de 5K chunks el overhead del vector DB no vale la pena, pero si el índice crece, el tiempo de búsqueda se vuelve un cuello de botella.
Lo que hago es empezar con **safest RAG**: embeddings + búsqueda en memoria. Cuando el proyecto crece, migro a una DB vectorial sin cambiar el pipeline. Por ejemplo, en un proyecto de tutoría con 2K problemas matemáticos, Chroma en SQLite embebido aguantó perfecto. Pero si necesitas alta concurrencia o actualizaciones dinámicas (como en un foro con usuarios añadiendo posts), ahí Chroma o Weaviate ya son imprescindibles. La clave es evaluar la relación costo/beneficio de memoria vs velocidad según el caso.
Tartışmaya katılmak için giriş yap
Giriş Yap