Building a RAG flow with Vectorize and Workers AI

Retrieval-augmented generation is composed rather than configured here: an embedding step, a Vectorize query, and a generation step wired together on the canvas. Nothing about the pattern is specific to SwiftTune — what changes is that each step is a typed block the composer can check before it runs, rather than three functions calling each other on trust.

The graph below is the minimum version: a trigger, an embedding call, a Vectorize query, and a Workers AI generation call reading both the question and the retrieved passages.

{
  "nodes": [
    { "id": "trigger", "type": "http_trigger" },
    {
      "id": "embed",
      "type": "workers_ai",
      "config": { "model": "@cf/baai/bge-base-en-v1.5" }
    },
    { "id": "retrieve", "type": "vectorize", "config": { "operation": "query", "topK": 5 } },
    {
      "id": "generate",
      "type": "workers_ai",
      "config": { "model": "@cf/meta/llama-3.1-8b-instruct" }
    }
  ],
  "edges": [
    { "source": "trigger", "sourcePort": "out", "target": "embed", "targetPort": "in" },
    { "source": "embed", "sourcePort": "out", "target": "retrieve", "targetPort": "in" },
    { "source": "retrieve", "sourcePort": "out", "target": "generate", "targetPort": "in" }
  ]
}

Quality is usually lost between retrieve and generate: a retriever that returns the wrong passages produces a confident answer built on the wrong evidence, and a confident wrong answer reads exactly like a correct one. Because retrieval is its own block with its own output port, it can be measured on its own — recall and precision per query cluster — instead of only being visible in the final answer.

The Retrieval Monitor add-on watches which documents a deployed RAG flow’s queries actually return over time, so drift shows up as a line that moved rather than a support ticket someone has to reproduce.

The quickstart builds a two-block flow with curl; swap the graph in its third step for the one above and the same deploy call publishes this one.