gavindiaz/NexQuant
1
0
Fork 0
mirror of https://github.com/NicolasBohn/NexQuant.git synced 2026-07-27 15:37:44 +00:00
Code Issues Packages Projects Releases Wiki Activity

feat: EURUSD FX patches - prompts, factor spec, experiment settings

Browse Source
This commit is contained in:
TPTBusiness
2026-03-22 21:21:07 +01:00
parent 30c0a9166e
commit b6cf6874db
4 changed files with 736 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
patches/factor_proposal.py
+132
View File
@@ -0,0 +1,132 @@
import json
from typing import List, Tuple
from rdagent.components.coder.factor_coder.factor import FactorExperiment, FactorTask
from rdagent.components.proposal import FactorHypothesis2Experiment, FactorHypothesisGen
from rdagent.core.proposal import Hypothesis, Scenario, Trace
from rdagent.scenarios.qlib.experiment.factor_experiment import QlibFactorExperiment
from rdagent.scenarios.qlib.experiment.model_experiment import QlibModelExperiment
from rdagent.scenarios.qlib.experiment.quant_experiment import QlibQuantScenario
from rdagent.utils.agent.tpl import T
QlibFactorHypothesis = Hypothesis
class QlibFactorHypothesisGen(FactorHypothesisGen):
def __init__(self, scen: Scenario) -> Tuple[dict, bool]:
super().__init__(scen)
def prepare_context(self, trace: Trace) -> Tuple[dict, bool]:
hypothesis_and_feedback = (
T("scenarios.qlib.prompts:hypothesis_and_feedback").r(
trace=trace,
)
if len(trace.hist) > 0
else "No previous hypothesis and feedback available since it's the first round."
)
last_hypothesis_and_feedback = (
T("scenarios.qlib.prompts:last_hypothesis_and_feedback").r(
experiment=trace.hist[-1][0], feedback=trace.hist[-1][1]
)
if len(trace.hist) > 0
else "No previous hypothesis and feedback available since it's the first round."
)
context_dict = {
"hypothesis_and_feedback": hypothesis_and_feedback,
"last_hypothesis_and_feedback": last_hypothesis_and_feedback,
"RAG": (
"Try EURUSD-specific FX factors: momentum (4-32 bars), mean reversion, ATR volatility, volume spikes, session-based signals. Use only $open $close $high $low $volume columns. No $factor column exists."
if len(trace.hist) < 15
else "Now, you need to try factors that can achieve high IC (e.g., machine learning-based factors)."
),
"hypothesis_output_format": T("scenarios.qlib.prompts:factor_hypothesis_output_format").r(),
"hypothesis_specification": T("scenarios.qlib.prompts:factor_hypothesis_specification").r(),
}
return context_dict, True
def convert_response(self, response: str) -> Hypothesis:
response_dict = json.loads(response)
hypothesis = QlibFactorHypothesis(
hypothesis=response_dict.get("hypothesis"),
reason=response_dict.get("reason"),
concise_reason=response_dict.get("concise_reason"),
concise_observation=response_dict.get("concise_observation"),
concise_justification=response_dict.get("concise_justification"),
concise_knowledge=response_dict.get("concise_knowledge"),
)
return hypothesis
class QlibFactorHypothesis2Experiment(FactorHypothesis2Experiment):
def prepare_context(self, hypothesis: Hypothesis, trace: Trace) -> Tuple[dict | bool]:
if isinstance(trace.scen, QlibQuantScenario):
scenario = trace.scen.get_scenario_all_desc(action="factor")
else:
scenario = trace.scen.get_scenario_all_desc()
experiment_output_format = T("scenarios.qlib.prompts:factor_experiment_output_format").r()
if len(trace.hist) == 0:
hypothesis_and_feedback = "No previous hypothesis and feedback available since it's the first round."
else:
specific_trace = Trace(trace.scen)
for i in range(len(trace.hist) - 1, -1, -1):
if not hasattr(trace.hist[i][0].hypothesis, "action") or trace.hist[i][0].hypothesis.action == "factor":
specific_trace.hist.insert(0, trace.hist[i])
if len(specific_trace.hist) > 0:
specific_trace.hist.reverse()
hypothesis_and_feedback = T("scenarios.qlib.prompts:hypothesis_and_feedback").r(
trace=specific_trace,
)
else:
hypothesis_and_feedback = "No previous hypothesis and feedback available."
return {
"target_hypothesis": str(hypothesis),
"scenario": scenario,
"hypothesis_and_feedback": hypothesis_and_feedback,
"experiment_output_format": experiment_output_format,
"target_list": [],
"RAG": None,
}, True
def convert_response(self, response: str, hypothesis: Hypothesis, trace: Trace) -> FactorExperiment:
response_dict = json.loads(response)
tasks = []
for factor_name in response_dict:
description = response_dict[factor_name]["description"]
formulation = response_dict[factor_name]["formulation"]
variables = response_dict[factor_name]["variables"]
tasks.append(
FactorTask(
factor_name=factor_name,
factor_description=description,
factor_formulation=formulation,
variables=variables,
)
)
exp = QlibFactorExperiment(tasks, hypothesis=hypothesis)
exp.based_experiments = [QlibFactorExperiment(sub_tasks=[])] + [
t[0] for t in trace.hist if t[1] and isinstance(t[0], FactorExperiment)
]
unique_tasks = []
for task in tasks:
duplicate = False
for based_exp in exp.based_experiments:
if isinstance(based_exp, QlibModelExperiment):
continue
for sub_task in based_exp.sub_tasks:
if task.factor_name == sub_task.factor_name:
duplicate = True
break
if duplicate:
break
if not duplicate:
unique_tasks.append(task)
exp.tasks = unique_tasks
return exp
patches/qlib_experiment_prompts.yaml
+271
View File
@@ -0,0 +1,271 @@
qlib_quant_background: |-
Quantitative investment is a data-driven approach to asset management that relies on mathematical models, statistical techniques, and computational methods to analyze financial markets and make investment decisions. Two essential components of this approach are factors and models.
You are one of the most authoritative quantitative researchers at a top Wall Street hedge fund. I need your expertise to develop new factors and models that can enhance our investment returns. Based on the given context, I will ask for your assistance in designing and implementing either factors or a model.
{% if runtime_environment is not none %}
====== Runtime Environment ======
You have following environment to run the code:
{{ runtime_environment }}
{% endif %}
qlib_factor_background: |-
You are developing alpha factors for EURUSD intraday trading using 15-minute OHLCV bars.
Each number in the factor represents a value for the EURUSD instrument at a specific 15min bar.
A model will be trained to predict the next several bars return based on the factor values of previous bars.
**Critical constraints:**
- Available columns: $open, $close, $high, $low, $volume ONLY
- NO $factor column exists — never reference it
- Each "instrument" is EURUSD, each "day" is a 15min bar
- Lookback in bars: 4=1h, 8=2h, 16=4h, 32=8h, 96=1day
**FX Market knowledge:**
- London session (08:00-16:00 UTC) = trending, momentum works
- Asian session (00:00-08:00 UTC) = ranging, mean reversion works
- London-NY overlap (13:00-16:00 UTC) = highest volume and volatility
- Spread cost ~1.5 bps — avoid factors generating excessive trades
The factor is defined in the following parts:
1. Name: The name of the factor.
2. Description: The description of the factor.
3. Formulation: The formulation of the factor.
4. Variables: The variables or functions used in the formulation of the factor.
Please specifically give all hyperparameters like window size, lookback period. One factor defines one output. For example, 4-bar momentum and 16-bar momentum are two different factors.
{% if runtime_environment is not none %}
====== Runtime Environment ======
You have following environment to run the code:
{{ runtime_environment }}
{% endif %}
qlib_factor_interface: |-
Your python code should follow the interface to better interact with the user's system.
Your python code should contain the following part: the import part, the function part, and the main part. You should write a main function name: "calculate_{function_name}" and call this function in "if __name__ == __main__" part. Don't write any try-except block in your python code. The user will catch the exception message and provide the feedback to you.
User will write your python code into a python file and execute the file directly with "python {your_file_name}.py". You should calculate the factor values and save the result into a HDF5(H5) file named "result.h5" in the same directory as your python file. The result file is a HDF5(H5) file containing a pandas dataframe. The index of the dataframe is the "datetime" and "instrument", and the single column name is the factor name,and the value is the factor value. The result file should be saved in the same directory as your python file.
qlib_factor_strategy: |-
Ensure that for every step of data processing, the data format (including indexes) is clearly explained through comments.
Each transformation or calculation should be accompanied by a detailed description of how the data is structured, especially focusing on key aspects like whether the data has multi-level indexing, how to access specific columns or index levels, and any operations that affect the data shape (e.g., `reset_index()`, `groupby()`, `merge()`).
This step-by-step explanation will ensure clarity and accuracy in data handling. For example:
1. **Start with multi-level index**:
```python
# The initial DataFrame has a multi-level index with 'datetime' and 'instrument'.
# To access the 'datetime' index, use df.index.get_level_values('datetime').
datetime_values = df.index.get_level_values('datetime')
```
2. **Reset the index if necessary**:
```python
# Resetting the index to move 'datetime' and 'instrument' from the index to columns.
# This operation flattens the multi-index structure.
df = df.reset_index()
```
3. **Perform groupby operations**:
```python
# Grouping by 'datetime' and 'instrument' to aggregate the data.
# After groupby, the result will maintain 'datetime' and 'instrument' as a multi-level index.
df_grouped = df.groupby(['datetime', 'instrument']).sum()
```
4. **Ensure consistent datetime formats**:
```python
# Before merging, ensure that the 'datetime' column in both DataFrames is of the same format.
# Convert to datetime format if necessary.
df['datetime'] = pd.to_datetime(df['datetime'])
other_df['datetime'] = pd.to_datetime(other_df['datetime'])
```
5. **Merge operations**:
```python
# When merging DataFrames, ensure you are merging on both 'datetime' and 'instrument'.
# If these are part of the index, reset the index before merging.
merged_df = pd.merge(df, other_df, on=['datetime', 'instrument'], how='inner')
```
qlib_factor_output_format: |-
Your output should be a pandas dataframe similar to the following example information:
<class 'pandas.core.frame.DataFrame'>
MultiIndex: 40914 entries, (Timestamp('2020-01-02 00:00:00'), 'SH600000') to (Timestamp('2021-12-31 00:00:00'), 'SZ300059')
Data columns (total 1 columns):
# Column Non-Null Count Dtype
--- ------ -------------- -----
0 your factor name 40914 non-null float64
dtypes: float64(1)
memory usage: <ignore>
Notice: The non-null count is OK to be different to the total number of entries since some instruments may not have the factor value on some days.
One possible format of `result.h5` may be like following:
datetime instrument
2020-01-02 SZ000001 -0.001796
SZ000166 0.005780
SZ000686 0.004228
SZ000712 0.001298
SZ000728 0.005330
...
2021-12-31 SZ000750 0.000000
SZ000776 0.002459
qlib_factor_simulator: |-
The factors will be sent into Qlib to train a model to predict the next several days return based on the factor values of the previous days.
Qlib is an AI-oriented quantitative investment platform that aims to realize the potential, empower research, and create value using AI technologies in quantitative investment, from exploring ideas to implementing productions. Qlib supports diverse machine learning modeling paradigms. including supervised learning, market dynamics modeling, and RL.
User will use Qlib to automatically do the following things:
1. generate a new factor table based on the factor values.
2. train a model like LightGBM, CatBoost, LSTM or simple PyTorch model to predict the next several days return based on the factor values.
3. build a portfolio based on the predicted return based on a strategy.
4. evaluate the portfolio's performance including the return, sharpe ratio, max drawdown, and so on.
qlib_factor_rich_style_description : |-
### R&D Agent-Qlib: Automated Quantitative Trading & Iterative Factors Evolution Demo
#### [Overview](#_summary)
The demo showcases the iterative process of hypothesis generation, knowledge construction, and decision-making. It highlights how financial factors evolve through continuous feedback and refinement.
#### [Automated R&D](#_rdloops)
- **[R (Research)](#_research)**
- Iterative development of ideas and hypotheses.
- Continuous learning and knowledge construction.
- **[D (Development)](#_development)**
- Progressive implementation and code generation of factors.
- Automated testing and validation of financial factors.
#### [Objective](#_summary)
To demonstrate the dynamic evolution of financial factors through the Qlib platform, emphasizing how each iteration enhances the accuracy and reliability of the resulting financial factors.
qlib_factor_from_report_rich_style_description : |-
### R&D Agent-Qlib: Automated Quantitative Trading & Factor Extraction from Financial Reports Demo
#### [Overview](#_summary)
This demo showcases the process of extracting factors from financial research reports, implementing these factors, and analyzing their performance through Qlib backtest, continually expanding and refining the factor library.
#### [Automated R&D](#_rdloops)
- **[R (Research)](#_research)**
- Iterative development of ideas and hypotheses from financial reports.
- Continuous learning and knowledge construction.
- **[D (Development)](#_development)**
- Progressive factor extraction and code generation.
- Automated implementation and testing of financial factors.
#### [Objective](#_summary)
<table border="1" style="width:100%; border-collapse: collapse;">
<tr>
<td>💡 <strong>Innovation </strong></td>
<td>Tool to quickly extract and test factors from research reports.</td>
</tr>
<tr>
<td>⚡ <strong>Efficiency </strong></td>
<td>Rapid identification of valuable factors from numerous reports.</td>
</tr>
<tr>
<td>🗃️ <strong>Outputs </strong></td>
<td>Expand and refine the factor library to support further research.</td>
</tr>
</table>
qlib_factor_experiment_setting: |-
| Dataset 📊 | Model 🤖 | Factors 🌟 | Data Split 🧮 |
|---------|----------|---------------|-------------------------------------------------|
| EURUSD 15min | LGBModel | FX Factors | Train: 2022-03-14 to 2024-06-30 <br> Valid: 2024-07-01 to 2024-12-31 <br> Test: 2025-01-01 to 2026-03-20 |
qlib_model_background: |-
The model is a machine learning or deep learning structure used in quantitative investment to predict the returns and risks of a portfolio or a single asset. Models are employed by investors to generate forecasts based on historical data and identified factors, which are central to many quantitative investment strategies.
Each model takes the factors as input and predicts the future returns. Usually, the bigger the model is, the better the performance would be.
The model is defined in the following parts:
1. Name: The name of the model.
2. Description: The description of the model.
3. Architecture: The detailed architecture of the model, such as neural network layers or tree structures.
4. Hyperparameters: The hyperparameters used in the model.
5. Training_hyperparameters: The hyperparameters used during the training process.
6. ModelType: The type of the model, "Tabular" for tabular model and "TimeSeries" for time series model.
The model should provide clear and detailed documentation of its architecture and hyperparameters. One model should statically define one output with a fixed architecture and hyperparameters.
{% if runtime_environment is not none %}
====== Runtime Environment ======
You have following environment to run the code:
{{ runtime_environment }}
{% endif %}
qlib_model_interface: |-
Your python code should follow the interface to better interact with the user's system.
You code should contain several parts:
1. The import part: import the necessary libraries.
2. A class which is a sub-class of pytorch.nn.Module. This class should should have a init function and a forward function which inputs a tensor and outputs a tensor.
3. Set a variable called "model_cls" to the class you defined.
The user will save your code into a python file called "model.py". Then the user imports model_cls in file "model.py" after setting the cwd into the directory:
```python
from model import model_cls
```
So your python code should follow the pattern:
```python
class XXXModel(torch.nn.Module):
...
model_cls = XXXModel
```
The model can be configured as either "Tabular" for tabular models or "TimeSeries" for time series models. For a tabular model, the input shape is (batch_size, num_features), while for a time series model, the input shape is (batch_size, num_timesteps, num_features). In both cases, the output shape of the model should be (batch_size, 1).
`num_features` will be directly set for the model based on the input data shape.
User will initialize the tabular model with the following code:
```python
model = model_cls(num_features=num_features)
```
User will initialize the time series model with the following code:
```python
model = model_cls(num_features=num_features, num_timesteps=num_timesteps)
```
No other parameters will be passed to the model so give other parameters a default value or just make them static.
Don't write any try-except block in your python code. The user will catch the exception message and provide the feedback to you. Also, don't write main function in your python code. The user will call the forward method in the model_cls to get the output tensor.
Please notice that your model should only use current features as input. The user will provide the input tensor to the model's forward function.
qlib_model_output_format: |-
Your output should be a tensor with shape (batch_size, 1).
The output tensor should be saved in a file named "output.pth" in the same directory as your python file.
The user will evaluate the shape of the output tensor so the tensor read from "output.pth" should be 8 numbers.
qlib_model_simulator: |-
The models will be sent into Qlib to train and evaluate their performance in predicting future returns. Hypothesis is improved upon checking the feedback on the results.
Qlib is an AI-oriented quantitative investment platform that aims to realize the potential, empower research, and create value using AI technologies in quantitative investment, from exploring ideas to implementing productions. Qlib supports diverse machine learning modeling paradigms, including supervised learning, market dynamics modeling, and reinforcement learning (RL).
User will use Qlib to automatically perform the following tasks:
1. Generate a baseline factor table.
2. Train the model defined in your class Net to predict the next several days' returns based on the factor values.
3. Build a portfolio based on the predicted returns using a specific strategy.
4. Evaluate the portfolio's performance, including metrics such as return, IC, max drawdown, and others.
5. Iterate on growing the hypothesis to enable model improvements based on performance evaluations and feedback.
qlib_model_rich_style_description: |-
### Qlib Model Evolving Automatic R&D Demo
#### [Overview](#_summary)
The demo showcases the iterative process of hypothesis generation, knowledge construction, and decision-making in model construction in quantitative finance. It highlights how models evolve through continuous feedback and refinement.
#### [Automated R&D](#_rdloops)
- **[R (Research)](#_research)**
- Iteration of ideas and hypotheses.
- Continuous learning and knowledge construction.
- **[D (Development)](#_development)**
- Evolving code generation and model refinement.
- Automated implementation and testing of models.
#### [Objective](#_summary)
To demonstrate the dynamic evolution of models through the Qlib platform, emphasizing how each iteration enhances the accuracy and reliability of the resulting models.
qlib_model_experiment_setting: |-
| Dataset 📊 | Model 🤖 | Factors 🌟 | Data Split 🧮 |
|---------|----------|---------------|-------------------------------------------------|
| CSI300 | RDAgent-dev | 20 factors (Alpha158) | Train: 2008-01-01 to 2014-12-31 <br> Valid: 2015-01-01 to 2016-12-31 <br> Test &nbsp;: 2017-01-01 to 2020-08-01 |
patches/qlib_rd_loop_prompts.yaml
+23
View File
@@ -0,0 +1,23 @@
hypothesis_generation:
system: |-
You are an expert in FX and quantitative trading, specialized in EURUSD intraday strategies.
Your task is to generate a well-reasoned hypothesis for new alpha factors based on EURUSD 15min OHLCV data.
Key market knowledge:
- EURUSD trades 24h with three main sessions: Asian (00:00-08:00 UTC), London (08:00-16:00 UTC), NY (13:00-21:00 UTC)
- London-NY overlap (13:00-16:00 UTC) has highest volume and momentum
- Asian session shows mean reversion tendencies
- Spread costs approximately 1.5 bps per trade — avoid overtrading
- No overnight gap risk like stocks, but weekend gaps exist
- Volume spikes signal news events (NFP, ECB, Fed)
Please ensure your response is in JSON format as shown below:
{
"hypothesis": "A clear and concise hypothesis based on the provided information.",
"reason": "A detailed explanation supporting the generated hypothesis.",
}
user: |-
The following are the financial factors and their descriptions:
{{ factor_descriptions }}
The report content is as follows:
{{ report_content }}
patches/qlib_scenarios_prompts.yaml
+310
View File
@@ -0,0 +1,310 @@
hypothesis_and_feedback: |-
=========================================================
{% for experiment, feedback in trace.hist %}
# Trial {{ loop.index }}:
## Hypothesis
{{ experiment.hypothesis }}
## Specific task:
{% for task in experiment.sub_tasks %}
{% if task is not none and task.get_task_brief_information is defined %}
{{ task.get_task_brief_information() }}
{% endif %}
{% endfor %}
## Backtest Analysis and Feedback:
{% if experiment.result is not none %}
Backtest Result: {{ experiment.result.loc[["IC", "1day.excess_return_without_cost.annualized_return", "1day.excess_return_without_cost.max_drawdown"]] }}
{% endif %}
Observation: {{ feedback.observations }}
Hypothesis Evaluation: {{ feedback.hypothesis_evaluation }}
Decision (Whether the hypothesis was successful): {{ feedback.decision }}
=========================================================
{% endfor %}
last_hypothesis_and_feedback: |-
## Hypothesis
{{ experiment.hypothesis }}
## Specific task:
{% for task in experiment.sub_tasks %}
{% if task is not none and task.get_task_brief_information is defined %}
{{ task.get_task_brief_information() }}
{% endif %}
{% endfor %}
## Backtest Analysis and Feedback:
{% if experiment.result is not none %}
Backtest Result: {{ experiment.result.loc[["IC", "1day.excess_return_without_cost.annualized_return", "1day.excess_return_without_cost.max_drawdown"]] }}
{% endif %}
Training Log:
Here, you need to focus on analyzing whether there are any issues with the training. If any problems are identified, you must correct them in the next iteration and clearly describe how the changes will be made in the hypothesis.
{{ experiment.stdout }}
Observation: {{ feedback.observations }}
Evaluation: {{ feedback.hypothesis_evaluation }}
Decision (Whether this experiment is SOTA): {{ feedback.decision }}
New Hypothesis (Given in feedback stage, just for reference, and can be accepted or rejected in the next round): {{ feedback.new_hypothesis }}
Reasoning (Justification for the new hypothesis): {{ feedback.reason }}
sota_hypothesis_and_feedback: |-
## Hypothesis
{{ experiment.hypothesis }}
## Specific task:
{% for task in experiment.sub_tasks %}
{% if task is not none and task.get_task_brief_information is defined %}
{{ task.get_task_brief_information() }}
{% endif %}
{% endfor %}
## Backtest Analysis and Feedback:
{% if experiment.result is not none %}
Backtest Result: {{ experiment.result.loc[["IC", "1day.excess_return_without_cost.annualized_return", "1day.excess_return_without_cost.max_drawdown"]] }}
{% endif %}
Training Log: {{ experiment.stdout }}
Observation: {{ feedback.observations }}
Evaluation: {{ feedback.hypothesis_evaluation }}
Decision (Whether this experiment is SOTA): {{ feedback.decision }}
hypothesis_output_format: |-
The output should follow JSON format. The schema is as follows:
{
"hypothesis": "An exact, testable, and innovative statement derived from previous experimental trace analysis. Avoid overly general ideas and ensure precision. The hypothesis should clearly specify the exact approach and expected improvement in performance in two or three sentences.",
"reason": "Provide a clear, logical explanation for why this hypothesis was proposed, grounded in evidence (e.g., trace history, domain principles). Reason should be short with no more than two sentences.",
}
factor_hypothesis_output_format: |-
The output should follow JSON format. The schema is as follows:
{
"hypothesis": "The new hypothesis generated based on the information provided. Limit in two or three sentences.",
"reason": "The reason why you generate this hypothesis. It should be comprehensive and logical. It should cover the other keys below and extend them. Limit in two or three sentences.",
}
hypothesis_output_format_with_action: |-
The output should follow JSON format. The schema is as follows:
{
"action": "If `hypothesis_specification` provides the action you need to take, please follow "hypothesis_specification" to choose the action. Otherwise, based on previous experimental results, suggest the action you believe is most appropriate at the moment. It should be one of [`factor`, `model`].",
"hypothesis": "The new hypothesis generated based on the information provided,should be a string.",
"reason": "The reason why you generate this hypothesis. It should be comprehensive and logical. It should cover the other keys below and extend them. Limit in two or three sentences.",
}
model_hypothesis_specification: |-
1. First, observe and analyze the overall experimental progression in `hypothesis_and_feedback`. Analyze where the previous model designs were inadequate — whether it was due to parameter settings, architectural flaws, or a lack of novelty (proposing entirely new concepts is highly encouraged as long as they demonstrate effectiveness).
2. Second, `last_hypothesis_and_feedback` and `sota_hypothesis_and_feedback` are key references you should pay close attention to. You can choose to optimize based on either of them or generate new ideas to form hypotheses and experiments.
3. If there is no prior experiment or result available at the beginning, you can start by implementing a simple and small architecture.
4. If a series of attempts fail to achieve SOTA, consider exploring entirely new directions; at this point, it is acceptable to return to simple architectures.
5. Focus exclusively on the architecture of PyTorch models. Each hypothesis should specifically address architectural decisions, such as layer configurations, activation functions, regularization methods, and overall model structure. DO NOT do any feature-specific processing. Instead, you can propose innovative transformations on the input time-series data to enhance model training effectiveness.
6. Avoid including aspects unrelated to architecture, such as input features or optimization strategies.
7. Sometimes, when training performance is poor, adjusting hyperparameters can also be an effective strategy for improvement.
8. Use standard libraries for baseline models, but also explore custom architecture designs to investigate novel structures. After sufficient trials with traditional models, aim for innovation comparable to top-tier AI conferences (NeurIPS, ICLR, ICML, SIGKDD, etc.) in time series modeling.
factor_hypothesis_specification: |-
You are developing alpha factors for EURUSD intraday trading using 15-minute OHLCV bars.
**Market Context:**
- EURUSD trades 24h with three sessions: Asian (00:00-08:00 UTC), London (08:00-16:00 UTC), NY (13:00-21:00 UTC)
- London-NY overlap (13:00-16:00 UTC) has highest volume and trending behavior
- Asian session shows mean reversion tendencies
- Spread cost ~1.5 bps per trade — avoid high-turnover factors
- No $factor column exists — use only $open, $close, $high, $low, $volume
- Each "instrument" is EURUSD, each "day" is a 15min bar
**Factor Generation Rules:**
1. **3-5 Factors per Generation** — cover different signal types per round
2. **FX-Specific Signals First:**
- Momentum: price change over last N bars (N=4,8,16,32 = 1h,2h,4h,8h)
- Mean Reversion: deviation from rolling mean, Bollinger Band position
- Volatility: ATR, realized vol, high-low range normalized
- Volume: volume spike ratio, volume trend
- Session: time-of-day encoded signals (London open, NY open)
3. **Gradual Complexity:**
- Rounds 1-5: single indicators (RSI, momentum, ATR)
- Rounds 6-15: combined signals (momentum + volume filter)
- Rounds 15+: ML-based factors (LSTM embeddings, XGBoost residuals)
4. **Avoid:**
- Factors requiring $factor column
- Daily-frequency assumptions (no overnight gaps in logic)
- Factors with >100 bar lookback without justification
5. No matter how many factors you plan to generate, only reply with one set of hypothesis and reason.
factor_experiment_output_format: |-
The output should follow JSON format. The schema is as follows:
{
"factor name 1": {
"description": "description of factor 1, start with its type, e.g. [Momentum Factor]",
"formulation": "latex formulation of factor 1",
"variables": {
"variable or function name 1": "description of variable or function 1",
"variable or function name 2": "description of variable or function 2"
}
},
"factor name 2": {
"description": "description of factor 2, start with its type, e.g. [Machine Learning based Factor]",
"formulation": "latex formulation of factor 2",
"variables": {
"variable or function name 1": "description of variable or function 1",
"variable or function name 2": "description of variable or function 2"
}
}
# Don't add ellipsis (...) or any filler text that might cause JSON parsing errors here!
}
model_experiment_output_format: |-
So far please only design one model to test the hypothesis!
The output should follow JSON format. The schema is as follows (value in training_hyperparameters is a basic setting for reference, you CAN CHANGE depends on the previous training log):
{
"model_name (The name of the model)": {
"description": "A detailed description of the model",
"formulation": "A LaTeX formula representing the model's formulation",
"architecture": "A detailed description of the model's architecture, e.g., neural network layers or tree structures",
"variables": {
"\\hat{y}_u": "The predicted output for node u",
"variable_name_2": "Description of variable 2",
"variable_name_3": "Description of variable 3"
},
"hyperparameters": {
"hyperparameter_name_1": "value of hyperparameter 1",
"hyperparameter_name_2": "value of hyperparameter 2",
"hyperparameter_name_3": "value of hyperparameter 3"
},
"training_hyperparameters" { # All values are for reference; you can set them yourself
"n_epochs": "100",
"lr": "1e-3",
"early_stop": 10,
"batch_size": 256,
"weight_decay": 1e-4,
}
"model_type": "Tabular or TimeSeries" # Should be one of "Tabular" or "TimeSeries"
},
}
factor_feedback_generation:
system: |-
You are a professional financial result analysis assistant in data-driven R&D.
The task is described in the following scenario:
{{ scenario }}
You will receive a hypothesis, multiple tasks with their factors, their results, and the SOTA result.
Your feedback should specify whether the current result supports or refutes the hypothesis, compare it with previous SOTA (State of the Art) results, and suggest improvements or new directions.
Please understand the following operation logic and then make your feedback that is suitable for the scenario:
1. Logic Explanation:
a) All factors that have surpassed SOTA in previous attempts will be included in the SOTA factor library.
b) New experiments will generate new factors, which will be combined with the factors in the SOTA library.
c) These combined factors will be backtested and compared against the current SOTA to enable continuous iteration.
2. Development Directions:
a) New Direction: Propose a new factor direction for exploration and development.
b) Optimization of Existing Direction:
- Suggest further improvements to that factor (this can include further optimization of the factor or proposing a direction that combines better with the factor).
- Avoid re-implementing previous factors as those that surpassed SOTA are already included in the factor library and will be used in each run.
3. Final Goal: To continuously accumulate factors that surpass each iteration to maintain the best SOTA.
When judging the results:
1. Any small improvement should be considered for inclusion as SOTA (set `Replace Best Result` as yes).
2. If the new factor(s) shows an improvement in the annualized return, recommend it to replace the current best result.
3. Minor variations in other metrics are acceptable as long as the annualized return improves.
Consider Changing Direction for Significant Gaps with SOTA:
- If the new results significantly differ from the SOTA, consider exploring a new direction (write new type factors).
- Avoid re-implementing previous factors as those that surpassed SOTA are already included in the factor library and will be used in each run.
Please provide detailed and constructive feedback for future exploration.
Respond in JSON format. Example JSON structure for Result Analysis:
{
"Observations": "Your overall observations here",
"Feedback for Hypothesis": "Observations related to the hypothesis",
"New Hypothesis": "Your new hypothesis here",
"Reasoning": "Reasoning for the new hypothesis",
"Replace Best Result": "yes or no"
}
user: |-
Target hypothesis:
{{ hypothesis_text }}
Tasks and Factors:
{% for task in task_details %}
- {{ task.factor_name }}: {{ task.factor_description }}
- Factor Formulation: {{ task.factor_formulation }}
- Variables: {{ task.variables }}
- Factor Implementation: {{ task.factor_implementation }}
{% if task.factor_implementation == "False" %}
**Note: This factor was not implemented in the current experiment. Only the hypothesis for implemented factors can be verified.**
{% endif %}
{% endfor %}
Combined Results:
{{ combined_result }}
Analyze the combined result in the context of its ability to:
1. Support or refute the hypothesis.
2. Show improvement or deterioration compared to the SOTA experiment.
Note: Only factors with 'Factor Implementation' as True are implemented and tested in this experiment. If 'Factor Implementation' is False, the hypothesis for that factor cannot be verified in this run.
model_feedback_generation:
system: |-
You are a professional quantitative analysis assistant in top-tier hedge fund.
The task is described in the following scenario:
{{ scenario }}
You will receive a quantitative model hypothesis, its specific task description, and it market backtest result.
Your feedback should specify whether the current result supports or refutes the hypothesis, compare it with previous SOTA results, examine the model's training logs to analyze whether there are issues with hyperparameter settings, and suggest improvements or new directions.
Please provide detailed and constructive feedback.
Example JSON Structure for Result Analysis:
{
"Observations": "First analyze the model's training logs to determine whether there are any issues with its parameter settings. Then clearly summarize the current results and the SOTA results with exact scores and any notable patterns. Limit your summary to no more than three concise, data-focused sentences.",
"Feedback for Hypothesis": "Explicitly confirm or refute the hypothesis based on specific data points or performance trends. Limit to two sentences.",
"New Hypothesis": "Propose a revised hypothesis, considering observed patterns and limitations in the current one. Limit to no more than two sentences.",
"Reasoning": "Explain the rationale for the new hypothesis using specific trends or performance shifts. Be concise but technically complete. Limit to two sentences.",
"Decision": <true or false>,
}
user: |-
{% if sota_hypothesis %}
# SOTA Round Information:
Hypothesis: {{ sota_hypothesis.hypothesis }}
Specific Task: {{ sota_task }}
Code Implementation: {{ sota_code }}
Result: {{ sota_result }}
{% else %}
# This is the first round. No previous information available. As long as the performance is not too negative (eg.ICIR is greater than 0), treat it as successful. Do not set the threshold too high.
{% endif %}
# Current Round Information:
Hypothesis: {{ hypothesis.hypothesis }}
Why propose this hypothesis: {{ hypothesis.reason }}
Specific Task: {{ exp.sub_tasks[0].get_task_information() }}
Code Implementation: {{ exp.sub_workspace_list[0].file_dict.get("model.py") }}
Training Log: {{ exp.stdout }}
Result: {{ exp_result }}
# When judging the results:
1. **Recommendation for Replacement:**
- If the new model's performance shows an improvement in the annualized return, recommend it to replace the current SOTA result.
- Minor variations in other metrics are acceptable as long as the annualized return improves.
2. Consider Changing Direction When Results Are Significantly Worse Than SOTA:
- If the new results significantly worse than the SOTA, consider exploring a new direction, like change a model architecture.
action_gen:
system: |-
Quantitative investment is a data-driven approach to asset management that relies on mathematical models, statistical techniques, and computational methods to analyze financial markets and make investment decisions. Two essential components of this approach are factors and models.
You are one of the most authoritative quantitative researchers at a top Wall Street hedge fund. I need your expertise to develop new factors and models that can enhance our investment returns. Based on the given context, I will ask for your assistance in designing and implementing either factors or a model.
You will receive a series of experiments, including their factors and models, and their results.
Your task is to analyze the previous experiments and decide whether the next experiment should focus on factors or models.
Example JSON Structure for your return:
{
"action": "factor" or "model", # You must choose one of the two
}
user: |-
{% if hypothesis_and_feedback|length == 0 %}
It is the first round of hypothesis generation. The user has no hypothesis on this scenario yet.
{% else %}
The former hypothesis and the corresponding feedbacks are as follows:
{{ hypothesis_and_feedback }}
{% endif %}
{% if last_hypothesis_and_feedback != "" %}
Here is the last trial's hypothesis and the corresponding feedback. The main feedback includes a new hypothesis for your reference only. You should evaluate the entire reasoning chain to decide whether to adopt it, propose a more suitable hypothesis, or transfer and optimize it for another scenario (e.g., factor/model), since transfers are generally encouraged:
{{ last_hypothesis_and_feedback }}
{% endif %}