docs: rename docs website images (#11996)

Author: anakin87

docs-website/docs/concepts/pipelines/debugging-pipelines.mdx

@@ -112,7 +112,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Tracing
 

docs-website/docs/concepts/pipelines/visualizing-pipelines.mdx

@@ -77,7 +77,7 @@ my_pipeline.draw("my_pipeline.png", server_url="http://localhost:3000")
 ## Example
 
 This is an example of what a pipeline graph may look like:
-<ClickableImage src="/img/46a8989-Untitled.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
+<ClickableImage src="/img/rag-pipeline.png" alt="RAG pipeline flowchart showing the data flow from query through retriever, prompt builder, language model, and answer builder components" size="large" />
 
 <br />
 

docs-website/docs/development/deployment/kubernetes.mdx

@@ -56,7 +56,7 @@ spec:
 ```
 
 After applying the above to an existing Kubernetes cluster, a `hayhooks` Pod will show up as a Service called `haystack-service`.
-<ClickableImage src="/img/6eb9fb0c7b00367bfbe8182ffc7c3746f3f3d03b720e963df045e28160362d7f-Screenshot_2025-04-15_at_16.15.28.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
+<ClickableImage src="/img/hayhooks-k8s-1.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
 
 Note that the `Service` defined above is of type `ClusterIP`. That means it's exposed only _inside_ the Kubernetes cluster. To expose the Hayhooks API to the _outside_ world as well, you need a `NodePort` or `Ingress` resource. As an alternative, it's also possible to use [Port Forwarding](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) to access the `Service` locally.
 
@@ -182,7 +182,7 @@ data:
 ```
 
 After applying this, check your Hayhooks Pod logs, and you'll see that the `chat_with_website` pipelines have already been deployed.
-<ClickableImage src="/img/2dbf42dd2db1cb355ee7222d7f8e96c45b611200d83ca289be3456264a854c38-Screenshot_2025-04-16_at_09.19.14.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
+<ClickableImage src="/img/hayhooks-k8s-2.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
 
 ## Roll Out Multiple Pods
 
@@ -264,6 +264,6 @@ spec:
 
 Implementing the above configuration will create three pods. Each pod will run a different instance of Hayhooks, all serving the same example pipeline provided by the mounted volume in the previous example.
 
-<ClickableImage src="/img/f3f0ac4b22a37039f0837c22b0cb8b640937bbb0db4acfcbdf7bd016b545d84a-Screenshot_2025-04-16_at_09.32.07.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
+<ClickableImage src="/img/hayhooks-k8s-3.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
 
 Note that the `NodePort` you created before will now act as a load balancer and will distribute incoming requests to the three Hayhooks Pods.

docs-website/docs/development/enabling-gpu-acceleration.mdx

@@ -29,7 +29,7 @@ You can find more information on the [Device management](../concepts/device-mana
 ### Enabling the GPU in Colab
 
 1. In your Colab environment, select **Runtime>Change Runtime type**.
-<ClickableImage src="/img/85079c7-68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f646565707365742d61692f686179737461636b2f6d61696e2f646f63732f696d672f636f6c61625f6770755f72756e74696d652e6a7067.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
+<ClickableImage src="/img/colab-gpu-runtime.jpeg" alt="Google Colab Runtime menu with Change runtime type option highlighted for selecting GPU acceleration" size="large" />
 
 2. Choose **Hardware accelerator>GPU**.
 3. To check if the GPU is enabled, run:

docs-website/docs/development/logging.mdx

@@ -68,7 +68,7 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
 
 ## Structured Logging
 
@@ -96,7 +96,7 @@ configure_logging(propagate=False)
 ### Console Rendering
 
 To make development a more pleasurable experience, Haystack uses [structlog’s `ConsoleRender`](https://www.structlog.org/en/stable/console-output.html) by default to render structured logs as a nicely aligned and colorful output:
-<ClickableImage src="/img/e49a1f2-Screenshot_2024-02-27_at_16.13.51.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
+<ClickableImage src="/img/basic-logging-output.png" alt="Python code snippet demonstrating basic logging setup with getLogger and a warning level log message output" />
 
 :::tip[Rich Formatting]
 
@@ -115,7 +115,7 @@ We recommend JSON logging when deploying Haystack to production. Haystack will a
 
   haystack.logging.configure_logging(use_json=True)
   ```
-<ClickableImage src="/img/bff93d4-Screenshot_2024-02-27_at_16.15.35.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
+<ClickableImage src="/img/structured-json-logging.png" alt="Python code snippet showing structured JSON logging configuration with example JSON formatted log output including event, level, and timestamp fields" />
 
 ### Disabling Structured Logging
 

docs-website/docs/development/tracing/logging-tracer.mdx

@@ -58,4 +58,4 @@ tracing.enable_tracing(
 ```
 
 Here’s what the resulting log would look like when a pipeline is run:
-<ClickableImage src="/img/55c3d5c84282d726c95fb3350ec36be49a354edca8a6164f5dffdab7121cec58-image_2.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />
+<ClickableImage src="/img/logging-tracer-console-output.png" alt="Console output showing Haystack pipeline execution with DEBUG level tracing logs including component names, types, and input/output specifications" />

docs-website/docs/development/tracing/opentelemetry.mdx

@@ -93,7 +93,7 @@ See the [`OpenTelemetryConnector` documentation page](../../pipeline-components/
 ## Visualizing Traces During Development
 
 Use [Jaeger](https://www.jaegertracing.io/docs/1.6/getting-started/) as a lightweight tracing backend for local pipeline development. This allows you to experiment with tracing without the need for a complex tracing backend.
-<ClickableImage src="/img/dd906d7-Screenshot_2024-02-22_at_16.51.01.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
+<ClickableImage src="/img/jaeger-trace-timeline.png" alt="Jaeger UI trace timeline displaying haystack pipeline execution with component spans showing duration and nesting of operations" />
 
 1. Run the Jaeger container. This creates a tracing backend as well as a UI to visualize the traces:
 

docs-website/docs/optimization/advanced-rag-techniques/hypothetical-document-embeddings-hyde.mdx

@@ -22,7 +22,7 @@ The HyDE method is highly useful when:
 ## How Does It Work?
 
 Many embedding retrievers generalize poorly to new, unseen domains. This approach tries to tackle this problem. Given a query, the Hypothetical Document Embeddings (HyDE) first zero-shot prompts an instruction-following language model to generate a “fake” hypothetical document that captures relevant textual patterns from the initial query - in practice, this is done five times. Then, it encodes each hypothetical document into an embedding vector and averages them. The resulting, single embedding can be used to identify a neighbourhood in the document embedding space from which similar actual documents are retrieved based on vector similarity. As with any other retriever, these retrieved documents can then be used downstream in a pipeline (for example, in a Generator for RAG). Refer to the paper “[Precise Zero-Shot Dense Retrieval without Relevance Labels](https://aclanthology.org/2023.acl-long.99/)” for more details.
-<ClickableImage src="/img/2d00628-Untitled_2.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
+<ClickableImage src="/img/hyde-architecture.png" alt="HyDE model architecture diagram showing how GPT generates hypothetical documents from queries in multiple languages, which are then matched with real documents via a Contriever model" size="large" />
 
 ## How To Build It in Haystack?