Modernize image serving example - #190
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
|
Addressed the feedback from former inline discussion The notebook now states that retrieve reports aggregate image-serving activity without dedicated fields for individual asset-store paths or image bytes. It separately identifies the wildcard index query as the source of The original inline comment currently returns |
Hailey Tapia (haileytap)
left a comment
Hailey Tapia (haileytap)
left a comment
There was a problem hiding this comment.
Approved pending some minor suggestions.
| @@ -5,30 +5,31 @@ | |||
| "id": "92ebfca4", | |||
| "metadata": {}, | |||
| "source": [ | |||
There was a problem hiding this comment.
Please add (preview) labels to applicable functionality in this notebook.
| "metadata": {}, | ||
| "source": [ | ||
| "# Example: Image Serving with Azure Blob Knowledge Source\n", | ||
| "# Example: Image serving for agentic retrieval using Python\n", |
There was a problem hiding this comment.
The C# and Python samples describe the same end-to-end workflow, but their opening content differs in positioning, terminology, prerequisite structure, and setup flow. Could we align the companion samples so that readers receive the same conceptual framing and requirements regardless of language?
In particular:
-
Use parallel introductory wording for the managed-ingestion and indexed-image workflows.
-
Include the same distinction from the classic
OcrSkillandnormalized_imagesapproach. -
Use unordered prerequisites in the same order and at the same level of detail. To reduce duplication and maintenance, I recommend replacing both prerequisite lists with: "For required resources and permissions, see Surface document-embedded images in agentic retrieval (preview)." Keep only language-specific requirements in each sample.
-
If desired, keep sequential workflow steps under a separate "Flow" section.
2 participants
Summary
Validation