You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+21-4Lines changed: 21 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -93,6 +93,8 @@ Then, either way:
93
93
- Credentials loaded from environment variables only — no hardcoded keys
94
94
- A `run.sh` that exports `OPIK_PROJECT_NAME` and can run the example end-to-end
95
95
96
+
> **Notebook examples are the exception.** A `.ipynb` guide ships `notebook.ipynb` + `pyproject.toml` + `README.md` and is executed live by [`test-notebooks.yml`](.github/workflows/test-notebooks.yml) — no `run.sh` and no dry-run. See [Notebook examples](#notebook-examples).
97
+
96
98
### README structure
97
99
98
100
Use the template's README as a guide. Required sections:
@@ -104,6 +106,8 @@ Use the template's README as a guide. Required sections:
104
106
105
107
### Dry-run mode
106
108
109
+
> Notebook examples are exempt — they require credentials and have no dry-run (see [Notebook examples](#notebook-examples)).
110
+
107
111
Every runnable example must work without credentials. The secrets-free CI `dry-run` job runs `bash run.sh` with no Opik or LLM keys set and expects a clean exit — it is the only execution signal a fork PR receives, so a working dry-run path is required, not optional. The standard pattern:
108
112
109
113
```python
@@ -136,6 +140,8 @@ Each example is a `uv` project: declare dependencies in its `pyproject.toml` (th
136
140
137
141
### run.sh
138
142
143
+
> Notebook examples don't use `run.sh` — they're executed by [`test-notebooks.yml`](.github/workflows/test-notebooks.yml). See [Notebook examples](#notebook-examples).
144
+
139
145
Every testable example must include a `run.sh` at its root. This file is what the CI matrix runs. Requirements:
The compliance check accepts either pattern — it looks for `OPIK_PROJECT_NAME` in `run.sh` or in any `.py` file in the folder.
184
+
The compliance check accepts any of these — it looks for `OPIK_PROJECT_NAME` exported in `run.sh`, or referenced in any `.py` or `.ipynb` file in the folder.
185
+
186
+
### Notebook examples
187
+
188
+
Some guides are Jupyter notebooks rather than runnable scripts. They follow a lighter contract:
- Set `OPIK_PROJECT_NAME` in a notebook cell (e.g. `OPIK_PROJECT_NAME = "my-guide"`) and pass it via `@opik.track(project_name=...)`.
192
+
- Commit with **outputs cleared** — no baked-in execution state (cleaner diffs, no stale/leaked run details).
193
+
- Keep the install cell simple: `%pip install --quiet --upgrade opik` (works in Colab and locally). `pyproject.toml` stays the dependency source of truth and the hook for notebook CI.
194
+
195
+
A notebook teaches by logging real traces you watch render in Opik, so it needs credentials and has **no dry-run**. [`test-notebooks.yml`](.github/workflows/test-notebooks.yml) executes each changed notebook end-to-end with `ipython <notebook>.ipynb` (every cell runs; non-zero exit on the first error) — but only on same-repo PRs where Opik secrets are available. Fork PRs skip execution; the compliance check still runs. Because there's no secrets-free run, a notebook nobody edits isn't re-tested until it changes (a scheduled run for stable notebooks is a future addition).
179
196
180
197
### Opik workspace
181
198
@@ -238,12 +255,12 @@ Before opening a PR, verify:
238
255
-[ ] Folder name is lowercase with underscores (e.g. `my_example`, not `MyExample` or `my-example`)
239
256
-[ ]`README.md` has all required sections
240
257
-[ ] READMEs updated — the example's `README.md`, and for added/renamed/removed examples the bucket index and the root `README.md` table
241
-
-[ ] Dry-run works with no credentials set — `bash run.sh` exits cleanly (this is exactly what CI's secrets-free job runs)
258
+
-[ ] Dry-run works with no credentials set — `bash run.sh` exits cleanly (this is exactly what CI's secrets-free job runs) — *not applicable to notebook examples*
242
259
-[ ]`uv run ruff check .` and `uv run ruff format --check .` are clean
243
260
-[ ] No credentials or `.env` files committed
244
261
-[ ] Dependencies declared in `pyproject.toml` (uv project); no `requirements.txt`
245
-
-[ ]`run.sh` exists and starts with `set -e`
246
-
-[ ]`OPIK_PROJECT_NAME` is set — exported in `run.sh` (scripts) or defined in `config.py` (use-cases/guides)
262
+
-[ ]`run.sh` exists and starts with `set -e` — *or, for notebook examples, the folder ships a `.ipynb` (no `run.sh`) and notebook outputs are cleared*
263
+
-[ ]`OPIK_PROJECT_NAME` is set — exported in `run.sh` (scripts), defined in `config.py` (use-cases/guides), or set in a notebook cell
247
264
-[ ] Examples that call LLMs use litellm and read `OPIK_EXAMPLES_MODEL` in `config.py`
Copy file name to clipboardExpand all lines: README.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -32,6 +32,7 @@ Task-oriented examples for specific Opik workflows and patterns.
32
32
33
33
|| Description |
34
34
|---|---|
35
+
|[guides/annotation_queues_with_context](guides/annotation_queues_with_context/)| Structure RAG traces for Opik annotation queues — clean answer in output, context in metadata, full detail in child spans |
35
36
|[guides/tracing_finetuned_models](guides/tracing_finetuned_models/)| Fine-tune a model, register it to the CometML Model Registry, then fetch and trace inference in Opik |
36
37
37
38
## Use Cases
@@ -41,6 +42,7 @@ End-to-end applications and domain-specific workflows.
41
42
|| Description |
42
43
|---|---|
43
44
|[use-cases/call_summarizer](use-cases/call_summarizer/)| Streamlit app that summarises customer calls using an LLM, traced with Opik |
45
+
|[use-cases/f1_radio_rag](use-cases/f1_radio_rag/)| Typer CLI walking the full Opik loop over F1 team-radio messages: RAG (ChromaDB) → eval dataset + test suite → optimization studio → prompt library |
44
46
|[use-cases/governance_observability](use-cases/governance_observability/)| Instrument agents with governance metadata, derive composite metrics, and extract scores for oversight reporting |
Copy file name to clipboardExpand all lines: guides/README.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,6 +4,7 @@ Task-oriented examples for doing something specific with Opik — combining Opik
4
4
5
5
| Guide | Description |
6
6
|---|---|
7
+
|[annotation_queues_with_context/](./annotation_queues_with_context/)| Structure RAG traces for Opik annotation queues — clean answer in output, context in metadata, full detail in child spans |
7
8
|[tracing_finetuned_models/](./tracing_finetuned_models/)| Fine-tune a model, register it to the CometML Model Registry, then fetch and trace inference in Opik |
Shows how to structure a RAG pipeline's traces so they are immediately useful in Opik [annotation queues](https://www.comet.com/docs/opik/evaluation/advanced/annotation_queues) — a clean answer in `output`, supporting context in `metadata`, and full technical detail preserved in child spans.
4
+
5
+
## What this does
6
+
7
+
A trace gives you four distinct places to put data: `input`, `output`, `metadata`, and child `spans`. A common default is to return the whole pipeline dict — answer, retrieved documents, the built prompt — as the trace `output`, which buries the answer a reviewer needs to score. This example shows how to distribute the data instead:
8
+
9
+
-`input` — the user's question
10
+
-`output` — the final answer only
11
+
-`metadata` — retrieval context, set with `opik_context.update_current_trace()`
12
+
- child `spans` — every sub-step decorated with `@opik.track`; full detail preserved
13
+
14
+
It also covers creating annotation queues programmatically and the post-hoc enrichment pattern for existing traces.
15
+
16
+
## Prerequisites
17
+
18
+
You need an Opik account to follow along — the value of this guide is watching the traces and the annotation queue render live in Opik.
19
+
20
+
| Variable | Description |
21
+
|---|---|
22
+
|`OPIK_API_KEY`| Opik API key |
23
+
|`OPIK_WORKSPACE`| Opik workspace name |
24
+
25
+
No LLM API key required — the example uses a mock retriever and mock LLM.
26
+
27
+
## Running it
28
+
29
+
Open the notebook in Colab (badge below), or run it locally in a uv-managed environment:
30
+
31
+
```bash
32
+
uv sync
33
+
uv run --with jupyter jupyter lab
34
+
```
35
+
36
+
Then open `annotation_queues_with_context.ipynb`.
37
+
38
+
[](https://colab.research.google.com/github/comet-ml/opik-examples/blob/main/guides/annotation_queues_with_context/annotation_queues_with_context.ipynb)
39
+
40
+
## How it works
41
+
42
+
The notebook builds a small traced RAG pipeline and walks through three things:
43
+
44
+
1.**Structuring the trace.**`rag_pipeline()` calls `retrieve()` and `generate()` (each `@opik.track`, so they become child spans), returns only the answer as `output`, and attaches the retrieved context as `metadata` via `opik_context.update_current_trace()`. Input and output stay clean; the supporting detail is one layer down.
45
+
2.**Creating a queue.**`client.create_traces_annotation_queue()` makes a review queue, `client.search_traces()` fetches the traces just logged, and `queue.add_traces()` adds them for review.
46
+
3.**Post-hoc enrichment.** For traces already logged without context, `client.update_trace()` adds metadata after the fact; `client.flush()` commits the writes before the traces are added to a queue.
0 commit comments