A Negotiation-Aware Hybrid LLM Framework for Intent Interpretation and Service Discovery

• Classical composition methods assume structured, low-level, complete requests, unlike users’ high-level, incomplete, and potentially conflicting natural-language intents.Service composition combines autonomous services into a higher-value solution.Source: §1 · pp. 1–2
• Conflicts may violate cloud-paradigm limitations, reflect inconsistent user requirements, or arise when provider catalogs cannot satisfy a requirement.Examples include cross-region local L2 networking, automatic scaling with a fixed IP, and an unavailable database engine in a requested region.Source: §1 · p. 2
• The framework uses LLMs to refine and structure requests, deterministic catalog matching to verify exact compliance, and shared natural-language negotiation to resolve conflicts.The structured representation is a provider-independent TOSCA template; users select proposed relaxations.Source: §1 · pp. 2–3
• On 70 diverse natural-language requests, the framework improves recall and F1 for conflict detection and discovery, eliminates hallucinated offers, and relaxes constraints at cost proportional to conflict count.Source: §1 · p. 3

• Traditional composition assumes structured or semi-structured requests, while NLP and supervised-learning methods need large labeled datasets that limit use on unseen natural-language requests.Source: §2 · p. 3
• Directly prompted LLMs can miss implicit requirements, overlook conflicts, or hallucinate services; prior refinements address only part of the problem, while other relaxations lack user interaction or dynamic conflict handling.The paper’s approach covers functional and non-functional needs and resolves conflicts through iterative natural-language negotiation.Source: §2 · pp. 3–4
• Semantic matchmaking gives graded similarity, supervised discovery needs annotated data, and generation-based discovery can hallucinate or return noncompliant offers.Source: §2 · p. 4
• Retrieval-augmented discovery returns textually similar candidates rather than guaranteed-compliant offers, whereas deterministic catalog matching returns satisfying offers or identifies unsatisfiable requirements.Source: §2 · p. 4

• TOSCA is an OASIS standard for describing, deploying, and managing cloud applications independently of providers and technologies.Source: §3 · p. 4
• A TOSCA topology template represents application components as node templates, with node types defining properties, capabilities, and requirements.Templates can also specify policies for non-functional requirements such as placement, performance, and cost.Source: §3 · pp. 4–5
• The framework uses TOSCA for interpretation output, but an equivalent provider-independent abstraction language could serve the same role.Source: §3 · p. 5

• The framework automates the first two cloud-composition steps: request interpretation and service discovery.Source: §4 · p. 5
• Interpretation refines the request into a provider-independent TOSCA template, while deterministic matching finds catalog offers satisfying each service’s functional and non-functional requirements.Source: Figure 1 · p. 5
• When interpretation detects a conflict or discovery finds an unsatisfied requirement, a shared module proposes relaxations for the user to select, then retries matching.The user selects options rather than reformulating the request, validating offers, or editing the architecture.Source: Figure 1 · p. 5

5.1 Request Refinement and Conflict Detection

• Business needs are reformulated as measurable provider-independent services, and incomplete requests gain the components needed for a deployable architecture.Completion relies on normative TOSCA node types, properties, capabilities, and requirements rather than the model’s parametric TOSCA knowledge.Source: §5.1 · pp. 6–7
• After completion, an LLM detects cloud-paradigm and user-requirement conflicts, including incompatibilities that emerge only when implicit services and dependencies are explicit.Detected conflicts and the refined request proceed to relaxation; conflict-free requests proceed directly to structuring.Source: §5.1 · p. 7

5.2 Conflict Relaxation and User Negotiation

• For each detected conflict, a specialized LLM proposes minimal relaxation options that restore satisfiability while keeping changes to the original request small.Options are generated independently per conflict so resolving one does not interfere with another.Source: §5.2 · pp. 7–8
• Users select one option per conflict in a turn-based natural-language exchange, and the system reinterprets and rechecks the adjusted request until no conflict remains.All pending options are presented together in each turn.Source: §5.2 · p. 8

5.3 Request Structuring

• The final interpretation output is a provider-independent TOSCA template capturing the refined, conflict-free request.A dedicated structuring step uses TOSCA-derived knowledge to map services, properties, dependencies, and non-functional requirements into the template.Source: §5.3 · p. 8

6 Service Discovery

• Grounding matching in actual provider offerings avoids hallucinated offers, returns the complete satisfying candidate set, and handles service-name requirements that semantic matching misses.The matching phase uses no LLM, so it incurs neither token cost nor multiple-call overhead.Source: §6 · p. 9
• The algorithm groups nodes with identical requirements, searches catalogs organized by service type, and repeats matching after relaxation until every service has an offer or negotiation ends.Grouping ensures identical requirements are matched only once; catalogs can be updated independently by type.Source: §6 · p. 9
• The deterministic matcher filters catalog offers against every extracted functional and non-functional requirement, without falling back to a closest offer when none qualify.An empty candidate set produces the failed criteria as unsatisfiable requirements for relaxation and negotiation.Source: §6 · p. 9
• The algorithm runs in O(|G| · m · k) time and scales linearly with catalog size, where G is the requirement groups, m the largest catalog, and k the bounded criteria per requirement.Grouping bounds |G| by the number of TOSCA nodes.Source: §6 · pp. 9–10

Dataset

• 70 requests cover three request forms and conflict-free cases, cloud-paradigm violations, user-requirement inconsistencies, and catalog-unsatisfied discovery requirements.Conflict cases include near-miss controls and paired conflicts; the seven interpretation conflicts are unseen by the model because prompts list no concrete conflict.Source: Dataset · p. 10

Framework implementation

• The implementation uses mistral-large-2512 for all three LLM modules and searches catalogs containing 209 regionalized offers from AWS, Azure, and GCP.The six catalog service types correspond to normative TOSCA node types.Source: Framework implementation · p. 11
• Experiments run automatically, retaining each module’s minimal proposed relaxation to stay closest to the original request and to match baselines without user interaction.Conflict and relaxation ground truth is fixed, while offer ground truth is established per execution because candidates depend on user-applied relaxations.Source: Framework implementation · p. 11, Dataset · p. 11

Baselines

• The single-shot baseline prompts a model once to refine requests, detect conflicts, propose relaxations, and discover candidate offers from the shared catalogs.Four models span proprietary and open systems, including the framework’s Mistral-Large-2512 model.Source: Baselines · p. 11
• Enhanced-prompting baselines hold Mistral-Large-2512 fixed while adding chain-of-thought, self-refinement, retrieval grounding, or agentic reasoning and catalog inspection.These strategies isolate prompting effects from model choice.Source: Baselines · pp. 11–12

7.2 Evaluation Methodology

• Evaluation measures conflict-detection precision, recall, and F1; relaxation Recall@5; discovery precision, recall, and F1; hallucination rate; and computational cost.Recall@5 checks whether at least one admissible relaxation appears among the five proposed options.Source: §7.2 · p. 12

Quality analysis.

• Conflict detection records 89.3% recall and 79.0% F1 with 70.8% precision; refinement makes conflicts more explicit, especially interpretation conflicts.Source: Quality analysis · p. 12
• Discovery reaches 98.5% precision, 84.8% recall, and 91.1% F1 with no hallucination; relaxation Recall@5 is 83.3%, versus at most 73.2% for baselines.Source: Quality analysis · p. 13
• Generation-based baselines recover barely 60% of compliant offers and hallucinate up to 15.4%, while RAG avoids hallucinations but forgoes recall and precision.Source: Quality analysis · p. 13

Computational cost

• The cost analysis tracks input/output tokens and end-to-end latency by conflict count; two-conflict requests reach 47,294 tokens and 133.6 s as extra iterations accumulate.Source: Computational cost · p. 12, Figure 3 · p. 13

7.4 Ablation study

• Removing refinement reduces conflict-detection precision from 70.8% to 40.4% and discovery recall from 84.8% to 38.9%.Source: §7.4 · p. 14
• Without a completed architecture, the module mistakes missing elements in high-level requests for genuine conflicts.Source: §7.4 · p. 14
• Replacing deterministic matching with an LLM degrades all discovery metrics and introduces 5.6% hallucination, whereas deterministic matching produces none.Source: §7.4 · p. 14

8 Discussion and Conclusion

• The framework refines intents, detects conflicts, structures provider-independent TOSCA templates, retrieves compliant offers deterministically, and negotiates remaining conflicts with users.Source: §8 · p. 14
• Automatic evaluation retains minimal relaxations rather than involving real users, leaving relaxation clarity and user satisfaction unassessed; the dataset contains 70 requests and limited conflict types.Source: §8 · p. 14
• Discovery uses static catalogs of 209 offers from three providers, while interpretation, relaxation, and structuring depend on one LLM and results come from a single run without variance estimates.Source: §8 · p. 15
• Future work includes real-user validation, live-provider API discovery, multi-criteria service selection, and extension to the cloud–edge–IoT continuum.Source: §8 · p. 15