vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For more information about next-generation models and low latency, see



* [Next-generation languages and models](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-models-ng)
* [Customization support for next-generation models](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-custom-supportcustom-language-support-ng)
* [Low latency](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-interimlow-latency)



Defect fix: Correct custom word recognition in transcription results for next-generation models
: Defect fix: For language model customization with next-generation models, custom words are now recognized and used in all transcripts. Previously, custom words sometimes failed to be recognized and used in transcription results.

Defect fix: Correct use of display_as field in transcription results for next-generation models
: Defect fix: For language model customization with next-generation models, the value of the display_as field for a custom word now appears in all transcripts. Previously, the value of the word field sometimes appeared in transcription results.

Defect fix: Update custom model naming documentation
: Defect fix: The documentation now provides detailed rules for naming custom language models and custom acoustic models. For more information, see



* [Create a custom language model](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-languageCreatecreateModel-language)
* [Create a custom acoustic model](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-acousticcreateModel-acoustic)
* [API & SDK reference](https://cloud.ibm.com/apidocs/speech-to-text)







 20 October 2022 

Updates to English next-generation telephony models
: The English next-generation telephony models have been updated for improved speech recognition:



* en-AU_Telephony
* en-GB_Telephony
Common use cases include conversations between a patient and a medical provider (for example, a doctor, nurse, or pharmacist).

The new model is available for all supported English dialects: Australian, Indian, UK, and US. The new model supports language model customization and grammars as beta functionality. It supports most of the same parameters as the en-US_Telephony model, including smart_formatting for US English audio. It does not support the following parameters: low_latency, profanity_filter, redaction, and speaker_labels.

For more information, see [The English medical telephony model](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-models-ngmodels-medical).

Update to Chinese zh-CN_Telephony model
: The next-generation Chinese model zh-CN_Telephony has been updated for improved speech recognition. The model continues to support low latency. By default, the service automatically uses the updated model for all speech recognition requests. For more information about all available next-generation models, see [Next-generation languages and models](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-models-ng).

If you have custom language models that are based on the updated model, you must upgrade your existing custom models to take advantage of the updates by using the POST /v1/customizations/{customization_id}/upgrade_model method. For more information, see [Upgrading custom models](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-custom-upgrade).

Update to Japanese ja-JP_Multimedia next-generation model to support low latency
: The next-generation Japanese model ja-JP_Multimedia now supports low latency. You can use the low_latency parameter with speech recognition requests that use the model. You do not need to upgrade custom models that are based on the updated Japanese base model. For more information about the next-generation models and low latency, see
For example, metric data for an instance that is provisioned in US South is hosted in the US South region.







 Data retention 

Data is retained for each instance based on a roll-up policy.

As time progresses, the data is rolled up from a fine granularity to a coarser one by the end 2 months.

The roll-up policy describes the granularity of the data over time:



* Data is retained at 10-second resolution for the first 4 hours.
* Data is retained at 1-minute resolution for 2 days.
* Data is retained at 10-minute resolution for 2 weeks.
* Data is retained at 1-hour resolution for 2 months.
* Data is retained at 1-day resolution for 15 months.







 Data availability 

Data is available for a maximum of 15 months.

User metadata is always available.

After you remove a monitoring agent from a host or container, historical data is not deleted.



* Data is available for a maximum of 15 months.
* Data is available for analysis through the web UI for the time period that the agent was installed and reporting.



After you delete an instance of the IBM Cloud Monitoring service, data is not available for search and analysis.







 Deleting your data 



 Deleting metric data 

Metric data is deleted automatically after 15 months.





 Deleting user metadata 

User metadata, such as alerts, dashboards, teams, and users, is never deleted.

You must open a case through support to request the metadata to be deleted. For more information, see [Open a support ticket](https://cloud.ibm.com/docs/get-support?topic=get-support-open-case).





 Deleting a subset of data 

Deletion of a subset of data is not supported.

For example, deletion of data that is collected from 1 monitoring agent in a Monitoring instance is not supported.





 Deleting captures 

When you delete a capture, the data file for that capture is automatically deleted.





 Deleting an IBM Cloud Monitoring instance 

When you delete an instance of IBM Cloud Monitoring from the IBM Cloud, you must open a case through support to request the data to be deleted.
[Shows the two containment metrics for volume and trend](https://cloud.ibm.com/docs-content/v1/content/a2b18c153837bce00a5b4de496e4b4ca64bbf56e/assistant-data/images/containment-metric.png)

The containment metric requires that your dialog flag requests for external support when they occur. For more information, see [Measuring containment](https://cloud.ibm.com/docs/assistant-data?topic=assistant-data-dialog-supportdialog-support-containment).
* Coverage: Number of conversations in which the assistant is confident that it can address a customer's request.



* The volume graph shows the total number of conversations per day and how many of the conversations were covered (meaning intents in your dialog understood user requests and were able to address them), and not covered (meaning the input did not match an intent in the dialog and was processed by the Anything else node instead).
* The trend graph shows the percentage of daily conversations that were covered. This graph helps you to see if your dialog is getting better or worse at covering conversations over time.



![Shows the two coverage metrics for volume and trend](https://cloud.ibm.com/docs-content/v1/content/a2b18c153837bce00a5b4de496e4b4ca64bbf56e/assistant-data/images/coverage-metric.png)

The coverage metric requires that your dialog contain an Anything else node.
* Total conversations: The total number of conversations between active users and your assistant during the selected time period.
* Average messages per conversation - The total messages received during the selected time period divided by the total conversations during the selected time period.
* Total messages - The total number of messages received from active users over the selected time period.
* Active users - The number of unique users who have engaged with your assistant within the selected time period.
* Average conversations per user - The total conversations divided by the total number of unique users during the selected time period.

Statistics for Active users and Average conversations per user require a unique user_id parameter.
Known limitations 

The Speech to Text service has the following known limitations. These issues apply to service functionality that spans releases for all platforms. For information about known limitations specific to Speech to Text for IBM Cloud Pak for Data version 4.6.x, see [Limitations and known issues in Watson Speech services](https://www.ibm.com/docs/en/cloud-paks/cp-data/4.6.x?topic=issues-watson-speech-services).



 Issue: Interim results for previous-generation models 

27 April 2021: When you use previous-generation models with the WebSocket interface, if you request both speaker labels and interim results, the speaker labels response includes an extra object. The final results duplicate the object for the last speaker label. Instead of appearing once with "final": true, the object appears twice: once with "final": false and once with "final": true.

For example, a WebSocket request that includes both speaker labels and interim results sends a start message like the following:

var message = {
action: 'start',
speaker_labels: true,
interim_results: true
};
websocket.send(JSON.stringify(message));

To indicate final results for speaker labels, the service is supposed to return a response of the following form:

{
"speaker_labels": [
. . .
{
"from": 1.01,
"to": 1.75,
"speaker": 0,
"confidence": 0.75,
"final": false
},
{
"from": 1.76,
"to": 2.50,
"speaker": 1,
"confidence": 0.80,
"final": true
}
]
}
Show more

Instead, the service returns final results like the following. Note that the object for the last speaker label, which begins at 1.76 and ends at 2.50, is returned twice. The "final": true indication is associated with the second instance of the label.

{
RetentionLegalHoldId: legalHoldId
}).promise()
.then(() => {
console.log(Legal hold ${legalHoldId} added to object ${objectName} in bucket ${bucketName}!);
})
.catch((e) => {
console.log(ERROR: ${e.code} - ${e.message}n);
});
}

function deleteLegalHoldFromObject(bucketName, objectName, legalHoldId) {
console.log(Deleting legal hold ${legalHoldId} from object ${objectName} in bucket ${bucketName});
return cos.client.deleteLegalHold({
Bucket: bucketName,
Key: objectId,
RetentionLegalHoldId: legalHoldId
}).promise()
.then(() => {
console.log(Legal hold ${legalHoldId} deleted from object ${objectName} in bucket ${bucketName}!);
})
.catch((e) => {
console.log(ERROR: ${e.code} - ${e.message}n);
});
}





 Extend the retention period of an object 

This implementation of the POST operation uses the extendRetention query parameter to extend the retention period of a protected object in a protected bucket.

The retention period of an object can only be extended. It cannot be decreased from the currently configured value.

The retention expansion value is set in one of three ways:



* additional time from the current value (Additional-Retention-Period or similar method)
* new extension period in seconds (Extend-Retention-From-Current-Time or similar method)
* new retention expiry date of the object (New-Retention-Expiration-Date or similar method)



The current retention period that is stored in the object metadata is either increased by the given extra time or replaced with the new value, depending on the parameter that is set in the extendRetention request.
Speech audio parsing 

The IBM Watson® Speech to Text service provides multiple features that determine how the service is to parse audio to produce final transcription results.



* End of phrase silence time specifies the duration of the pause interval at which the service splits a transcript into multiple final results.
* Split transcript at phrase end directs the services to split a transcript into multiple final results for semantic features such as sentences.
* Character insertion bias directs the service to favor character sequences of shorter or greater length as it develops transcription hypotheses with next-generation models.





 End of phrase silence time 

The end_of_phrase_silence_time parameter specifies the duration of the pause interval at which the service splits a transcript into multiple final results. If the service detects pauses or extended silence before it reaches the end of the audio stream, its response can include multiple final results. Silence indicates a point at which the speaker pauses between spoken words or phrases. For most languages, the default pause interval is 0.8 seconds; for Chinese the default interval is 0.6 seconds. For more information, see [Pauses and silence](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-basic-responseresponse-pauses-silence).

By using the end_of_phrase_silence_time parameter, you can specify a double value between 0.0 and 120.0 seconds that indicates a different pause interval:



* A value greater than 0 specifies the interval that the service is to use for speech recognition.
* A value of 0 indicates that the service is to use the default interval. It is equivalent to omitting the parameter.



You can use the parameter to strike a balance between how often a final result is produced and the accuracy of the transcription:



* A longer pause interval produces fewer final results, and each result covers a larger segment of audio. Larger segments tend to be more accurate because the service has more context with which to transcribe the audio.

However, larger pause intervals directly impact the latency of the final results. After the last word of the input audio, the service must wait for the indicated interval to expire before it returns its response. The service waits to ensure that the input audio does not continue beyond the longer interval.
After adding or modifying a custom word, it is important that you verify the correctness of the word's definition; for more information, see [Validating a words resource for next-generation models](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-corporaWords-ngvalidateModel-ng). You must also train the model for the changes to take effect during transcription; for more information, see [Train the custom language model](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-languageCreatetrainModel-language).

You can add custom words that already exist, for example, to add more sounds-like pronunciations for common words. Otherwise, there is no reason to duplicate common words. Such words remain in the model's words resource, but they are harmless and unnecessary.





 How much data do I need? 

Many factors contribute to the amount of data that you need for an effective custom language model. It is not possible to indicate the exact amount of data that you need to add for any custom model or application. Depending on the use case, even adding a few words directly to a custom model can improve the model's quality. But adding corpora that show the words in the context in which they are used can greatly improve transcription accuracy.

You can add a maximum of 10 million total words to a custom model from all sources. This figure includes all words that are included in corpora and that you add directly. The service uses all of the words from a corpus to learn the context in which sequences of characters can occur, which is why corpora are a more effective means of improving recognition accuracy.

Adding a large number of corpora and words can increase the latency of speech recognition, but the exact effect is difficult to quantify or predict. As with the amount of data that is needed to produce an effective custom model, the performance impact of a large amount of data depends on many factors. Test your custom model with different amounts of data to determine the performance of your models.



 Guidelines for adding words to custom models based on improved next-generation models
Users are typically willing to wait about 8 seconds (8,000 ms) for someone to enter a response. To prevent a typing indicator from being displayed during the pause, choose Off.

Add another response type, such as a text response type, after the pause to clearly denote that the pause is over.



* If you want different follow-up statements to be shown based on whether the user provides the information you need in response to the initial slot prompt, you can edit the slot (by clicking the Edit slot![Edit slot](https://cloud.ibm.com/docs-content/v1/content/a2b18c153837bce00a5b4de496e4b4ca64bbf56e/assistant-data/images/edit-slot.png) icon) and define the follow-up statements:



* Found: Displayed after the user provides the expected information.
* Not found: Displayed if the information provided by the user is not understood, or is not provided in the expected format. If the slot is filled successfully, or the user input is understood and handled by a slot handler, then this statement is never displayed.



For information about how to define conditions and associated actions for Found and Not found responses, see [Adding conditions to Found and Not found responses](https://cloud.ibm.com/docs/assistant-data?topic=assistant-data-dialog-slotsdialog-slots-handler-next-steps).



This table shows example slot values for a node that helps users place a pizza order by collecting two pieces of information, the pizza size and delivery time.



Example slots for pizza order

 Check for Save as Prompt Follow-up if found Follow-up if not found 

 @size $size What size pizza would you like? $size it is. What size did you want? We have small, medium, and large. 
 @sys-time $time When do you need the pizza by? For delivery by $time. What time did you want it delivered? We need at least a half hour to prepare it. 



5. Make a slot optional or disable it under certain conditions. You can optionally configure a slot in these ways:
GET /api/v1/retentions container-registry.retention.list container-registry.retention.list 
 Set the retention policy for the specified namespace. POST /api/v1/retentions container-registry.retention.set container-registry.retention.set 
 Analyze a retention policy, and get a list of what would be deleted by it. POST /api/v1/retentions/analyze container-registry.retention.analyze container-registry.retention.analyze 
 Get the retention policy for the specified namespace. GET /api/v1/retentions/{namespace} container-registry.retention.get container-registry.retention.get 







 Settings API methods 



Table 8. Settings

 Action Method IAM ACTION AT ACTION 

 Get registry service settings for the targeted account, such as whether platform metrics are enabled. GET /api/v1/settings container-registry.settings.get container-registry.settings.get 
 Update registry service settings for the targeted account, such as enabling platform metrics. PATCH /api/v1/settings container-registry.settings.set container-registry.settings.set 







 Tag API methods 



Table 9. Tags

 Action Method IAM ACTION AT ACTION 

 Delete tag. DELETE /api/v1/tags/{image} container-registry.image.delete container-registry.image.untag 







 Trash API methods 



Table 10. Trash

 Action Method IAM ACTION AT ACTION 

 List images in the trash. GET /api/v1/trash container-registry.image.delete container-registry.trash.list 
 Restore a digest and all associated tags. POST /api/v1/trash/{digest}/restoretags container-registry.image.push container-registry.trash.restore 
 Restore deleted image. POST /api/v1/trash/{image}/restore container-registry.image.push container-registry.trash.restore 









 Vulnerability Advisor API methods 



 Report API methods 



Table 11. Report

 Action Method IAM ACTION AT ACTION 

 Get the vulnerability assessment for all images.
Some historical rows might be preserved for incremental backup purposes, but the rows are not accessible to time travel queries.

If you alter DATA_VERSION_RETENTION_TIME of an existing temporal table to zero, the table becomes a nontemporal table. It no longer supports access to historical data with time travel queries.





 Limitations 

Changes to retention time intervals for tables, schemas, and databases are not replicated from primary to replica nodes. They are not historical (deleted) table rows either.

Retention time intervals of tables, schemas, and databases are automatically backed up by the nzbackup command and restored by the nzrestore command. The insert and delete timestamps of table rows are not backed up and restored. Restored rows get fresh insert timestamps in the target database or system, and rows that were deleted by incremental restore get fresh delete timestamps in the target database or system. There is no expectation or guarantee that the number of historical versions of a row on the target will match that on the source database. For example, a specific row might get updated multiple times, or get updated and then deleted, between backup increments on the source. This actions result in a single delete of that row on the target.

If you try to expand your Netezza Performance Server system with additional SPU enclosures, the procedure results in the loss of historical (deleted) rows. All current rows are redistributed with fresh insert timestamps.

The following types of tables cannot be temporal tables:



* Temporary tables
* External tables
* Versioned tables that were altered by adding and/or dropping columns
* Row-secure tables.



This limitation affects the following commands:



* [CREATE TABLE ROW SECURITY](https://www.ibm.com/docs/en/netezza?topic=npsscr-create-table-2), [CREATE EXTERNAL TABLE](https://www.ibm.com/docs/en/netezza?topic=npsscr-create-external-table-2), CREATE TEMPORARY TABLE
If DATA_VERSION_RETENTION_TIME is specified to a nonzero value, the commands fail.
* For more information about the interaction of the interim_results and low_latency parameters with next-generation models, including examples that demonstrate the different combinations of parameters, see [Requesting interim results and low latency](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-interiminterim-low-latency).





The client receives multiple JSON objects in response. The service returns separate response objects for each interim result and for each each final result that is generated by the audio. The service sends at least one interim result for each final result.

The service sends responses as soon as they are available. It does not wait for a stop message to send its results, though the stop message is still required to signal the end of transmission for the request. The structure and format of the service's response is the same regardless of whether you use a previous- or next-generation model.

{
"result_index": 0,
"results": [
{
"alternatives":
{
"transcript": "one "
}
],
"final": false
}
]
}{
"result_index": 0,
"results": [
{
"alternatives":
{
"transcript": "one two "
}
],
"final": false
}
]
}{
"result_index": 0,
"results": [
{
"alternatives":
{
"confidence": 0.99,
"transcript": "one two "
}
],
"final": true
}
]
}{
"result_index": 1,
"results": [
{
"alternatives":
{
"transcript": "three "
}
],
"final": false
}
]
}{
"result_index": 1,
"results": [
{
"alternatives":
{