From 5b83f81f569f42d0f89c15d6fbe2a5ffa4223085 Mon Sep 17 00:00:00 2001 From: George Tsoukalas Date: Tue, 13 May 2025 23:15:55 -0500 Subject: [PATCH] Tweak prompt --- frame/configs/prompts/abstraction_prompt.yaml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/frame/configs/prompts/abstraction_prompt.yaml b/frame/configs/prompts/abstraction_prompt.yaml index 6d3d889..de372d4 100644 --- a/frame/configs/prompts/abstraction_prompt.yaml +++ b/frame/configs/prompts/abstraction_prompt.yaml @@ -4,7 +4,7 @@ abstraction_user_prompt_template: | **Output Format:** ``` - def abstraction_name(entity_id: str, graph: KnowledgeGraph) -> float: + def abstraction_name(*args) -> float: """ Description of the abstraction. """ @@ -12,20 +12,20 @@ abstraction_user_prompt_template: | 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,