GH issue

HeidiSteen · HeidiSteen · commit 87856ffa43ec · 2024-02-18T10:38:05.000-08:00
diff --git a/articles/search/cognitive-search-concept-troubleshooting.md b/articles/search/cognitive-search-concept-troubleshooting.md
@@ -8,39 +8,32 @@ ms.service: cognitive-search
 ms.custom:
   - ignite-2023
 ms.topic: conceptual
-ms.date: 09/16/2022
+ms.date: 02/16/2024
 ---
-# Tips for AI enrichment in Azure AI Search
 
-This article contains a list of tips and tricks to keep you moving as you get started with AI enrichment capabilities in Azure AI Search. 
+# Tips for AI enrichment in Azure AI Search 
 
-If you haven't already, step through [Quickstart: Create a skillset for AI enrichment](cognitive-search-quickstart-blob.md) for a light-weight introduction to enrichment of blob data.
+This article contains tips to help you get started with AI enrichment and skillsets used during indexing.
 
-## Tip 1: Start with a small dataset
+## Tip 1: Start simple and start small
 
-The best way to find issues quickly is to increase the speed at which you can fix issues, which means working with smaller or simpler documents. 
+Both the [Import data wizard](ognitive-search-quickstart-blob.md) and [Import and vectorize data wizard](search-get-started-portal-import-vectors.md) in the Azure portal support AI enrichment. Without writing any code, you can create all of the objects used in an enrichment pipeline: an index, indexer, data source, and skillset.
 
-Start by creating a data source with just a handful of documents or rows in a table that are representative of the documents that will be indexed. 
-
-Run your sample through the end-to-end pipeline and check that the results meet your needs. Once you're satisfied with the results, you're ready to add more files to your data source.
+Another way to start simply is by creating a data source with just a handful of documents or rows in a table that are representative of the documents that will be indexed. A small data set is the best way to increase the speed of finding and fixing issues.Run your sample through the end-to-end pipeline and check that the results meet your needs. Once you're satisfied with the results, you're ready to add more files to your data source.
 
 ## Tip 2: Make sure your data source credentials are correct
 
-The data source connection isn't validated until you define an indexer that uses it. If you get connection errors, make sure that:
-
-+ Your connection string is correct. Specially when you're creating SAS tokens, make sure to use the format expected by Azure AI Search. See [How to specify credentials section](search-howto-indexing-azure-blob-storage.md#credentials) to learn about the different formats supported.
-
-+ Your container name in the indexer is correct.
+The data source connection isn't validated until indexer execution. If you get connection errors, check the connection string, permissions, and the folder or container name.
 
 ## Tip 3: See what works even if there are some failures
 
 Sometimes a small failure stops an indexer in its tracks. That is fine if you plan to fix issues one by one. However, you might want to ignore a particular type of error, allowing the indexer to continue so that you can see what flows are actually working.
 
-In that case, you may want to tell the indexer to ignore errors. Do that by setting *maxFailedItems* and *maxFailedItemsPerBatch* as -1 as part of the indexer definition.
+To ignore errors during development, set `maxFailedItems` and `maxFailedItemsPerBatch` as -1 as part of the indexer definition.
 
-```
+```json
 {
-  "// rest of your indexer definition
+  // rest of your indexer definition
    "parameters":
    {
       "maxFailedItems":-1,
@@ -50,68 +43,34 @@ In that case, you may want to tell the indexer to ignore errors. Do that by sett
 ```
 
 > [!NOTE]
-> As a best practice, set the maxFailedItems, maxFailedItemsPerBatch to 0 for production workloads
-
-## Tip 4: Use Debug sessions to identify and resolve issues with your skillset 
-
-**Debug sessions** is a visual editor that works with an existing skillset in the Azure portal. Within a debug session you can identify and resolve errors, validate changes, and commit changes to a production skillset in the AI enrichment pipeline. This is a preview feature [read the documentation](./cognitive-search-debug-session.md). For more information about concepts and getting started, see [Debug sessions](./cognitive-search-tutorial-debug-sessions.md).
-
-Debug sessions work on a single document are a great way for you to iteratively build more complex enrichment pipelines.
-
-## Tip 5: Looking at enriched documents under the hood 
-
-Enriched documents are temporary structures created during enrichment, and then deleted when processing is complete.
+> As a best practice, set the `maxFailedItems` and `maxFailedItemsPerBatch` to 0 for production workloads
 
-To capture a snapshot of the enriched document created during indexing, add a field called ```enriched``` to your index. The indexer automatically dumps into the field a string representation of all the enrichments for that document.
+## Tip 4: Use Debug session to identify and resolve issues with your skillset 
 
-The ```enriched``` field will contain a string that is a logical representation of the in-memory enriched document in JSON.  The field value is a valid JSON document, however. Quotes are escaped so you'll need to replace `\"` with `"` in order to view the document as formatted JSON. 
+[**Debug session**](./cognitive-search-debug-session.md) is a visual editor that shows a skillset's dependency graph, inputs and outputs, and definitions. It works by loading a single document from your search index, with the current indexer and skillset configuration. You can then run the entire skillset, scoped to a single document. Within a debug session, you can identify and resolve errors, validate changes, and commit changes to a parent skillset. For a walkthrough, see [Tutorial: debug sessions](./cognitive-search-tutorial-debug-sessions.md).
 
-The enriched field is intended for debugging purposes only, to help you understand the logical shape of the content that expressions are being evaluated against. You shouldn't depend on this field for indexing purposes.
+## Tip 5: Expected content fails to appear
 
-Add an ```enriched``` field as part of your index definition for debugging purposes:
-
-#### Request Body Syntax
-
-```json
-{
-  "fields": [
-    // other fields go here.
-    {
-      "name": "enriched",
-      "type": "Edm.String",
-      "searchable": false,
-      "sortable": false,
-      "filterable": false,
-      "facetable": false
-    }
-  ]
-}
-```
-
-## Tip 6: Expected content fails to appear
-
-Missing content could be the result of documents getting dropped during indexing. Free and Basic tiers have low limits on document size. Any file exceeding the limit is dropped during indexing. You can check for dropped documents in the Azure portal. In the search service dashboard, double-click the Indexers tile. Review the ratio of successful documents indexed. If it isn't 100%, you can select the ratio to get more detail. 
+If you're missing content, check for dropped documents in the Azure portal. In the search service page, open **Indexers** and look at the **Docs succeeded** column. Click through to indexer execution history to review specific errors. 
 
 If the problem is related to file size, you might see an error like this: "The blob \<file-name>" has the size of \<file-size> bytes, which exceed the maximum size for document extraction for your current service tier." For more information on indexer limits, see [Service limits](search-limits-quotas-capacity.md).
 
 A second reason for content failing to appear might be related input/output mapping errors. For example, an output target name is "People" but the index field name is lower-case "people". The system could return 201 success messages for the entire pipeline so you think indexing succeeded, when in fact a field is empty. 
 
-## Tip 7: Extend processing beyond maximum run time (24-hour window)
+## Tip 6: Extend processing beyond maximum run time (24-hour window)
 
-Image analysis is computationally intensive for even simple cases, so when images are especially large or complex, processing times can exceed the maximum time allowed. 
+Image analysis is computationally intensive for even simple cases, so when images are especially large or complex, processing times can exceed the maximum time allowed.
 
-Maximum run time varies by tier: several minutes on the Free tier, 24-hour indexing on billable tiers. If processing fails to complete within a 24-hour period for on-demand processing, switch to a schedule to have the indexer pick up processing where it left off. 
+For indexers that have skillsets, skillset execution is [capped at 2 hours for most tiers](search-limits-quotas-capacity.md#indexer-limits). If skillset processing fails to complete within that period, you can put your indexer on a 2-hour recurring schedule to have the indexer pick up processing where it left off. 
 
-For scheduled indexers, indexing resumes on schedule at the last known good document. By using a recurring schedule, the indexer can work its way through the image backlog over a series of hours or days, until all unprocessed images are processed. For more information on schedule syntax, see [Schedule an indexer](search-howto-schedule-indexers.md).
+Scheduled indexing resumes at the last known good document. On a recurring schedule, the indexer can work its way through the image backlog over a series of hours or days, until all unprocessed images are processed. For more information on schedule syntax, see [Schedule an indexer](search-howto-schedule-indexers.md).
 
 > [!NOTE]
-> If an indexer is set to a certain schedule but repeatedly fails on the same document over and over again each time it runs, the indexer will begin running on a less frequent interval (up to the maximum of at least once every 24 hours) until it successfully makes progress again.  If you believe you have fixed whatever the issue that was causing the indexer to be stuck at a certain point, you can perform an on-demand run of the indexer, and if that successfully makes progress, the indexer will return to its set schedule interval again.
-
-For portal-based indexing (as described in the quickstart), choosing the "run once" indexer option limits processing to 1 hour (`"maxRunTime": "PT1H"`). You might want to extend the processing window to something longer.
+> If an indexer is set to a certain schedule but repeatedly fails on the same document over and over again each time it runs, the indexer will begin running on a less frequent interval (up to the maximum of at least once every 24 hours) until it successfully makes progress again. = If you believe you have fixed whatever the issue that was causing the indexer to be stuck at a certain point, you can perform an on-demand run of the indexer, and if that successfully makes progress, the indexer will return to its set schedule interval again.
 
-## Tip 8: Increase indexing throughput
+## Tip 7: Increase indexing throughput
 
-For [parallel indexing](search-howto-large-index.md), place your data into multiple containers or multiple virtual folders inside the same container. Then create multiple data source and indexer pairs. All indexers can use the same skillset and write into the same target search index, so your search app doesn’t need to be aware of this partitioning.
+For [parallel indexing](search-howto-large-index.md), distribute your data into multiple containers or multiple virtual folders inside the same container. Then create multiple data source and indexer pairs. All indexers can use the same skillset and write into the same target search index, so your search app doesn’t need to be aware of this partitioning.
 
 ## See also
 
diff --git a/articles/search/cognitive-search-incremental-indexing-conceptual.md b/articles/search/cognitive-search-incremental-indexing-conceptual.md
@@ -16,7 +16,7 @@ ms.date: 02/16/2024
 > [!IMPORTANT] 
 > This feature is in public preview under [supplemental terms of use](https://azure.microsoft.com/support/legal/preview-supplemental-terms/). The [preview REST API](/rest/api/searchservice/index-preview) supports this feature.
 
-*Incremental enrichment* refers to the use of cached enrichments during [skillset execution](cognitive-search-working-with-skillsets.md) so that only new and changed skills and documents incur AI processing charges. The cache contains the output from [document cracking](search-indexer-overview.md#document-cracking), plus the outputs of each skill for every document. Although caching is billable (it uses Azure Storage), the overall cost of enrichment is reduced because the costs of storage are less than image extraction and AI processing.
+*Incremental enrichment* refers to the use of cached enrichments during [skillset execution](cognitive-search-working-with-skillsets.md) so that only new and changed skills and documents incur pay-as-you-go processing charges for API calls to Azure AI services. The cache contains the output from [document cracking](search-indexer-overview.md#document-cracking), plus the outputs of each skill for every document. Although caching is billable (it uses Azure Storage), the overall cost of enrichment is reduced because the costs of storage are less than image extraction and AI processing.
 
 When you enable caching, the indexer evaluates your updates to determine whether existing enrichments can be pulled from the cache. Image and text content from the document cracking phase, plus skill outputs that are upstream or orthogonal to your edits, are likely to be reusable.
 
diff --git a/articles/search/cognitive-search-skill-textsplit.md b/articles/search/cognitive-search-skill-textsplit.md
@@ -8,7 +8,7 @@ ms.service: cognitive-search
 ms.custom:
   - ignite-2023
 ms.topic: reference
-ms.date: 10/25/2023
+ms.date: 02/18/2024
 ---
 
 # Text split cognitive skill
@@ -44,7 +44,7 @@ Parameters are case-sensitive.
 
 | Parameter name	 | Description |
 |--------------------|-------------|
-| `textItems`	| An array of substrings that were extracted. |
+| `textItems` | An array of substrings that were extracted. `textItems` is the default name of the output. `targetName` is optional, but if you have multiple text split skills, make sure to set `targetName` so that you don't overwrite the data from the first skill with the second one. If `targetName` is set, use it in output field mappings or in downstream skills that use the skill output.|
 
 ## Sample definition
 
@@ -135,7 +135,9 @@ This example is for integrated vectorization, currently in preview. It adds prev
 
 This definition adds `pageOverlapLength` of 100 characters and `maximumPagesToTake` of one. 
 
-Assuming the `maximumPageLength` is 5000 characters (the default), then `"maximumPagesToTake": 1` processes the first 5000 characters of each source document. 
+Assuming the `maximumPageLength` is 5,000 characters (the default), then `"maximumPagesToTake": 1` processes the first 5,000 characters of each source document.
+
+This example sets `textItems` to `myPages` through `targetName`. Because `targetName` is set, `myPages` is the value you should use to select the output from the Text Split skill. Use `/document/mypages/*` in downstream skills, indexer output field mappings, knowledge store projection, or index projections.
 
 ```json
 {
diff --git a/articles/search/search-get-started-terraform.md b/articles/search/search-get-started-terraform.md
@@ -2,7 +2,7 @@
 title: 'Quickstart: Deploy using Terraform'
 description: 'In this article, you create an Azure AI Search service using Terraform.'
 ms.topic: quickstart
-ms.date: 4/14/2023
+ms.date: 02/16/2024
 ms.custom:
   - devx-track-terraform
   - ignite-2023
