dolphinium
commited on
Commit
·
3a70c72
1
Parent(s):
7743fc6
pup: added possible user profiles(financial and scientific) to dimension and measure selection prompt. needs tests.
Browse files- llm_prompts.py +19 -19
llm_prompts.py
CHANGED
@@ -1,4 +1,3 @@
|
|
1 |
-
|
2 |
"""
|
3 |
Contains the prompt templates for interacting with the Gemini LLM.
|
4 |
|
@@ -45,9 +44,9 @@ An external API has identified the following field-value pairs from the user que
|
|
45 |
"""
|
46 |
|
47 |
return f"""
|
48 |
-
You are an expert
|
49 |
|
50 |
-
Your most important job is to
|
51 |
|
52 |
---
|
53 |
### CONTEXT & RULES
|
@@ -69,29 +68,30 @@ never add an additional filter by yourself like `total_deal_value_in_million:[0
|
|
69 |
---
|
70 |
### HOW TO CHOOSE THE ANALYSIS DIMENSION AND MEASURE (ANALYTICAL STRATEGY)
|
71 |
|
72 |
-
This is the most critical part of your task. A bad choice leads to a useless, boring analysis.
|
|
|
|
|
|
|
|
|
|
|
|
|
73 |
|
74 |
-
**
|
|
|
|
|
|
|
75 |
|
76 |
* **THE ANTI-REDUNDANCY RULE (MOST IMPORTANT):** If you use a field in the `query_filter` with a specific value (e.g., `news_type:"product approvals"`), you **MUST NOT** use that same field (`news_type`) as the `analysis_dimension`. The user already knows the news type; they want to know something *else* about it. Choosing a redundant dimension is a critical failure.
|
77 |
|
78 |
-
* **USER INTENT FIRST:** If the user explicitly asks to group by a field (e.g., "by company"
|
79 |
|
80 |
-
* **INFERENCE HEURISTICS (If the user doesn't specify a dimension):** Think "What is the next logical question
|
81 |
-
*
|
|
|
|
|
82 |
* If the query compares concepts like "cancer vs. infection," the dimension is `therapeutic_category`.
|
83 |
* If the query compares "oral vs. injection," the dimension is `route_branch`.
|
84 |
-
*
|
85 |
-
* if the query is about "recent deals about infection" the dimension should be `company_name_invested`. if we choose company_name as dimension, we got duplicate data. because this field contains
|
86 |
-
both investor and invested companies. So we need to use company_name_invested as dimension in this type of scenarios.
|
87 |
-
* Your goal is to find a dimension that reveals a meaningful pattern in the filtered data.
|
88 |
-
|
89 |
-
**2. Choosing the `analysis_measure` (The metric):**
|
90 |
-
|
91 |
-
* **EXPLICIT METRIC:** If the user asks for a value (e.g., "by total deal value," "highest revenue"), use the corresponding field and function (e.g., `sum(total_deal_value_in_million)`).
|
92 |
-
* **IMPLICIT VALUE vs. COUNT:**
|
93 |
-
* **Prioritize Financial Metrics for "Deals":** If the query is about "deals," "financings," or "partnerships," even if the user doesn't explicitly ask for a value (e.g., "show me recent deals"), you **MUST** default to a financial measure like `sum(total_deal_value_in_million)`. The user is always interested in the money behind the deal.
|
94 |
-
* **Use 'count' as a fallback:** For non-financial queries where no metric is specified (e.g., "what are the most common news types?"), 'count' is the appropriate measure.
|
95 |
---
|
96 |
### FIELD DEFINITIONS (Your Source of Truth for Core: {core_name})
|
97 |
|
|
|
|
|
1 |
"""
|
2 |
Contains the prompt templates for interacting with the Gemini LLM.
|
3 |
|
|
|
44 |
"""
|
45 |
|
46 |
return f"""
|
47 |
+
You are an expert financial and scientific analyst specializing in the pharmaceutical industry. Your task is to convert a natural language question into a structured JSON "Analysis Plan". This plan will be used to run two separate, efficient queries: one for aggregate data (facets) and one for finding illustrative examples (grouping).
|
48 |
|
49 |
+
Your most important job is to correctly infer the user's intent (are they a scientist or a financial analyst?) and choose an `analysis_dimension` and `analysis_measure` that provides a meaningful, non-obvious breakdown of the data for them.
|
50 |
|
51 |
---
|
52 |
### CONTEXT & RULES
|
|
|
68 |
---
|
69 |
### HOW TO CHOOSE THE ANALYSIS DIMENSION AND MEASURE (ANALYTICAL STRATEGY)
|
70 |
|
71 |
+
This is the most critical part of your task. A bad choice leads to a useless, boring analysis. You must first determine the user's persona and then select the analysis parameters accordingly.
|
72 |
+
|
73 |
+
**USER PERSONAS:**
|
74 |
+
* **The Financial Analyst:** This user cares about the money. They look for investments, acquisitions, deal values, and company financials. Their queries contain terms like "deal," "value," "acquisition," "financing," "investment," or "revenue."
|
75 |
+
* **The Scientific Analyst:** This user cares about the science. They look for product pipelines, clinical trial phases, therapeutic breakthroughs, and compound details. Their queries contain terms like "drug approvals," "phase 2," "therapeutic category," "compounds," "molecule," or "mechanism."
|
76 |
+
|
77 |
+
**1. Choosing the `analysis_measure` (The metric):**
|
78 |
|
79 |
+
* **Financial Intent (High Priority):** If the query mentions "deals," "financings," "partnerships," or financial value, the user's intent is financial. You **MUST** default to a financial measure like `sum(total_deal_value_in_million)`. The user is always interested in the money behind the deal, even if they don't explicitly ask for a dollar value.
|
80 |
+
* **Scientific Intent:** If the query is about scientific progress (e.g., "what are the most common news types?"), 'count' is the appropriate measure as a fallback when no specific value is requested.
|
81 |
+
|
82 |
+
**2. Choosing the `analysis_dimension` (The "Group By" field):**
|
83 |
|
84 |
* **THE ANTI-REDUNDANCY RULE (MOST IMPORTANT):** If you use a field in the `query_filter` with a specific value (e.g., `news_type:"product approvals"`), you **MUST NOT** use that same field (`news_type`) as the `analysis_dimension`. The user already knows the news type; they want to know something *else* about it. Choosing a redundant dimension is a critical failure.
|
85 |
|
86 |
+
* **USER INTENT FIRST:** If the user explicitly asks to group by a field (e.g., "by company," "by country"), use that field.
|
87 |
|
88 |
+
* **INFERENCE HEURISTICS (If the user doesn't specify a dimension):** Think "What is the next logical question for this user persona?"
|
89 |
+
* For a **Financial Analyst** asking about "top deals" or "recent financings," a good dimension is `company_name` (who is making deals?) or `news_type` (what kind of deals?). If the query is about "recent deals about infection," the dimension should be `company_name_invested`. Using `company_name` would pollute the data with both investor and invested companies.
|
90 |
+
* For a **Scientific Analyst** asking about "drug approvals," a good dimension is `therapeutic_category` (what diseases are the approvals for?) or `company_name` (who is getting the approvals?).
|
91 |
+
* For a **Scientific Analyst** asking about phase movements (e.g., "phase 2 to phase 3" or "phase 2 or phase 3"), a highly valuable dimension is `compound_name`. This reveals which specific compounds are progressing through the pipeline.
|
92 |
* If the query compares concepts like "cancer vs. infection," the dimension is `therapeutic_category`.
|
93 |
* If the query compares "oral vs. injection," the dimension is `route_branch`.
|
94 |
+
* Your goal is to find a dimension that reveals a meaningful pattern in the filtered data that is relevant to the user's likely persona.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
95 |
---
|
96 |
### FIELD DEFINITIONS (Your Source of Truth for Core: {core_name})
|
97 |
|