Wonkee Lee
2026.07.27
On-device Agentic AI: LG U+ ixi-O powered by EXAONE
As AI technology advances rapidly, the focal point of AI Transformation (AX) is expanding beyond high-performance cloud infrastructure to encompass personalized devices. This shift is driven by a move toward "on-device agentic AI," a paradigm in which complex, intelligent tasks are processed in real-time directly on the device, bypassing the need for massive central servers. The telecommunications industry, in particular, stands as a key domain for this innovation; given its close connection to everyday user experiences and the continuous generation and flow of vast amounts of data, the adoption of on-device AI promises the most tangible, immediate synergies and far-reaching impacts.
Mobile devices, in particular, serve as platforms that support real-time access to personal sensitive information and business communications. In this environment, LG AI Research and LG U+ have undertaken an advanced project to take telecommunications services to the next level. We enhanced the inference capabilities of LG U+’s AI assistant service, “ixi-O,” by integrating LG’s foundation model, “EXAONE,” into it.
This post aims to provide a detailed technical overview of the transition to on-device AI, which maximizes security and efficiency by overcoming the limitations of cloud-based architectures, as well as the advanced methodologies applied to our core services, “AI Call Analysis” and “AI Call Answering.”
To evolve ixi-O into a true on-device agent, this project defined three key tasks.
The first is the transition of the AI Call Analysis service to an on-device model. We migrated the call analysis pipeline, which had previously been operated using cloud-based large language models (LLMs), to an EXAONE-based system that runs on-device. This has significantly reduced our reliance on cloud servers, leading to dramatic savings in infrastructure costs, while also enhancing security by processing highly sensitive customer call data directly on the device.
The second task is to enhance the “AI Call Answering” service using a model-based approach. For this project, we transformed the existing system, which relied on standardized scripts and rules, into a conversational structure utilizing the on-device EXAONE LLM. The goal of this project was to go beyond having the AI simply repeat predefined phrases when the user is unable to answer a call, and instead enhance the system so that it can understand the caller’s intent and engage in flexible, natural conversations.
We focused on the final aspect: efficiency By training the system to handle all development tasks using a multi-task learning approach, we implemented a solution where a single model powers all services. This strategy was designed to minimize memory (RAM) usage while maximizing efficiency in future model maintenance, deployment, and operations.
This project was a joint effort between LG AI Research and LG U+, with LG AI Research handling modeling and data engineering, and LG U+ responsible for device optimization and service delivery. By dividing roles based on each company’s areas of expertise and collaborating closely, the two companies were able to carry out the project in a seamless and integrated manner.
1. EXAONE 4.0
Image 1. EXAONE 4.0 1.2B benchmark performance[1]
The EXAONE 4.0 1.2B lightweight model was selected as the base model for on-device serving. The primary technical reasons for choosing this model for the project are as follows:
-
Model size suitable for on-device deployment: The EXAONE 4.0 1.2B is a lightweight model designed with on-device applications in mind, featuring a size optimized for serving and performance on smartphones.
-
Superior performance for a lightweight model: Despite being a lightweight model with 1.2 billion parameters, it demonstrated superior performance on key benchmarks including knowledge reasoning, instruction following, and Korean language understanding when compared to other global lightweight models in its class.
-
Long-context and multilingual support: With support for long context lengths of up to 65K, it is well-suited for processing relatively long inputs, such as Speech-to-Text (STT)-based call scripts. Additionally, it is capable of understanding not only Korean but also multilingual inputs, including English and Spanish, making it highly applicable in real-world call environments.
2. LG U+ ixi-O
Image 2. Key ixi-O services
The goal of this project was to implement EXAONE on-device for ixi-O, LG U+’s AI assistant service, and to optimize the model’s performance to suit a real-world service environment.
ixi-O is a service that offers a variety of AI-powered calling experiences, including call recording and summarization, AI call answering, a visual calling interface, and voice phishing detection. For this project, we have identified two primary application areas: the AI Call Analysis service, which must understand the content of users’ calls and generate structured results, and the AI Call Answering service, which must identify the caller’s purpose through conversation and generate a response.
The first is AI Call Analysis. After a call ends, this service uses AI to analyze the conversation and summarize key points, enabling users to quickly grasp essential information. It also suggests necessary follow-up actions such as scheduling, tasks, or contacting others based on the call content, facilitating a seamless transition to post-call activities.
The second is AI Call Answering. This service allows AI to answer calls on the user's behalf and engage in real-time conversations with callers when the user is unable to pick up. The AI identifies the caller's purpose and records the conversation, enabling the user to review the details later and respond appropriately.
As both services operate based on actual call data, key requirements include privacy protection, low response latency, and stable inference performance on the device. Accordingly, this project focused on integrating EXAONE into an on-device environment to enable the processing of call data on the device itself, while enhancing Korean language understanding, summarization, conversational response, and information structuring capabilities tailored to the services’ objectives.
3. EXAONE-based ixi-O AI call analysis
Image 3. Training data generation pipeline
The core of AI Call Analysis lies in transforming unstructured call transcripts into structured information that users can immediately utilize. Once a call ends, the audio is converted to text via STT; based on this text, the model must summarize key content, extract important keywords and information, and generate follow-up actions such as scheduling appointments, initiating contact, or requesting confirmations. In other words, AI Call Analysis goes beyond simple summarization; it is a multifaceted task involving a combination of summarization, keyword extraction, entity extraction, and follow-up recommendations to achieve a comprehensive understanding of the call.
This task is far more challenging than typical document summarization or information extraction. Real-world conversations naturally contain colloquial expressions, incomplete sentences, repeated utterances, sentence breaks, overlapping speech between speakers, and abrupt topic shifts. Compounding these challenges are word misrecognition, missing sentence boundaries, and errors in recognizing numbers and proper nouns that occur during the STT conversion process. Therefore, the model must be able to accurately identify key information and generate consistent analysis results even from noisy call transcripts, rather than from refined text.
To enhance ixi-O’s AI call analysis service using the EXAONE platform and enable the effective execution of these call understanding tasks, this project established a pipeline as shown in Figure 3 that spans from data generation to model training. This pipeline is designed such that, upon receiving real call data or synthetic data as input, a high-performance Teacher Model generates call analysis labels such as summaries, key points, and follow-up actions. The generated results are then verified and refined through the Verification & Regeneration stage before ultimately being used to train the Student Model, EXAONE.
This project makes two key contributions. First, by generating synthetic data that reflects the conversation flows and expressions likely to occur in real-world call environments, we have ensured the data diversity and coverage necessary for training on-device models. In particular, since call analysis services use text converted via STT from real-world usage environments as input, we incorporated characteristics that can occur in real-call-based inputs such as colloquial expressions, sentence breaks, overlapping speech between speakers, and recognition errors into the synthetic data generation process.
Second, rather than using the labels generated by the Teacher Model as-is, we ensured label quality through a verification and regeneration process. While the Teacher Model generates call analysis results like summaries, key points, and follow-up actions based on the given call transcripts, there is a possibility that some results may be inaccurate or incomplete because the input text consists of call scripts that contain STT errors and colloquial language, rather than polished documents. To address this, we designed the system to verify the generated results item by item and regenerate any parts that contain errors or are missing, thereby increasing the reliability of the labels used for training the Student Model.
3.1. Synthetic Dialogue Generation
Image 4. Pipeline for generating synthetic dialogue
To address the challenge of securing sufficient real-world call-based training data, we built a synthetic dialogue generation pipeline that reflects the conversation flows and STT input characteristics found in actual calls. As shown in the figure, the synthetic dialogue generation process consists of three stages: Base Dialogue Generation → Utterance Diversification → Entity Replacement. In each stage, we utilized an LLM to generate and expand call scripts that closely resemble actual service inputs.
(1) Base Dialogue Generation.
In the first step, we define the fundamental parameters for conversation generation like topics, scenarios, key keywords, and major entities, and use them to generate a base call conversation. We structured the conversation conditions to naturally incorporate essential information required for call analysis, such as locations, phone numbers, schedules, and specific requests, while also reflecting characteristics common in real-world calls, such as colloquialisms, incomplete sentences, interrupted speech, and repetitions. Furthermore, acknowledging that the final service input consists of text converted via Speech-to-Text (STT), we provided the LLM with examples and noise patterns that simulate typical STT errors, including spacing mistakes, misrecognitions based on pronunciation, missing sentence boundaries, and ungrammatical phrasing. This approach enabled the generation of base conversations that closely resemble actual call transcripts rather than polished, formal documents.
(2) Utterance Diversification.
While the dialogues generated through Base Dialogue Generation have a clear scenario and information structure, some utterances may appear repetitive or follow formulaic patterns due to the nature of LLM generation. To mitigate this, we diversified the phrasing of the utterances while maintaining the same meaning. Specifically, we varied sentence length, tone, word order, level of colloquialism, and the directness of the utterances to ensure that multiple expressions could appear even in the same call scenario. For example, we rewrote a formulaic expression such as “Where are you now?” to vary depending on the situation and the speaker’s personality, such as “How far have you gotten?” or “Yo, have you arrived yet?” This approach prevented the model from overfitting to specific sentence patterns and enabled it to learn the diverse variations found in real-world user utterances.
(3) Entity Replacement.
Finally, we expanded the data coverage by replacing key entities in the conversations like place names, business names, dates, times, and phone numbers, with different values. Rather than simply changing the entity strings, we also modified the surrounding utterances to ensure that the replaced entities remained natural within the context of the conversation. For example, when changing a specific place name to another location or business name, we rearranged the entire conversation to ensure that the speaker’s location description, travel status, and response content did not conflict with the new entity. Through this process, we extended the same conversation structure to various real-world service scenarios and enriched the training data to ensure that the call analysis model was not biased toward specific entities or scenarios.
Using this synthetic conversation generation pipeline, we constructed a large-scale training dataset that reflects the conversation flow, utterance diversity, entity distribution, and STT error characteristics that may occur in real calls. In particular, rather than generating simple clean-text-based conversations, we generated data in the form of “Noisy STT Transcripts”, which closely resemble actual service inputs, to ensure more realistic call analysis performance during the subsequent Teacher Model-based label generation and Student Model training stages.
3.2. Verification & Regeneration
Image 5. Result verification and reproducibility pipeline
The initial call analysis results generated by the Teacher Model were not used directly as training labels; instead, their quality was refined through a separate verification and regeneration process. The overall workflow consists of [Conversation Content] → [Generation of Initial Call Analysis Results] → [Result Verification] → [Regeneration of Revised Results]. First, the Teacher Model generates initial results for each task, such as call summaries, key keywords, core content, and follow-up actions, based on the given call script. Subsequently, during the result verification stage, both the original conversation and the initially generated results were input into the LLM to verify, step by step, whether the generated results matched the original conversation, met the constraints for each task, and did not contain any missing, duplicate, or conflicting information.
During the validation phase, we verified the results from three main perspectives. First, fidelity to the source text. We checked whether the generated summaries, keywords, and follow-up actions were based on the actual conversation content and whether any new information not present in the conversation had been added. Second, compliance with task-specific formats and constraints. We verified that each result met the required format and constraints for each task. Third, consistency among the information. We checked whether there were any conflicting details among the summaries, keywords, and follow-up actions; whether the same information was unnecessarily repeated; and whether any important schedules, locations, contact information, or requests were omitted. In particular, since the input was an STT-based call transcript rather than a polished document, we took into account that the Teacher Model’s initial output might contain inaccuracies or omissions due to colloquial expressions, sentence breaks, repeated utterances, and STT recognition errors.
When errors were detected during verification, rather than simply discarding the entire set of results, we performed regeneration focused on the problematic items. During the regeneration phase, we fed the original dialogue, the initial generation results, and the feedback generated during the verification process into the LLM to ensure that the erroneous items were regenerated in the correct direction. Through this process, we removed content not based on the source text, supplemented missing key information, and generated final labels that conformed to the format and constraints of each task. Consequently, the Verification & Regeneration stage served as a quality control procedure designed to systematically reduce errors in the generated results while leveraging the Teacher Model’s generative capabilities, thereby enhancing the accuracy, consistency, and fidelity to the source text of the labels used to train the Student Model, EXAONE.
3.3. Experiments
To validate the performance of the advanced EXAONE model, we conducted a comparative evaluation against Gemini 2.0 Flash, the cloud model previously used in the existing ixi-O service. The comparison included Gemini 2.0 Flash, EXAONE 4.0 without synthetic data, and EXAONE 4.0 with the synthetic data and label quality improvement pipeline developed in this project.
The evaluation was conducted using the LLM-as-a-Judge method, with GPT-5.2 serving as the judge model. Based on a rubric reflecting the characteristics of each task, we conducted a 0–5-point Likert scale evaluation for each item and converted the scores to a 100-point scale. The actual evaluation included additional detailed criteria for each task; examples of key rubric items are shown in the table below.
| Task | Rubric | Description |
| Summary | Transaction (TX) Consistency | Is the summary based on the transaction? |
| Focus On Key Outcomes | Is the summary centered on the purpose and outcome of the call? | |
| Chronological Order | Evaluation of whether the summary maintains the chronological flow of the actual conversation | |
| Keyword Extraction | Category | Evaluation of whether conversation topics were classified into appropriate categories |
| Hallucination | Evaluation of whether keywords not present in the conversation were included | |
| Coverage | Evaluation of whether key topics were included without omission | |
| Task Recommendation | Evidence Grounding | Evaluation of whether the recommended follow-up tasks are based on the actual conversation content |
| Date Normalization | Evaluation of whether relative date expressions such as “tomorrow” and “next week” were converted into the correct actual dates. | |
| Deduplication | Evaluation of whether duplicate follow-up tasks have been created |
Figure 1. Example of an evaluation rubric
| Gemini-2.0-F | EXAONE4.0 (wo synthetic) |
EXAONE4.0 (w synthetic) |
|
| Summary | 46.8 | 45.2 | 76.8 |
| Keyword Extraction | 64.8 | 67.6 | 85.2 |
| Task Recommendation | 60.8 | 62.0 | 78.0 |
| Avg. | 57.4 | 58.2 | 80.0 |
Figure 2. Results of the AI call analysis experiment
4. EXAONE-based ixi-O AI call answering
Image 6. AI call answering based on task-oriented dialogues
AI Call Answering is a service that allows AI to answer calls on the user’s behalf when the user is unable to do so. The AI converses with the caller and, after the call, summarizes and conveys key details like the caller’s name, the purpose of the call, any additional messages, and whether the matter is urgent, so the user can quickly review the necessary information.
Existing services operated by responding to callers and collecting necessary information based on predetermined scenarios and rules. While this approach can function reliably in predictable situations, it has limitations when it comes to flexibly responding to the diverse expressions, unexpected responses, incomplete utterances, and shifts in conversation flow that occur in real phone conversations. In particular, a rule-based structure alone is insufficient for accurately discerning the caller’s intent, distinguishing between information that has already been collected and information that is still needed, and generating natural follow-up questions.
To address this, this project redefined the “AI Call Answering” feature as a task-oriented dialogue problem and designed tasks that allow EXAONE to generate the next response while tracking the conversation state. Specifically, the model is trained to extract slot information like the caller’s name, purpose of the call, additional messages, and whether the call is urgent, based on the caller’s utterance at each turn, classify the utterance’s intent, and generate the next system utterance that reflects the current state of the conversation. In other words, the goal was to create a structure that goes beyond simply generating natural sentences to accurately gather necessary information and terminate the conversation at the appropriate time.
Training such a model requires training data that includes a variety of caller responses and conversation flows. However, since there are limitations to acquiring large-scale data on incoming calls, as opposed to actual phone calls, this project built a machine-to-machine synthetic data generation pipeline. Using a User Simulator and a System Simulator, we automatically generated various caller scenarios and system responses, and based on these, we constructed training data that included slot extraction, intent classification, and next-response generation. Through this process, we enhanced EXAONE so that it can engage in more natural conversations in real-world service environments and accurately collect the necessary information.
4.1. Synthetic-data Generation
The model training data was structured by aligning the conversation history, state information, and the subsequent system response for each turn. Specifically, for a given dialogue turn *t*, the model input X_t consists of the conversation sequence up to the current point (ending with the user utterance), the history of system and user intents up to the previous turn, and the belief state accumulated and updated up to the current turn. Based on this, the model generates the intent of the current user utterance, the slot information (newly extracted or updated from that utterance), and the next system utterance .
In other words, the training data consists not merely of dialogue pairs, but is structured as a sequence that aligns the conversational context and cumulative state of each turn with the corresponding interpretation of the user’s utterance and the system’s subsequent response.
To reliably obtain this type of data, a variety of conversation scenarios and detailed labels for each turn are required. In real-life phone call situations, various conversation flows can occur: the caller may state their name first, state only the purpose of the call, clearly indicate whether the matter is urgent, provide a response unrelated to the question, or remain silent or give an incomplete answer. Therefore, we need conversation data that includes not only major normal flows but also exceptional and atypical flows. To this end, we systematically defined the possible combinations of conversation flows and built a machine-to-machine synthetic data generation pipeline.
4.1.1. Dialogue Flow
Image 7. Dialogue Flowchart
Image 8. Dialogue Finite State Machine Diagram
AI Call Answering is designed to engage in natural conversation with the caller, but it follows predefined conversation scenarios to reliably gather the information that needs to be conveyed to the recipient. The overall flow can be illustrated as shown in the figure. The system first greets the caller, informs them that the recipient is unavailable, and asks the caller about the purpose of the call. Depending on the caller’s response, if the purpose is clearly confirmed, the system proceeds to the information collection or termination stage; if the purpose is unclear or the response is insufficient, the system asks for the purpose again. Conversely, the system is designed to terminate the conversation if inappropriate responses such as spam, profanity, or requests for personal information are detected, or if attempts to confirm the purpose fail repeatedly.
This conversation flow can be abstracted into a Finite State Machine (FSM) by setting the System Intent as the state and the User Intent as the state transition condition. Converting a flowchart into an FSM in this manner allows the dialogue policy to be expressed through explicit state transition rules and enables the consistent generation of the necessary Intent, Slot, Belief State, and System Utterance labels for each turn.
FSM-based definitions are used to systematically map out the scenario space for generating synthetic data. By tracing the possible User Intents in each State and the corresponding subsequent System Intents, and then flattening all possible transition paths, it is possible to automatically generate the diverse dialogue scenarios required for model training. In this project, we identified a total of 61 unique dialogue scenarios in the System → User → System → User format, under the condition that a maximum of one Followup_request—corresponding to a request for clarification—is allowed. For example, a conversation scenario like
| greeting_request → provide_info:no_purpose → followup_request → provide_info:call_purpose → final_check_close → additional_msg → close_call |
refers to a situation where the caller does not initially state a clear purpose but provides the reason for the call after a follow-up request, leaves an additional message, and then concludes the call.
4.1.2. Machine-to-Machine
Image 9. Machine-to-machine-based synthetic data generation
Based on the previously defined FSM-based dialogue flow, each synthetic dialogue begins with the selection of a specific transition path. This selected path dictates the sequence of system and user intents that must occur within the dialogue. For instance, if a path such as greeting_request → provide_info/no_purpose → followup_request → provide_info/call_purpose → final_check_close → additional_info → close_call is chosen, the subsequent simulation proceeds according to this flow. This approach ensures that the synthetic data is not generated randomly but is instead created in a manner that adheres to predefined dialogue policies and transition conditions.
Dialogue generation was performed using a machine-to-machine approach that employs two LLMs. One LLM acts as a User Simulator, which plays the role of the sender and generates user utterances appropriate for a given user intent. For example, if the current intent is “provide_info/call_purpose”, it generates an utterance that reveals the purpose of the call; if the intent is “provide_info/no_purpose”, it is instructed to generate a response indicating that the purpose is unclear or incomplete. The other LLM acts as the System Simulator. It takes the conversation history to date, previous intent history, and the current belief state as input to interpret the intent and slots of the current user utterance, and then generates the next system utterance based on the updated state. This is structured in the same way as the input-output structure of the training data defined in Section 5.1.
The two simulators exchange dialogue turn by turn according to the selected dialogue flow, recording the information necessary for training in each turn. Specifically, for each turn, they collect the dialogue history, user intent, current belief state, next system intent, and next system utterance, and organize this data into a single training instance. Through this process, the system can automatically generate data that not only includes simple dialogue sentences but also aligns state changes for each turn with Intent/Slot labels and the subsequent system response. Consequently, the FSM controls the possible dialogue flows, while the machine-to-machine simulation generates various natural language utterances and labels for each flow.
4.1. Synthetic-data Generation4.1.1. Dialogue Flow
| Metric | EXAONE (wo. synth data) | EXAONE (w. synth data) |
| Intent (acc) | 67.00 | 100.0 (+34) |
| Slot (EM) | 30.51 | 73.40 (+42) |
| Slot (Fuzzy) | 37.29 | 84.57 (+47) |
| JGA (EM) | 40.00 | 88.16 (+48) |
| JGA (Fuzzy) | 43.00 | 92.89 (+49) |
| Utterance (Rouge-1) | 38.40 | 81.06 (+43) |
Figure 3. Quantitative evaluation results for AI Call Answering
4.1.2. Qualitative Evaluation
| Evaluation items | Description |
| Intent Classification | Was the purpose of the call accurately identified and classified? |
| Information Extraction (Accuracy) | Were key details like the caller's identity and the reason for the call gathered without omission? |
| Guardrails | Were personal data protection guidelines followed regarding issues like phishing and spam? |
| Conversational Naturalness | Were appropriate sentences generated that fit the context? |
Figure 4. Qualitative evaluation criteria
Image 10. Qualitative evaluation results
5. Conclusion