vania-janet/multiturn-rag-retrieval-data huggingface dataset:
[Shows the two containment metrics for volume and trend](https://cloud.ibm.com/docs-content/v1/content/417db917d18067d9dcc4cf2612564a9a87c3ddc8/assistant/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?topic=assistant-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/417db917d18067d9dcc4cf2612564a9a87c3ddc8/assistant/images/coverage-metric.png)

The coverage metric requires that your dialog contain an Anything else node. For more information, see [Ending the conversation gracefully](https://cloud.ibm.com/docs/assistant?topic=assistant-dialog-startdialog-start-anything-else).

The containment and coverage metrics are available to Plus or Enterprise plan users.
* Total conversations: The total number of conversations between active users and your assistant during the selected time period. This number counts exchanges in which the welcome message is displayed to a user, even if the user doesn't respond.
* Average messages per conversation - The total messages received during the selected time period divided by the total conversations during the selected time period.
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)



Update to German de-DE_Multimedia next-generation model to support low latency
: The next-generation German model, de-DE_Multimedia, now supports low latency. You do not need to upgrade custom models that are based on the updated German base model. For more information about the 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)
* [Low latency](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-interimlow-latency)



Support for sounds-like is now documented for custom models based on next-generation models
: For custom language models that are based on next-generation models, support is now documented for sounds-like specifications for custom words. Support for sounds-likes has been available since late 2021.

Differences exist between the use of the sounds_like field for custom models that are based on next-generation and previous-generation models. For more information about using the sounds_like field with custom models that are based on next-generation models, see [Working with custom words for next-generation models](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-corporaWords-ngworkingWords-ng).

Important: Deprecated customization_id parameter removed from the documentation
(https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/activity-tracker/images/streaming-topic-2.png)
8. Select a Message retention and click Create Topic.

Message retention defines how long messages are retained before they are deleted. If your messages are not read by a consumer within this time, they will be missed.







 Step 2. Create credentials to authenticate the auditing instance with Event Streams 

You need the following information to connect the IBM Cloud Activity Tracker instance to the Event Streams instance:



* Endpoint URLs to call the APIs
* Credentials for authentication



Complete the following steps to create service credentials that the IBM Cloud Activity Tracker instance needs to communicate with the Event Streams instance:



1. In the IBM Cloud, click the Menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/icons/icon_hamburger.svg) > Resource list.
2. Look for the Event Streams instance that you plan to use, and select it.
3. In the Event Streams console, click Service credentials.
4. Select New credential.
5. Enter a name and select the writer role.

![Create a credential.](https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/activity-tracker/images/streaming-credentials.png)
6. Click Add.



To restrict access to 1 topic, complete the following steps:



1. From the menu bar, click Manage > Access (IAM), and select Service IDS.

!
You do not need to worry about the session timeout after you send the last chunk to indicate the end of the stream. The service continues to process the audio until it returns the final transcription results.

When you transcribe a long audio stream, the service can take more than 30 seconds to process the audio and generate a response. The service does not begin to calculate the session timeout until it finishes processing all audio that it has received. The service's processing time cannot cause the session to exceed the 30-second session timeout.

For example, if you send one hour of audio in the first 10 seconds of a session, the service might take 300 seconds to process the audio. To keep this session alive, you would need to send at least 15 more seconds of some audio, including silence, no later than 340 seconds into the session.

In this example, if you were to send another 15 seconds of audio at the 100-second mark of the session, the service might spend an additional two seconds processing this audio. In this case, you would need to send 15 more seconds of audio no later 342 seconds into the session.

Do not rely on processing time or on whether you have received results to determine whether a streaming session is idle. Assume that the service can process all audio instantly, and send data to the service accordingly. If you stream audio in real-time, do not fall behind in sending audio at one-half real-time (15 seconds of audio) in any 30-second window. This rate is typically sufficient to accommodate network latency and delays.
When you set DATA_VERSION_RETENTION_TIME to 0, you cannot run time travel queries and you do not have access to historical rows for that table anymore. You can reclaim some or all of the now inaccessible historical rows in the table with GROOM TABLE.





 Altering nontemporal tables to temporal with the command-line 

To alter a nontemporal table to temporal, set DATA_VERSION_RETENTION_TIME] to a nonzero value.

For detailed syntax and the necessary privileges, see [the ALTER TABLE command](https://www.ibm.com/docs/en/netezza?topic=npsscr-alter-table-2).

ALTER TABLE <table> DATA_VERSION_RETENTION_TIME <number-of-days>;

Example:

ALTER TABLE PRODUCT DATA_VERSION_RETENTION_TIME 30;

If you first disabled your temporal table and then converted the same table to a temporal table, you do not have access to the prior historical rows for that table. Historical data is collected when rows are deleted or updated after the table is converted to temporal.

As with the CREATE TABLE command, a row that is inserted into the table receives a virtual insert timestamp that is equal to the commit time of the inserting transaction. A row that is deleted from the table receives a virtual delete timestamp that is equal to the commit time of the deleting (or truncating) transaction. The table’s retention lower bound and retention start time are equal to or just before the commit time of this ALTER TABLE transaction.

Unlike the CREATE TABLE command, which does not have any existing rows, existing visible rows in the table are treated as if they were inserted by this ALTER TABLE transaction. The existing visible rows receive virtual insert timestamps that are equal to the retention start time. With these timestamps, the rows are potentially visible to time travel queries.





 Altering temporal schemas to nontemporal with the command-line 

To alter a temporal schema to nontemporal, set DATA_VERSION_RETENTION_TIME to 0.
BETWEEN <TIMESTAMP EXPRESSION 1> AND <TIMESTAMP EXPRESSION 2> Includes all the rows that were valid at any time between TIMESTAMP EXPRESSION 1 and TIMESTAMP EXPRESSION 2 (inclusive), whose insert timestamp is less than or equal to TIMESTAMP EXPRESSION 2 and whose delete timestamp is NULL or is greater than TIMESTAMP EXPRESSION 1. If TIMESTAMP EXPRESSION 1 or TIMESTAMP EXPRESSION 2 is less than the table’s retention start timestamp, an error is returned. If TIMESTAMP EXPRESSION 1 is greater than TIMESTAMP EXPRESSION 2, the query produces no rows. 









 Timestamps in time travel queries 



 Retention time interval and retention time period 

A table’s retention time interval defines the number of days past their delete timestamps that historical (deleted) rows are available for time travel queries. At any given time, the retention time period ends at the current timestamp (date and time) and extends back the given number of days. This is a sliding time window that advances as the current system time advances.





 Retention lower bound 

For the most part, a table’s retention lower bound is the date and time when the table was defined to be a temporal table. This could have been when you ran the CREATE TABLE command, or the last time you altered the table’s DATA_VERSION_RETENTION_TIME from zero to non-zero.





 Retention start timestamp 

At the time of defining a table to be temporal (when the retention lower bound is defined), there are no historical rows available over the retention time period. To capture the notion of how far back historical rows are actually available (visible to time travel queries), a table’s retention start timestamp is defined. The retention start timestamp is the larger of the following values:



* The beginning of the retention time period (the current date/time minus the retention interval).
* The retention lower bound.



A table’s retention start timestamp comes into play in the following operations:



* Time travel queries (SELECT and sub-SELECT)

If you attempt to run queries for historical rows that were deleted before the retention start timestamp, an error is returned.
* [Commodity Futures Trading Commission (CFTC) Rule 1.31(c)-(d)](https://www.ecfr.gov/cgi-bin/text-idx?SID=2404f765a6f79e0b7fcf05b6844046cb&mc=true&node=se17.1.1_131&rgn=div8)



To assist clients in making informed decisions, IBM engaged Cohasset Associates Inc. to conduct an independent assessment of IBM’s Immutable Object Storage. Review [Cohasset Associates Inc.’s report](https://cloud.ibm.com/docs/images/immutable-cos.pdf) that provides details on the assessment of the Immutable Object Storage feature of IBM Cloud Object Storage.



 Audit of access and transactions 

Access log data for Immutable Object Storage to review changes to retention parameters, object retention period, and application of legal holds is available on a case-by-case basis by opening a customer service ticket.







 Using the console 

Retention policies can be added to new or existing empty buckets, and cannot be removed. For a new bucket, ensure that you are creating the bucket in a [supported region](https://cloud.ibm.com/docs/services/cloud-object-storage/basics?topic=cloud-object-storage-service-availabilityservice-availability), and then choose the Add retention policy option. For an existing bucket, ensure that it has no objects and then navigate to configuration settings and click the Create policy button below the bucket retention policy section. In either case, set a minimum, maximum, and default retention periods.





 Using the REST API, Libraries, and SDKs 

Several new APIs have been introduced to the IBM Cloud Object Storage SDKs to provide support for applications working with retention policies. Select a language (HTTP, Java, JavaScript, or Python) at the beginning of this page to view examples that use the appropriate Object Storage SDK.

All code examples assume the existence of a client object that is called cos that can call the different methods. For details on creating clients, see the specific SDK guides.

All date values used to set retention periods are Greenwich mean time.
Modifying speech synthesis characteristics 

The IBM Watson® Text to Speech service includes query parameters that you can use to globally modify the characteristics of speech synthesis for an entire request: rate_percentage, pitch_percentage, and spell_out_mode. These parameters are available for both the HTTP and WebSocket interfaces.

Each of these parameters interacts with elements of the Speech Synthesis Markup Language (SSML). The descriptions of the parameters include information about how they interact with related SSML elements and attributes.



 Modifying the speaking rate 

The rate_percentage parameter is beta functionality.

The speaking rate is the speed at which the service speaks the text that it synthesizes into speech. A higher rate causes the text to be spoken more quickly; a lower rate causes the text to be spoken more slowly.

You can use the optional rate_percentage query parameter to modify the rate of the synthesized speech for a voice. Each voice has a default speaking rate that is optimized to represent a normal rate of speech. The parameter accepts an integer that represents the percentage change from the voice's default:



* Specify a signed negative integer to reduce the speaking rate by that percentage. For example, -10 reduces the rate by ten percent.
* Specify an unsigned or signed positive integer to increase the speaking rate by that percentage. For example, 10 and +10 increase the rate by ten percent.
* Specify 0 or omit the parameter to get the default speaking rate for the voice.



The best way to determine how the parameter affects the rate of a given voice is to experiment with different values. Increase or decrease the rate incrementally, by five or ten percent, before trying more significant changes. When decreasing the rate, values less than -50 can begin to yield inadequate pronunciation. When increasing the rate, values greater than 100 might produce results that are not discernibly different from 100.

Table 1 provides examples of how the service changes the speaking rate with different values for the rate_percentage parameter. The examples use the en-US_AllisonV3Voice.



Table 1. Using the rate_percentage parameter

 Specification of the rate_percentage parameter Audio sample 

 rate_percentage=0 <br>The service uses the default speaking rate.
* 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. (With the WebSocket interface, setting the parameter can affect the latency and accuracy of the final results, regardless of whether you request interim results.)
* A shorter pause interval yields more final results, but because each segment of audio is smaller, transcription accuracy might not be as good. Smaller segments are acceptable when latency is crucial and transcription accuracy is not expected to degrade or any degradation is acceptable.

Also, a multi-phrase grammar recognizes, or matches, responses only within a single final result. If you use a grammar to recognize multiple strings, you can increase the pause interval to avoid receiving multiple final results.



Increase the interval when accuracy is more important than latency. Decrease the interval when the speaker is expected to say short phrases or single-word responses.

For previous-generation models, the service generates a final result for audio when an utterance reaches a two-minute maximum. The service splits a transcript into multiple final results after two minutes of continuous processing.



 End of phrase silence time example 

The following example requests show the effect of using the end_of_phrase_silence_time parameter. The audio speaks the phrase "one two three four five six," with a one-second pause between the words "three" and "four." The speaker might be reading a six-digit number from an identification card, for example, and pause to confirm the number.

The first example uses the default pause interval of 0.8 seconds:

IBM Cloud

curl -X POST -u "apikey:{apikey}" --header "Content-Type: audio/wav" --data-binary @{path}audio-file.wav "{url}/v1/recognize"

IBM Cloud Pak for Data
For more information about the next-generation models and about low latency, see [Next-generation languages and models](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-models-ng) and [Low latency](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-interimlow-latency).

Updates to beta Arabic and Brazilian Portuguese next-generation models for improved speech recognition
: The following existing beta next-generation language models have been updated for improved speech recognition:



* Arabic ar-MS_Telephony model
* Brazilian Portuguese pt-BR_Telephony model



For more information about the next-generation models and about low latency, see [Next-generation languages and models](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-models-ng) and [Low latency](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-interimlow-latency).





 26 May 2021 

New beta support for audio_metrics parameter for next-generation models
: The audio_metrics parameter is now supported as beta functionality for use with all next-generation languages and models. For more information, see [Audio metrics](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-metricsaudio-metrics).

New beta support for word_confidence parameter for next-generation models
: The word_confidence parameter is now supported as beta functionality for use with all next-generation languages and models. For more information, see [Word confidence](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-metadataword-confidence).

Defect fix: Update documentation for next-generation models
: Defect fix: The documentation has been updated to correct the following information:



* When you use a next-generation model for speech recognition, final transcription results now include the confidence field.
To set up logging alerts, see [Working with Alerts](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-alertsalerts)

For more information on features offered by IBM Cloud® Log Analysis, including integrating it with your other IBM Cloud services, see [its full documentation](https://cloud.ibm.com/docs/log-analysis).





 Internal Log Retention 

Database platform logs for all Cloud Databases deployments are kept internally for 30 days and then purged. If your Log Analysis plan is for a shorter period, logs are only accessible by you for the length of your plan. Regardless of the plan that you choose, all database logs are deleted after 30 days.
The best way to determine what works for your application is to make adjustments based on percentages and experiment with different values. Try incremental changes of five or ten percent before making more significant modifications.

<prosody rate="50">Set speaking rate to 50 words per minute</prosody>
<prosody rate="-5%">Decrease speaking rate by 5 percent</prosody>
<prosody rate="+5%">Increase speaking rate by 5 percent</prosody>
<prosody rate="slow">Decrease speaking rate by 25%</prosody>
<prosody rate="fast">Increase speaking rate by 25%</prosody>







 The <say-as> element 

The <say-as> element provides information about the type of text that is contained within the element and specifies the level of detail for rendering the text.



* The element has one required attribute, interpret-as, which indicates how the enclosed text is to be interpreted.
* The element has two optional attributes, format and detail, which are used only with particular values of the interpret-as attribute, as shown in the following examples.



The service supports the <say-as> element with the following languages:



* The service fully supports the <say-as> element for US English.
* For most other languages, the service supports only the digits and letters attributes of the element.
* For Japanese, the service supports only the digits attribute. The service ignores non-numeric characters that are included in the string of digits.



The service's default pronunciation of alphabetic, numeric, and alphanumeric strings varies by language, with each language having its own rules. You can use the <say-as> element to control how strings are pronounced, including whether they are to be spelled out as individual characters with the letters and digits elements.

For German, you can also control the pace at which the service pronounces the characters. For more information, see [Specifying how strings are spelled out](https://cloud.ibm.com/docs/text-to-speech?topic=text-to-speech-synthesis-paramsparams-spell-out-mode).
For information about pricing for the Plus and Standard plans, see the Speech to Text service in the [IBM Cloud® Catalog](https://cloud.ibm.com/catalog/speech-to-text).





 Do you round up to the nearest minute for every call to the API? 

IBM does not round up the length of the audio for every API call that the service receives. Instead, IBM aggregates all usage for the month and rounds to the nearest minute at the end of the month. For example, if you send two audio files that are each 30 seconds long, IBM sums the duration of the total audio for that month to one minute.





 Am I charged for all audio that I send, even audio that does not include speech? 

Yes, all audio that you send to the service contributes to your cumulative minutes of audio. This includes silence and noisy audio that does not contain or otherwise contribute to speech recognition. Because the service must process all audio that it receives, it does not distinguish between the type or quality of audio that you send. For pricing purposes, three seconds of silence is equivalent to three seconds of actual speech.





 What advantages do I get by using a Speech to Text Premium plan? 

The Premium plan offers developers and organizations all of the capabilities and features of the Plus plan. The plan also offers these additional features:



* The ability to use IBM Watson® services in the IBM Cloud® with data isolation and added security features such as IBM® Key Protect for IBM Cloud® (also referred to as Bring your own keys (BYOK)), Service Endpoints, Mutual Authentication, and US Health Insurance Portability and Accountability Act (HIPAA) readiness.
* Significantly greater capacity of up to 500 concurrent transcriptions with the option to add more, far above the limit of 100 concurrent transcriptions for the Plus plan.
* Your first 150,000 minutes of speech recognition each month at no charge.



To learn more or to make a purchase, [contact an IBM representative](https://ibm.biz/contact-wdc-premium).





 Can I provision a premium instance right now? 

No, you must first contact your IBM sales representative to purchase an entitlement and share your requirements.