kaxil commented on code in PR #69551: URL: https://github.com/apache/airflow/pull/69551#discussion_r3543165679
########## providers/common/ai/docs/index.rst: ########## @@ -19,6 +19,46 @@ ``apache-airflow-providers-common-ai`` ################################################## +When to use this provider Review Comment: A reader landing here to answer "which package do I install?" tends to scan before reading. Today that answer is split across prose on three pages, so they have to open all three and derive the rule themselves. A short feature-to-package table on this page (embeddings / batch / responses -> the vendor package; portable generation and worker-run agents with toolsets -> common.ai; managed server-side agents -> the vendor package) would let them decide at a glance, with the prose below as the "why". The prose is good, it just isn't scannable yet. ########## providers/common/ai/docs/index.rst: ########## @@ -19,6 +19,46 @@ ``apache-airflow-providers-common-ai`` ################################################## +When to use this provider +-------------------------- + +``common.ai`` is the vendor-neutral way to put LLM and agent steps in a Dag. It is built on Review Comment: A reader who already has LangChain or LlamaIndex code may read "built on pydantic-ai" as "not for me" and move on. Since the provider ships a LangChain toolset (the `langchain` extra), one sentence noting that existing LangChain tools can be called from a common.ai agent would keep that reader engaged, without overstating support. ########## providers/anthropic/docs/index.rst: ########## @@ -19,6 +19,41 @@ ``apache-airflow-providers-anthropic`` ====================================== +When to use this provider Review Comment: Placement: on this page the section renders above the one-line description of what the provider actually is (that line sits lower, in the generated block). So a first-time visitor meets a comparison before a definition. A short lead-in sentence naming what the provider is, or placing this section just under the provider tagline, would orient them first. ########## providers/openai/docs/index.rst: ########## @@ -19,6 +19,41 @@ ``apache-airflow-providers-openai`` ====================================== +When to use this provider +-------------------------- + +Use ``openai`` when a Dag needs OpenAI's native API surface — thin wrappers over +OpenAI-specific endpoints and options: + +* ``OpenAIEmbeddingOperator`` — call the Embeddings API directly, e.g. to feed a vector + store. +* ``OpenAIResponseOperator`` — call the + `Responses API <https://platform.openai.com/docs/api-reference/responses>`__ with + OpenAI-specific parameters. +* ``OpenAITriggerBatchOperator`` and ``OpenAIHook`` — submit a Review Comment: Two small things on this bullet: 1. `OpenAIHook` is the general client, not batch-specific, so listing it under "submit a Batch API job ... and wait for it to complete" reads as if the hook is a batch tool. Consider dropping it here, or mentioning it separately as the low-level access path. 2. This says what the batch operator does (async bulk) but not why a reader would reach for it over running the step in the worker. The Batch API runs at roughly half the per-token cost on a ~24h turnaround, and that cost-vs-latency tradeoff is the decision the reader is making on this page. One clause about it turns "what it is" into "when to pick it". ########## providers/openai/docs/index.rst: ########## @@ -19,6 +19,41 @@ ``apache-airflow-providers-openai`` ====================================== +When to use this provider Review Comment: Placement: on this page the section renders above the one-line description of what the provider actually is (that line sits lower, in the generated block). So a first-time visitor meets a comparison before a definition. A short lead-in sentence naming what the provider is, or placing this section just under the provider tagline, would orient them first. ########## providers/common/ai/docs/index.rst: ########## @@ -19,6 +19,46 @@ ``apache-airflow-providers-common-ai`` ################################################## +When to use this provider +-------------------------- + +``common.ai`` is the vendor-neutral way to put LLM and agent steps in a Dag. It is built on +`pydantic-ai <https://ai.pydantic.dev/>`__, so the model vendor (OpenAI, Anthropic, Google, +Bedrock, …) is picked by the connection ``llm_conn_id`` points at — switching providers later +is a connection change, not a Dag rewrite. The AI step is orchestrated by Airflow: the model +calls, the agent loop, and any tools all run in the Airflow worker, where they get retries, +logging, and observability like any other task. + +Use it when a Dag needs: + +* **Generation, classification, summarization, or structured extraction** — + :doc:`LLMOperator and @task.llm <operators/llm>`, with Pydantic-typed output pushed to XCom. +* **Branching on a model's decision** — :doc:`LLMBranchOperator <operators/llm_branch>`. +* **Agents with tools** — :doc:`AgentOperator <operators/agent>` runs a multi-turn agent loop Review Comment: Toolsets are the clearest thing separating a worker-run agent from a plain LLM call, but they appear here only as a parenthetical. A reader comparing this against a managed-agent service is exactly who needs that capability made visible, so it is worth linking to the Toolsets page (``:doc:`toolsets` ``) rather than leaving it inline. Minor: "durable step replay" isn't glossed here. The AgentOperator link does explain it further down, so this is optional, but a few words of context would help a reader who doesn't click through. ########## providers/anthropic/docs/index.rst: ########## @@ -19,6 +19,41 @@ ``apache-airflow-providers-anthropic`` ====================================== +When to use this provider +-------------------------- + +Use ``anthropic`` when a Dag needs Anthropic's native API surface — services Anthropic runs +for you, which no vendor-neutral operator wraps: + +* ``AnthropicBatchOperator`` and ``AnthropicBatchSensor`` — submit a Claude Review Comment: This describes what the batch operator does (async bulk) but not why a reader would reach for it over running the step in the worker. The Message Batches API runs at roughly half the per-token cost on a ~24h turnaround, and that cost-vs-latency tradeoff is the actual decision on this page. Adding that clause turns "what it is" into "when to pick it". -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
