InfoItem

Overview

• InfoItem (information item) are similar to "variables" in programming languages. They are used to collect and store the information content provided by the user during the dialogue process (it can also store content unrelated to user input, or be used to exchange information with the system), and be referenced and used in subsequent dialogue nodes.
• InfoItems can be divided into the following categories based on the way they are generated:
  • User Input InfoItem: refers to InfoItems defined in the "#single_turn_interact#" or "#multi_turn_interact#" nodes. These InfoItems can be input by the user (AI questions and then the user's affirmation or denial is also considered user input / but it cannot be the content expressed independently by the AI). If the user refuses to answer, the InfoItem will be assigned the value None (only the InfoItems defined in "#single_turn_interact#" can be recognized by the system as a refusal to answer). At the same time, user input InfoItems can also be:
    • Assigned or referenced via ctx in "Python Script/Function" of the relevant node
    • The initial value is passed in through the startup infoitem of the "#start#" node (see the "startup_infoitem" attribute in "Node - #start#")
    • Is assigned by the return content of the "#activity#call_http" node (see "Node - #activity#call_http") The name of this type of InfoItem will enter the LLM prompt word, so its naming needs to comply with the following specifications.
  • Code Definition InfoItem: refers to InfoItems that have not been defined in the "#single_turn_interact#" or "#multi_turn_interact#" nodes, but are initially assigned through the three methods in the above "User Input InfoItems". The names of such InfoItems will not be included in the LLM prompt words, so their naming does not need to comply with the requirements of the following specifications; these InfoItems are generally used to assist information storage and calculation or logical judgment, and can be regarded as auxiliary "variables" in the entire dialogue session.
  • System InfoItem: refers to the InfoItems preset by the system. The system will automatically assign and use its value according to the execution situation. The code or script in the ChatTree can access it; the name of the system InfoItem is underlined at both ends and the outermost part is also enclosed in curly brackets. It can also be referenced through ctx in "Python Script/Function". Currently there are:
    • {_phone_number_}: str type, including incoming number and outgoing number, which is passed in when the real-time voice interaction application starts the ChatTree
    • {_user_gender_}: str type, "male" or "female", real-time voice interaction application calls intentchat_set_user_gender_age to set
    • {_user_age_group_}: str type, "children" or "young and middle-aged" or "elderly", real-time voice interaction application calls intentchat_set_user_gender_age to set
    • {_curr_node_exec_count_}: num type, automatically set by the system,
    • {_curr_user_input_}: str type, automatically set by the system
    • {_multi_turn_interact_exit_reason_}: str type, "#multi_turn_interact#" In the node's interaction loop, the system automatically sets or the script or function setting in the node's "execute_script" or "execute_function" attribute
    • {_multi_turn_interact_dynamic_prompt_}: str type, "#multi_turn_interact#" in the interaction loop of the node, the script or function setting in the "execute_script" or "execute_function" attribute of the node
    • {_reference_information_hit_content_}: str type, including hitted static and dynamic reference information, automatically set by the system
    • {_time_zone_}: num type, that is, GMT time zone, passed in when the ChatTree starts
• For more information about the value and usage of InfoItems, please refer to the description of ctx["{...}"] in "Python Script/Function"

Naming Specification Requirements and Constraints for User Input InfoItems

• 2 Expression Forms (applicable to different scenarios, if one does not work well, you can try another)
  • Questions without question marks and modal particles:
    • Such as: "Who...", "When...", "What type...", "Why...", "Whether...", "whether doing ...", "whether to do ...", "Is...", "...or..."
    • Use the "you" or "system_role" of the "#start#" node to refer to the AI ​​robot in the dialogue, and use the "user" or "user_role" of the "#start#" node to refer to the other party (i.e. the user) in the dialogue; be careful when using other pronouns that can cause confusion
  • Noun Phrase:
    • Such as: "Time of...", "Reason of...", "Place of...", "Amount of...", "Applicant of...", etc.
• Text Requirements:
  • Can only be "digits, uppercase and lowercase letters, single quotes, commas, underscores, hyphens, forward slashes and dot", and both ends must be enclosed in curly braces, such as "{......}"
  • There must be no spaces (the spaces between English words replaced by underscores "_"), otherwise the spaces will be ignored
• Accurately and completely express the contextual information related to the InfoItem, which can be the optimization of the InfoItem name itself, or the use of InfoItem constraints:
  • Add modifiers or scene information to the name of the InfoItem to qualify:
    • {age} can be optimized to {age_of_child}, or even further to {age_of_child_in_divorce_case}
    • {appointment_time} can be optimized to {experience_class_appointment_time}
    • {whether_ready_to_tell_both_parents_about_the_divorce} can be optimized to {whether_ready_to_tell_both_parents_about_the_divorce_if_have_not_said_before}
    • {specific_location} can be optimized to {specific_location_where_the_caller_is_currently_located}
    • {call_answering_time} can be optimized to {expected_call_answering_time}
    • {whether_the_divorce_has_been_negotiated} can be optimized to {whether_both_parties_have_negotiated_the_divorce}
    • Especially descriptive InfoItems such as {case_status}, {reason}, {result}, it is necessary to optimize the name of the InfoItem through modifiers, scene information, etc., to avoid extracting too broad a content and resulting in low accuracy.
  • InfoItem Constraint (see "Node - #single_turn_interact#" and "Node - #multi_turn_interact#") to carry out semantic or format requirements (the constraint description itself cannot contain characters such as "()(){}[]|"), and avoid ambiguity in information extraction through constraints:
    • {criminal_case_circumstances} can add constraint "non-traffic accident"
    • {name_of_the_policy_holder} can add constraint "must be the complete name, just Mr. and Ms. XX does not count"
    • {who_to_seek_legal_services_for} can add constraint "must be a specific person, cannot be a negative form"
    • {flight_date} can add the constraint "must be converted to YYYY-MM-DD format. If it cannot be converted, it will not be counted" (note that the constraint here cannot be "must be in YYYY-MM-DD format", which may cause the failure of InfoItem content extraction, the same below)
    • {housework_start_time} can add constraint "must be converted to HH:MM:SS format, 24-hour format, if it cannot be converted, it will not be counted"
    • {housework_duration} can add constraint "must be converted to HH:MM:SS format. For example, 03:03:22 represents a duration of 3 hours, 3 minutes and 22 seconds. If it cannot be converted, it will not be counted."
    • {days_of_the_week_to_do_housework} can add constraint "must be converted to a number form from 1 to 7, representing Monday to Sunday respectively. If there are multiple, separate them with commas. If they cannot be converted, they will not be counted."
    • {whether_housework_is_performed_every_week_or_every_few_weeks} can add constraint "If it is just 'calculated weekly', there are two possibilities, and there is no answer at this time"
    • {your_final_offer} can be constrained by "it must be the amount that you, the lawyer, have explicitly proposed or agreed to, and it must be the final numerical result"
    • {car_owner_phone_number} can add constraint "Only the number provided by the user after you ask for the 'car owner phone number', or the user clearly identifies it as the 'car owner phone number'" Note:
    • Spaces between words in the content of InfoItem constraint do not need to be replaced with underscores "_"
    • Some constraint were added after testing and it was found that the effect of information extraction was not good
  • Completeness also needs to take into account:
    • {injury_or_illness} in the 911 scene can be optimized to {injury_or_illness_or_physical_condition} and add the constraint "Asymptomatic is also considered"
  • No Ambiguity (in terms of expression and wording)
  • Be careful with negative or exclusive expressions, such as {not...}, {other...}
• The InfoItem name isn't necessarily better just because it's longer. Sometimes too much useless information will in turn affect the information extraction accuracy of LLM.
• The naming of different InfoItems should be clearly distinguished as much as possible
  • In a ChatTree (including subtrees that may be called), in different "#single_turn_interact#" and "#multi_turn_interact#" nodes, there cannot be InfoItems with the same name, or names with inclusive relationships, or similar meanings, such as:
    • {address} and {address_with_landmark_or_house_number}
    • {despatch_station} and {vehicle_despatch_station}
    • {whether_willing_to_participate_in_the_trial_class} and {whether_willing_to_participate_in_the_trial_class_after_being_guided_again}
    • {whether_user_will_participate_in_the_trial_class} and {can_user_participate_in_the_trial_class}
    • {Whether_willing_to_get_a_sales_quote} and {can_user_accept_a_car_insurance_quote} etc. should be avoided, otherwise it will cause confusion and produce wrong dialogue logic.
  • If the InfoItems of the two "#single_turn_interact#" nodes really need to have the same meaning, then:
    • Or the two nodes should be able to merge
    • Or let the two names be slightly different and do not include each other (such as {shipping_station_for_goods_inquiry} and {shipping_station_for_freight_inquiry}), and then either (1) one or both of these two InfoItems are set by the "fixed" InfoItem modifier, or (2) both are on different "#user_intent#" branches after the "#single_turn_interact#" node with the "topic" InfoItem modifier
• There must be absolutely no expression in the name of the InfoItem that requires LLM to "do" or "say" anything, such as {tell me...}, {help me...}, {give me...}, {say...}, {answer...}, etc.

Default Optional Values ​​for User Input InfoItems

• Only supported by Python ChatTree, not supported by Xmind ChatTree
• You can set the value of the InfoItem "InfoItem options" (a list whose elements are str / see "Node - #single_turn_interact#" and "Node - #multi_turn_interact#"), which means that the value of the InfoItem can only be (or should try to match) the (one or more) values listed in this option. At the same time, you can also use "InfoItem options modifier" (also a list with str elements) for precise control:
  • If "infoItem_options_modifier" contains "multi_select", it means that the value of the InfoItem can be one or more of the options (the multiple values ​​will be separated by "|" after extraction); if not, it means that the value of the InfoItem can only be at most one of the options (that is, the one with the highest matching degree, if it can be matched)
  • If "infoItem_options_modifier" contains "open_ended", it means that the value of the InfoItem may or may not be in the options; if not, it means that the value of the InfoItem must be in the options.
  • "multi_select" and "open_ended" can exist at the same time, each can exist separately, or neither can exist at all.
• In "ChatTree Examples" the "TMC_book_flights" and "hospital_registration" ChatTree examples have the two attributes "infoitem_options" and "infoitem_options_modifier"
• For example, "infoitem_options" is ["General Surgery", "ENT", "Internal Medicine"], if the user inputs "otolaryngology", it will be extracted as "ENT"; if the user inputs "Burn Department", no value will be extracted (if "infoItem_options_modifier" does not contain "open_ended") or it will be extracted as "Burn Department" (if "infoItem_options_modifier" contain "open_ended")
• When "infoitem_options_modifier" contains neither "multi_select" nor "open_ended", this situation is actually the same as the situation where there are several "#user_intent#" nodes behind the "#single_turn_interact" node, the intent in several "#user_intent#" nodes is equivalent to the InfoItem options.
• In the value of "infoitem_options", sometimes it is necessary to have a value that means "not limited" (meaning that all situations are acceptable when the value of InfoItem is used as a condition). For example, the InfoItem "{airline}", its "infoitem_options" is generally ["American Airlines", "Delta Air Lines", "United Airlines", ...]. If you want to add such a value, it cannot just be "not limited", but "not limited to airlines", that is, ["not limited to airlines", "American Airlines", "Delta Air Lines", "United Airlines", ...] (The situation is similar when there are several "#user_intent#" nodes behind the "#single_turn_interact#" node mentioned above, that is, a "#user_intent#" node with intent "not limited to airlines" needs to be added)

"Supporting" User Input InfoItems

Some InfoItems of "#single_turn_interact#" nodes need to have corresponding "supporting" InfoItems, such as:

• {injury_of_the_other_party_in_traffic_accident}, there needs to be a "supporting" InfoItem {whether_other_party_in_traffic_accident_was_injured}, then first ask "Is the other party injured?" and then "Where is the injury? Is it serious?", otherwise there will be problems if the user directly replies "Not injured"
• {other_content_that_needs_to_be_informed_in_divorce_case} requires a "supporting" InfoItem {does_anything_else_need_to_be_disclosedin_divorce_case}, then first ask "Do you have anything else to tell us?" and then "What else do you want to tell us?", otherwise there will be problems if the user directly replies "No more"

A user input may involve multiple User Input InfoItems

• User input "I discovered him last year, and he has been hiding and transferring property in various ways." Possible information extraction: {reason_for_divorce} = "I found out that the other party has been hiding and transferring property in various ways last year", {disputed_points_in_divorce} = "Property transfer", {property_status_of_divorce} = "The other party has been hiding and transferring property in various ways"

Assignment and Use of InfoItems

• Where InfoItems can be generated, modified, referenced and cleared:
  • "#single_tuen_interact#" node, "#multi_turn_interact#" node, based on user input
  • All Python scripts or functions (access or assignment of InfoItems based on the ctx object in the script or function), see "Python Script/Function" for details
  • "#start#" node, passed in by the initiator (including after executing the "#restart#" node to restart the entire dialogue)
  • "#activity#call_http" node, based on the returned result
  • "#activity#ask_again" node, "#activity#skip_asking" node, "#activity#clear_info" node
• Where macro replacement can be performed on the occurrence of InfoItems (InfoItems can be enclosed in square brackets or single quote, such as in "#condition#description", this can ensure the independence of the value of the replaced InfoItem in the final LLM prompt word):
  • "#single_turn_interact#" node's "system_question" attribute
  • "#single_turn_interact#" node's "inform_user_before_asking" attribute
  • "#single_turn_interact#" node's "structured_output_before_asking" attribute
  • The "response" part in the "response_scripts" attribute of the "#start#" node
  • "#inform_user#" node's "inform_content" attribute
  • "#structured_output#" node's "output_content" attribute
  • "#condition#description" node's "description" attribute
  • "#activity#call_http" node's "url" attribute