
How I split the embedding workflow in Qdrant into clear steps
I rebuilt the worker so that one capture produces multiple token chunks, each chunk is embedded individually, and storage in Qdrant remains completely isolated.

I rebuilt the worker so that one capture produces multiple token chunks, each chunk is embedded individually, and storage in Qdrant remains completely isolated.

I do not treat the choice of embedding model as an interchangeable environment variable. In Qdrant, it becomes part of every collection. Using different vector spaces locally and in production creates an expensive future migration.

After the first successful start of my RAG system, I thought it was finished. Then I saw a docker exec step in the Quick Start and could not leave it alone. How a small source of friction led to a better architecture.

When I received "Ollama is not reachable", I faced a real architectural decision: install Ollama on the host or run it as a Docker container? The answer changed my entire deployment strategy.

I could have built Ollama directly into the backend. I could have built OpenAI directly into it. Instead, I built an abstraction layer that allows both, and understood why this is not overengineering but the only strategically sound decision.

Retrieval-Augmented Generation is not theory. It is a concrete three-step architecture: embed, retrieve and generate. I show how I implemented it entirely locally with Qdrant, nomic-embed-text and llama3.2, without cloud costs.
Describe your workflow. Together, we will identify the right next step.
Discuss your workflow