RunLLM

It seems likely that Phoenix's data retention policy deletes old traces, but PostgreSQL does not immediately reclaim disk space from deleted rows—especially for large objects stored in TOAST tables—unless a VACUUM FULL is run. Standard VACUUM only marks space as reusable, while VACUUM FULL physically reclaims it. This behavior is expected in PostgreSQL and is not unique to Phoenix. The Phoenix documentation and community confirm that storage usage may not decrease after deleting traces due to how PostgreSQL handles deleted row space and TOAST data; autovacuum or manual VACUUM FULL is needed to reclaim disk space (Phoenix Data Retention FAQ).There is no evidence in the data sources of Phoenix storing data in a way that prevents PostgreSQL from reclaiming space, nor of Phoenix-specific maintenance steps beyond standard PostgreSQL practices. However, index bloat or long-running transactions can also prevent space reclamation, and these are general PostgreSQL issues. Running VACUUM FULL on the spans table should reclaim space, but it will lock the table and may impact Phoenix availability during the operation. Always test on a staging environment first and ensure no long-running transactions are open (Phoenix Data Retention FAQ). Would you like more detail on safe procedures for running VACUUM FULL or on diagnosing index bloat?Sources: - Phoenix Data Retention FAQ

If you've lost the ability to reply in a Slack thread, it's likely due to channel or thread restrictions, not something you can control. For technical blockers, posting details on GitHub (as you've done) is the correct workflow—maintainers monitor issues there and will respond as able. No further action is needed unless maintainers request more info or clarification on GitHub.If you want to ensure visibility, you can mention relevant team members in the GitHub issue or check for updates periodically. For urgent matters, joining the project's Slack (if available) or using other official support channels is also appropriate, but GitHub remains the main place for technical issue tracking and resolution according to Phoenix contribution guidelines.Would you like more detail on how to follow up or escalate if you don't get a response?Sources: - Phoenix contribution guidelines

Yes, you can configure Phoenix to collect only the spans relevant to model interactions by ensuring the Phoenix tracer provider is not set as the global tracer provider. By default, the Phoenix register() function sets up its own tracer provider, and you should avoid calling trace.set_tracer_provider() with the Phoenix provider if you want to keep it independent. Only set the global tracer provider for your application-level tracing (e.g., Jaeger), and use the Phoenix tracer provider explicitly for StrandsAgents/model spans. This way, Phoenix will only receive the spans you instrument with its tracer, not all application spans. See Phoenix Python SDK docs and manual tracing example.If you want to further filter which spans are sent to Phoenix, you can implement a custom span processor to drop or mask unwanted spans before export, or use the Filter Spans to Export approach. This allows you to keep your application and Phoenix traces separate and focused.Would you like a code example for this setup?Sources: - Manual tracing example - Filter Spans to Export - Phoenix Python SDK docs

For a reliable, up-to-date self-hosting guide, use the official Phoenix Self-Hosting documentation, which covers Docker, Kubernetes, and other deployment options. The Quickstart guide also provides step-by-step instructions for running Phoenix locally, including installation, starting the server, and accessing the UI.If you want a minimal test, the docs recommend: 1. pip install arize-phoenix 2. phoenix serve 3. Visit [http://localhost::6006](http:://localhost:6006) in your browser. This should launch the Phoenix dashboard for immediate use. For Docker, run docker run -p 6006:6006 -p 4317:4317 -i -t arizephoenix/phoenix:latest and access the same URL. If you need to persist data, see the configuration section.Would you like more detail on a specific deployment method or troubleshooting tips?Sources: - Phoenix Self-Hosting documentation - Phoenix Quickstart guide - configuration section

You are correct—currently, when you add traces to a dataset, Phoenix does not automatically map reference outputs (e.g., retrieved documents) as input variables for prompt templates in the Prompt Playground. This limitation means you cannot immediately use those reference outputs in your prompts without additional data transformation or remapping, which has been noted as a workflow friction point in user discussions (see here).This is a known limitation, and there are open enhancement requests to improve trace-to-dataset workflows and variable mapping for seamless prompt experimentation.Would you like suggestions for workarounds or updates on planned improvements?Sources: - see here

This is a known issue: even if your dataset includes a reference column, the Prompt Playground may only expose input as a usable variable if the dataset was created or loaded in a way that doesn't map the reference output as an input variable. This limitation and related confusion have been discussed in GitHub issues and release notes, with improvements to error handling and variable mapping released in recent Phoenix versions (see here, issue discussion).To resolve this, ensure your dataset's reference column is mapped as an input variable when uploading or creating the dataset, not just as an output. If the Playground still doesn't recognize it, this is a UI limitation or bug—recent updates have improved error messaging, but the underlying mapping issue may persist in some cases.Would you like guidance on how to structure your dataset or a workaround?Sources: - see here - issue discussion

Your use case makes sense and aligns with Phoenix's intended RAG evaluation workflows: referencing retrieved documents (reference outputs) in prompts to let the LLM judge their relevance. However, in the Prompt Playground, only columns explicitly present in your dataset can be referenced as template variables (e.g., {{reference}}). If your dataset of retriever traces does not include a reference (or similar) column, Phoenix cannot inject those values into the prompt—this is why you see the missing variable error.To achieve your goal, ensure your dataset includes a column (e.g., reference or retrieved_docs) containing the retrieved documents for each trace. Then, reference that column in your prompt template (e.g., {{reference}}). This approach is standard for RAG and retrieval evaluation in Phoenix, as described in Prompt Concepts and Testing Prompts at Scale.Would you like detailed steps or a code example for preparing your dataset?Sources: - Prompt Concepts - Testing Prompts at Scale

The error means your dataset does not have a column named reference, but your prompt template uses {{reference}}. Only the input column is available, so Phoenix cannot fill the {{reference}} variable in your prompt. To fix this, either add a reference column to your dataset or remove {{reference}} from your prompt template. For more, see Phoenix Playground error handling and Prompt Concepts.Would you like step-by-step instructions to resolve this?Sources: - Phoenix Playground error handling - Prompt Concepts

Yes, you can reference the reference output in the Prompt Playground by using a variable in your prompt template that matches the column name for the reference output in your dataset (commonly {{reference}}). When you run a prompt over a dataset, Phoenix fills in these template variables—including the reference output—for each example at runtime, allowing you to use the reference text directly in your prompt template for tasks like RAG or Q&A evaluation. To do this, ensure your dataset includes a column for the reference output (e.g., reference), and use {{reference}} in your prompt template. When the prompt is executed, Phoenix will substitute the value from the dataset for each row. For example: LBKS[Question]: {{input}} [Reference text]: {{reference}}LBKSAccording to Phoenix documentation and Prompt Concepts, this is the standard way to dynamically inject reference outputs into your prompts.Would you like more detail or a code example?Sources: - Phoenix documentation - Prompt Concepts

There are plans and ongoing work to support document-level annotation in the Phoenix UI, but as of now, this feature is not fully available. Recent updates and GitHub discussions confirm that UI enhancements for annotations are being actively developed, with span-level annotation UI already released and document annotation support mentioned as a requested and tracked enhancement (GitHub Issue #6927, Release Notes, PR #3914).Would you like more detail on the current status or how to follow progress on this feature?Sources: - GitHub Issue #6927 - Release Notes - PR #3914