vania-janet/multiturn-rag-retrieval-data huggingface dataset:
In the speaker fields, the first speaker has an ID of 2 and the second has an ID of 1. The service develops a better understanding of the speaker patterns as it processes the audio. Therefore, it can change speaker IDs for individual words, and can also add and remove speakers, until it generates its final results.

As a result, speaker IDs might not be sequential, contiguous, or ordered. For instance, IDs typically start at 0, but in the previous example the earliest ID is 1. The service likely omitted an earlier word assignment for speaker 0 based on further analysis of the audio. Omissions can happen for later speakers, as well. Omissions can result in gaps in the numbering and produce results for two speakers who are labeled, for example, 0 and 2. Another consideration is that speakers can leave a conversation. So a participant who contributes only to the early stages of a conversation might not appear in later results.





 Requesting interim results for speaker labels 

When you use speaker labels with interim results, the service duplicates the final speaker label object. For more information, see [Known limitations](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-known-limitationslimitation-interim-results).

With the WebSocket interface, you can request interim results as well as speaker labels (for more information, see [Interim results](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-interiminterim-results)). Final results are generally better than interim results. But interim results can help identify the evolution of a transcript and the assignment of speaker labels. Interim results can indicate where transient speakers and IDs appeared or disappeared. However, the service can reuse the IDs of speakers that it initially identifies and later reconsiders and omits. Therefore, an ID might refer to two different speakers in interim and final results.

When you request both interim results and speaker labels, final results for long audio streams might arrive well after initial interim results are returned. It is also possible for some interim results to include only a speaker_labels field without the results and result_index fields for the transcript as a whole.
x-watson-metadata (optional string)
: Associates a customer ID with all data that is passed over the connection. The parameter accepts the argument customer_id={id}, where id is a random or generic string that is to be associated with the data. You must URL-encode the argument to the parameter, for example, customer_id%3dmy_customer_ID. By default, no customer ID is associated with the data. For more information, see [Information security](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-information-security).

x-watson-learning-opt-out (optional boolean)
:
IBM Cloud

Indicates whether the service logs requests and results that are sent over the connection. To prevent IBM from accessing your data for general service improvements, specify true for the parameter. For more information, see [Request logging](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-data-securitydata-security-request-logging).

The following snippet of JavaScript code opens a connection with the service. The call to the /v1/recognize method passes the access_token and model query parameters, the latter to direct the service to use the Spanish broadband model. After it establishes the connection, the client defines the event listeners (onOpen, onClose, and so on) to respond to events from the service. The client can use the connection for multiple recognition requests.

var access_token = '{access_token}';
var wsURI = '{ws_url}/v1/recognize'
+ '?access_token=' + access_token
+ '&model=es-ES_BroadbandModel';
var websocket = new WebSocket(wsURI);

websocket.onopen = function(evt) { onOpen(evt) };
websocket.onclose = function(evt) { onClose(evt) };
Because we are using the stateless message method, the assistant does not store the context, so it is the responsibility of our client application to maintain it from one turn of the conversation to the next.

The context includes a session ID for each conversation, as well as a counter that is incremented with each turn of the conversation. The assistant updates the context and returns it with each response. But our previous version of the example did not preserve the context, so these updates were lost, and each round of input appeared to be the start of a new conversation. We can fix that by saving the context and sending it back to the assistant each time.

In addition to maintaining our place in the conversation, the context can also contain action variables that store any other data you want to pass back and forth between your application and the assistant. This can include persistent data you want to maintain throughout the conversation (such as a customer's name or account number), or any other data you want to track (such as the contents of a shopping cart or user preferences).



* Python
* Node



 Example 3: Preserves context to maintain state.

from ibm_watson import AssistantV2
from ibm_cloud_sdk_core.authenticators import IAMAuthenticator

 Create Assistant service object.
authenticator = IAMAuthenticator('{apikey}') replace with API key
assistant = AssistantV2(
version = '2021-11-27',
authenticator = authenticator
)
assistant.set_service_url('{url}') replace with service instance URL
assistant_id = '{environment_id}' replace with environment ID

 Initialize with empty message to start the conversation.
message_input = {
'message_type:': 'text',
'text': ''
}
context = {}

 Initialize with empty message to start the conversation.
message_input = {
'message_type:': 'text',
'text': ''
}
context = {}

 Main input/output loop
while message_input['text'] != 'quit':

 Send message to assistant.
However, the service can reuse the IDs of speakers that it initially identifies and later reconsiders and omits. Therefore, an ID might refer to two different speakers in interim and final results.

When you request both interim results and speaker labels, final results for long audio streams might arrive well after initial interim results are returned. It is also possible for some interim results to include only a speaker_labels field without the results and result_index fields for the transcript as a whole. If you do not request interim results, the service returns final results that include results and result_index fields and a single speaker_labels field.

With interim results, a final field with a value of false for a word in the speaker_labels field can indicate that the service is still processing the audio. The service might change its identification of the speaker or its confidence for individual words before it is done. The service sends final results when the audio stream is complete or in response to a timeout, whichever occurs first. The service sets the final field to true only for the last word of the speaker labels that it returns in either case.





 Performance considerations for speaker labels 

As noted previously, the speaker labels feature is optimized for two-person conversations, such as communications with a call center. Therefore, you need to consider the following potential performance issues:



* Performance for audio with a single speaker can be poor. Variations in audio quality or in the speaker's voice can cause the service to identify extra speakers who are not present. Such speakers are referred to as hallucinations.
* Similarly, performance for audio with a dominant speaker, such as a podcast, can be poor. The service tends to miss speakers who talk for shorter amounts of time, and it can also produce hallucinations.
* Performance for audio with more than six speakers is undefined. The feature can handle a maximum of six speakers.
* Performance for cross-talk, or speaker overlap, is poor. Cross-talk can be difficult or impossible to transcribe accurately for any audio.
* Performance for short utterances can be less accurate than for long utterances. The service produces better results when participants speak for longer amounts of time, at least 30 seconds per speaker.
Refer-To: sip:user@domain.com?User-to-User=dev::latest::893499::dff9c274-adc4-4f63-93de-781166760bf8::978f1fd7-4e24-47d8-adb0-24a8a6eff69e::b5ffd6c2-902f-4658-b586-e3fc170a6cf3::7ad616a350cc48078f17e3ee3df551de%3Bencoding%3Dascii
Contact: sip:a@atlanta.example.com
Content-Length: 0

If a custom User-to-User header is specified, then the session history key is set in the X-Watson-Assistant-Session-History-Key header.

REFER sip:b@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK2293940223
To: <sip:b@atlanta.example.com>
From: <sip:a@atlanta.example.com>;tag=193402342
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 93809823 REFER
Max-Forwards: 70
You can associate a customer ID with custom words by passing the X-Watson-Metadata header with the following methods. If necessary, you can then delete the data associated with the customer ID by using the DELETE /v1/user_data method.



* POST /v1/customizations/{customization_id}
* POST /v1/customizations/{customization_id}/words
* PUT /v1/customizations/{customization_id}/words/{word}



In addition, if you delete an instance of the Text to Speech service from the IBM Cloud console, all data associated with that service instance is automatically deleted. This includes all custom models and word/translation pairs. This data is purged automatically and regardless of whether a customer ID is associated with the data.

For more information, see [Information security](https://cloud.ibm.com/docs/text-to-speech?topic=text-to-speech-information-security).





 Request logging and data privacy 

IBM Cloud

How the service handles request logging for calls to the customization interface depends on the request:



* The service does not log data (words and translations) that are used to build custom models. You do not need to set the X-Watson-Learning-Opt-Out request header when using the customization interface to manage the words and translations in a custom model. Your training data is never used to improve the service's base models.
* The service does log data when a custom model is used with a synthesize request. You can opt out of request logging at the account level or by setting the X-Watson-Learning-Opt-Out request header to true.



For more information, see [Request logging](https://cloud.ibm.com/docs/text-to-speech?topic=text-to-speech-data-securitydata-security-request-logging).







 Creating a custom model 

To create a new custom model, use the POST /v1/customizations method. A new model is always empty when you first create it. You must use other methods to populate it with word/translation pairs.
id <br>Required <br>string The unique identifier for this resource group <br>Possible values: Value must match regular expression ^[0-9a-f]{32}$ <br>Example:56969d6043e9465c883cb9f7363e78e8 





 Example Request 

This example illustrates creating a transit gateway with the API:

curl -X POST --location --header "Authorization: Bearer
{iam_token}" --header "Accept: application/json" --header "Content-Type: application/json" --data '{ "location": "us-south", "name": "Transit_Service_BWTN_SJ_DL" }' "{base_url}/transit_gateways?version={version}"







 Response 

The following response shows once you initiate the request:



Table 2. Initiate response example

 Response Body Details 

 id <br>Always included <br>ID The unique identifier for this transit gateway <br>Example:ef4dcb1a-fee4-41c7-9e11-9cd99e65c1f4 
 crn <br>Always included <br>CRN The CRN for this transit gateway <br>Example:crn:v1:bluemix:public:transit:dal03:a/57a7d05f36894e3cb9b46a43556d903e::gateway:ef4dcb1a-fee4-41c7-9e11-9cd99e65c1f4 
 name <br>Always included <br>string A human readable name for the transit gateway <br>Possible values: 1 ≤ length ≤ 63, Value must match regular expression `^([a-zA-Z] 
 location <br>Always included <br>string Location of the transit gateway <br>Example:us-south 
 created_at <br>Always included <br>boolean Allow global routing for a transit gateway <br>Example:true 
 status <br>Always included <br>string The status of the transit gateway.
[Location](https://cloud.ibm.com/docs-content/v1/content/417db917d18067d9dcc4cf2612564a9a87c3ddc8/assistant/images/location.png) icon next to it.

If you are not already on the Dialog page, open it.

The source node is given focus and the route that your assistant traversed through the tree to get to it is highlighted. It remains highlighted until you perform another action, such as entering a new test input.
7. To check or set the value of a context variable, click the Manage context link.

Any context variables that you defined in the dialog are displayed.

In addition, the following context variables are listed:



* $timezone: The Try it out pane gets user locale information from the web browser and uses it to set the $timezone context variable. This context variable makes it easier to deal with time references in test dialog exchanges.
* $metadata: This context variable contains a user ID name and value pair. Because no user_id is specified by default in the Try it out pane, the conversation_id is used as the user_id value. At run time, the ID value is typically passed to the assistant from whatever integration you are using. If you design a custom application, you set this value yourself.



You can add a variable and set its value to see how the dialog responds in the next test dialog turn. This capability is helpful if, for example, the dialog is set up to show different responses based on a context variable value that is provided by the user.



1. To add a context variable, specify the variable name, and press Enter.
2. To define a default value for the context variable, find the context variable you added in the list, and then specify a value for it.



See [Context variables](https://cloud.ibm.com/docs/assistant?topic=assistant-dialog-runtime-context) for more information.
8. Continue to interact with the dialog to see how the conversation flows through it.
You can associate a customer ID with data that is added or updated for custom language and custom acoustic models. You associate a customer ID with corpora, custom words, grammars, and audio resources by passing the X-Watson-Metadata header with the following methods. If necessary, you can then delete the data by using the DELETE /v1/user_data method.



* POST /v1/customizations/{customization_id}/corpora/{corpus_name}
* POST /v1/customizations/{customization_id}/words
* PUT /v1/customizations/{customization_id}/words/{word_name}
* POST /v1/customizations/{customization_id}/grammars/{grammar_name}
* POST /v1/acoustic_customizations/{customization_id}/audio/{audio_name}



In addition, if you delete an instance of the Speech to Text service from the IBM Cloud console, all data associated with that service instance is automatically deleted. This includes all custom language models, corpora, grammars, and words, and all custom acoustic models and audio resources. This data is purged automatically and regardless of whether a customer ID is associated with the data.

For more information, see [Information security](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-information-security).





 Request logging and data privacy 

IBM Cloud

How the service handles request logging for calls to the customization interface depends on the request:



* The service does not log data that is used to build custom models. For example, when working with corpora and words in a custom language model, you do not need to set the X-Watson-Learning-Opt-Out request header. Your training data is never used to improve the service's base models.
* The service does log data when a custom model is used with a recognition request. You can opt out of request logging at the account level or by setting the X-Watson-Learning-Opt-Out request header to true.
* Fixed an issue with adding a jump-to from a conditional response in one node to a conditional response in another node.
* The page now responds better when you scroll horizontally to see multiple levels of child nodes.







 15 July 2020 

Support ended for @sys-location and @sys-person
: The person and location system entities, which were available as a beta feature in English dialog skills only, are no longer supported. You cannot enable them. If your dialog uses them, they are ignored by the service.

Use contextual entities to teach your skill to recognize the context in which such names are used. For more information about contextual entities, see [Annotation-based method](https://cloud.ibm.com/docs/assistant?topic=assistant-entitiesentities-annotations-overview).

For more information about how to use contextual entites to identify names of people, see the [Detecting Names And Locations With Watson Assistant](https://medium.com/ibm-watson/detecting-names-and-locations-with-watson-assistant-e3e1fa2a8427) blog post on Medium.

How legacy numeric system entities are processed has changed
: All new dialog skills use the new system entities automatically.

For existing skills that use legacy numeric system entities, how the entities are processed now differs based on the skill language.



* Arabic, Chinese, Korean, and Japanese dialog skills that use legacy numeric system entities function the same as before.
* If you choose to continue to use the legacy system entities in European-language dialog skills, a new legacy API format is used. The new legacy API format simulates the legacy system entities behavior. In particular, it returns a metadata object and does not stop the service from idenfifying multiple system entities for the same input string. In addition, it returns an interpretation object, which was introduced with the new version of system entities. Review the interpretation object to see the useful information that is returned by the new version.



Update your skills to use the new system entities from the Options>System Entities page.

Web chat security is generally available
* training data (/v1/environments/{environment_id}/collections/{collection_id}/training_data)



The following stored information is not explicitly labeled and cannot be deleted by specifying the customer_id. Personal Data is not supported in these fields.

Any string fields (including but not limited to name and description) of the following stored items:



* configurations
* collections
* environments







 Labeling data 

When ingesting documents, include the X-Watson-Metadata header using the POST /v1/environments/{environment_id}/collections/{collection_id}/documents or POST /v1/environments/{environment_id}/collections/{collection_id}/documents/ID operations. The customer_id field is added to the extracted_metadata of the documents. Your application must be configured to provide a customer_id in the X-Watson-Metadata header when performing any operation.

Optionally, you can include the customer_id field with the metadata multi-part form part instead of using the X-Watson-Metadata header.

If your documents are already ingested, you must reingest them to add the X-Watson-Metadata header and customer_id.

If you specify a customer_id in the metadata multi-part form part and the X-Watson-Metadata header for the same document, then the customer_id in the X-Watson-Metadata header is used.

Restrictions:



* The value of the X-Watson-Metadata header cannot exceed 4 kilobytes of text.
* The X-Watson-Metadata header must contain a semicolon separated list of field=value pairs. The field and value must not contain semicolons (;) or equals signs (=).
* customer_ids are unique within each Discovery instance. They are NOT unique per environment or collection.
* A customer_id cannot be more than 256 characters in length.
* If a customer_id contains only whitespace or is empty, it is treated as though the customer_id was not provided at all, and no error messages are returned.





 Labeling data with the Discovery tooling 

Data can be labeled with the customer_id field, when you use the Discovery tooling. Click the !
From the web browser location field, scroll to the end of the URL. Look for the collections/ section, and then copy the ID that is displayed after it. For example, in the URL /collections/5a525eb7-b175-3820-0000-017d00f0fcd1/activity, the collection ID is 5a525eb7-b175-3820-0000-017d00f0fcd1.)



* If the problem has to do with documents failing to load, provide the following information if known:



* What kind of documents are being uploaded (such as PDF, Json, CSV). Was optical character recognition (OCR) enabled for the collection?
* How were the documents loaded into the collection? (using the API, from the product UI, data source connector)
* Did you identify fields in the collection by using Smart Document Understanding? If so, what type of SDU model was applied to the collection (user-trained or pretrained)?
* What enrichments were applied to the collection?



* If the problem is related to a particular document (of a small set of documents), provide the document_id of the document, if known. You can share example documents if they might be helpful.
* If the problem is related to querying documents, describe the kind of query being used.
The full customer ID looks like this: customer_id=intercom_5c499e5535ddf5c7fa2d72b3.
* For Slack, the customer_id is the user_id prepended with slack_. The Slack user_id property is a concatenation of the team ID, such as T09LVDR7Y, and the member ID of the user, such has W4F8K9JNF. For example: T09LVDR7YW4F8K9JNF.



* To get the team ID, open the channel from a web browser. Open the web developer tools to view the console. Look for [BOOT] Initial team ID.
* You can copy the member ID from the user's Slack profile.
* To get the IDs programmatically, use the Slack API. For more information, see [Overview](https://api.slack.com/apis). The full customer ID looks like this: customer_id=slack_T09LVDR7YW4F8K9JNF.



* For the web chat integration, the service takes the user_id that is passed in and adds it as the customer_id parameter value to the X-Watson-Metadata header with each request.





 Before you begin 

To be able to delete message data associated with a specific user, you must first associate all messages with a unique customer ID for each user. To specify the customer ID for any messages sent using the /message API, include the X-Watson-Metadata: customer_id property in your header. For example:

curl -X POST -u "apikey:3Df... ...Y7Pc9"
--header
'Content-Type: application/json'
'X-Watson-Metadata: customer_id=abc'
--data
'{"input":{"text":"hello"}}'
'{url}/v2/assistants/{assistant_id}/sessions/{session_id}/message?version=2019-02-28'

where {url} is the appropriate URL for your instance.