54 lines
3.0 KiB
Markdown
54 lines
3.0 KiB
Markdown
# Research: LLM-based Desire Categorization
|
|
|
|
**Date**: 2025-10-11
|
|
**Feature**: Result Preparation Refactoring
|
|
|
|
## Objective
|
|
|
|
To design a prompt for the Google Gemini LLM that takes a list of user desires (categorized as "wants", "accepts", and "no-goes") and returns a categorized list of `Go-to`, `Also good`, `Considerable`, `No-goes`, and `Needs discussion` items.
|
|
|
|
## Research & Findings
|
|
|
|
The core of the refactoring is to create a robust prompt that can handle the complex logic of categorizing desires. The prompt needs to instruct the LLM to perform the following steps:
|
|
|
|
1. **Identify Unique Desires**: The first step is to identify the unique desires across all participants. The current `LLMService` already does this, and this logic can be reused.
|
|
2. **Categorize Desires**: The main challenge is to categorize the unique desires based on the rules defined in the specification.
|
|
|
|
### Prompt Design
|
|
|
|
The following prompt is designed to be sent to the Gemini model. It includes the logic for categorization and the expected JSON output format.
|
|
|
|
```prompt
|
|
You are an AI assistant that analyzes and categorizes user desires from a session. Given a list of desire sets from multiple participants, your task is to categorize them into the following groups: "Go-to", "Also good", "Considerable", "No-goes", and "Needs discussion".
|
|
|
|
Here are the rules for categorization:
|
|
- "Go-to": Items that ALL participants want.
|
|
- "Also good": Items that at least one participant wants, and all other participants accept.
|
|
- "Considerable": Items that are wanted or accepted by some, but not all, participants, and are not "No-goes" for anyone.
|
|
- "No-goes": Items that at least ONE participant does not want. These items must be excluded from all other categories.
|
|
- "Needs discussion": Items where there is a direct conflict (e.g., one participant wants it, another does not want it).
|
|
|
|
The input will be a JSON object containing a list of desire sets. Each desire set has a participantId and three arrays of strings: "wants", "accepts", and "noGoes".
|
|
|
|
The output should be a JSON object with the following structure:
|
|
{
|
|
"goTo": ["item1", "item2"],
|
|
"alsoGood": ["item3"],
|
|
"considerable": ["item4"],
|
|
"noGoes": ["item5"],
|
|
"needsDiscussion": ["item6"]
|
|
}
|
|
|
|
Here is the input data:
|
|
[INPUT_JSON]
|
|
```
|
|
|
|
### Decision
|
|
|
|
The `LLMService` will be updated to use this new prompt. The `analyzeDesires` method will be refactored to take the desire sets as input and return the categorized result in the specified JSON format. The existing desire grouping logic will be replaced.
|
|
|
|
### Alternatives Considered
|
|
|
|
- **Rule-based System**: A purely rule-based system could be implemented to categorize the desires. However, this would be very complex to implement and maintain, especially when dealing with the nuances of natural language. Using an LLM simplifies this process significantly.
|
|
- **Multi-step LLM Chain**: A more complex approach would be to use multiple LLM calls to first group the desires, then categorize them. However, a single, well-defined prompt is more efficient and less prone to errors.
|