Tweak prompt

frame/configs/prompts/abstraction_prompt.yaml

@@ -4,28 +4,28 @@ abstraction_user_prompt_template: |
 
   **Output Format:**
   ```
-  def abstraction_name(entity_id: str, graph: KnowledgeGraph) -> float:
+  def abstraction_name(*args) -> float:
       """
       Description of the abstraction.
       """
       # ... implementation ...
       return score
   ```
 
-  Do not return more than {max_abstractions} abstractions. If you do not believe there are any useful abstractions, return an empty list. 
+  The arguments to the abstraction method are up to you to decide.Do not return more than {max_abstractions} abstractions. If you do not believe there are any useful abstractions, return an empty list. 
   Do not return any abstractions which are just the calculate_interestingness function themselves. Do not return any abstractions which do error-handling, or anything else unrelated to calculation of the interestingness.
   Keep the documentation concise. Do not name any abstractions you make the same name as any of the abstractions already provided, and do not name it `calculate_interestingness`.
   You can make abstractions which are improvements over other abstractions, if you think they are useful and distinct or more general. If you make an improvement abstraction, add "_vn" for some n to the end of the name to ensure a distinct name.
   Importantly, please do not make abstractions which seem to do things already handled by other abstractions! Do not "abstract" the abstractions themselves, and do not make an entire given program an abstraction, you can and should do smaller subroutines.
   Make sure the abstractions you generate are syntactically correct and do not call variables which don't exist. The abstractions you choose do not have to be common to many of the given functions, they should just abstract out useful operations which are not already handled by other abstractions.
   You can compose abstractions if you think it makes sense to do so, but importantly, make sure to keep the abstractions *general* - do not hard-code values which could be passed as arguments, for instance. YOU MUST PROVIDE THE IMPLEMENTATION OF THE ABSTRACTIONS YOU RETURN!
-  You should prefer making abstractions from functions which have higher scores. 
+  You should prefer making abstractions from functions which have higher scores. MAKE SURE YOU DON'T CREATE A NEW ABSTRACTION WHICH IS THE SAME AS AN EXISTING ABSTRACTION, BUT WITH A DIFFERENT NAME!
 
   Here are the functions (program examples) you are given:
   {program_examples}
 
 abstraction_system_prompt: |
-  You are a helpful assistant that identifies useful abstractions/subroutines in a set of given functions.
+  You are a helpful assistant that identifies useful abstractions/subroutines in a set of given functions. An abstraction is not just a subprogram, but one which can also abstract out constant multipliers and other operations, if desired.
   You will be given a set of functions used to calculate interestingness along with a score indicating their value. If you believe that there are
   useful abstractions or subroutines in these functions, you should identify them and return them in a list of
   python code blocks, each representing an abstraction, along with a short description of the abstraction as a docstring. Use your discretion,