Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add from_file class method to the Prompt object #1345

Open
rlouf opened this issue Dec 19, 2024 · 3 comments · May be fixed by #1355
Open

Add from_file class method to the Prompt object #1345

rlouf opened this issue Dec 19, 2024 · 3 comments · May be fixed by #1355
Assignees
Milestone

Comments

@rlouf
Copy link
Member

rlouf commented Dec 19, 2024

We keep coming back to the following pattern: first write the prompt in docstrings, and move it to a text file once it gets too large. It would be nice if Outlines made it easy for users to generate a prompt template from a text file. The file can contain plain text, or be written using the Jinja2 templating syntax.

I propose to add a from_file classmethod, which reads the file, extracts the names of the free variables (if any) in the template, and returns a Prompt instance.

@rlouf rlouf added this to the 1.0 milestone Dec 19, 2024
@yvan-sraka
Copy link
Contributor

What does the user code look like currently, and what would it look like after this change? This seems like a pretty standard design.

Would you, at some point, like to have a CLI automation tool that helps users extract docstrings of interest to external files in a given subfolder, to help “standardize” what a project using outlines would look like?

@rlouf
Copy link
Member Author

rlouf commented Dec 20, 2024

Why?

Currently people would write their prompt in a long block between """ marks in the same file. What we have started doing naturally, and seen others do as well, is to move the prompt to a text file to be able to work on it more easily. And then write logic to import the text. Most of the logic we need to process Jinja templating is already implemented in the Prompt object so it would be a fairly simple addition.

Current design

The current way to build Prompt objects is by decorating a function that contains the Jinja template in its docstring, and whose arguments correspond to the variables of the template:

import outlines

@outlines.prompt
def prompt_template(a: int, b: int):
    """You are a calculator.
    
    What is {{ a }} + {{ b }}?"""

This is not great design, and will be refactored for v1.0. For now we will keep this, but add the from_file method to create Prompt instances from Jinja templates stored in text files.

Other points

Would you, at some point, like to have a CLI automation tool that helps users extract docstrings of interest to external files in a given subfolder, to help “standardize” what a project using outlines would look like?

Maybe in a distant future, after we've had confirmation from users that transitioning is a pain point

@rlouf
Copy link
Member Author

rlouf commented Jan 2, 2025

Just to specify a little more the user interface. Assume the following file structure:

my_script.py
prompt.txt

such that prompt.txt contains a Jinja template (which can be plain text with no variables):

Here is a prompt with examples:

{% for example in examples %}
- Q: {{ example.question }}
- A: {{example.answer }}
{% endfor %}

Now please answer the following question:

Q: {{ question }}
A: 

In my_script.py we would like to be able to create a Prompt object from the content of the file:

from outlines import Prompt

template = Prompt.from_file("prompt.txt")

So that we can can render the template as follows:

examples = ... # List of NamedTuples for instance
question = "What is the Earth's diameter?"

prompt = template(examples, question)
print(prompt)
# The rendered prompt as a string

So we'll need to extract the variables from the template. We need to be able to do so even with Jinja templates that use template inheritance or simple includes.

The signature of the __call__ method of the Prompt instance will need to be specified so that it is discoverable by users and IDEs. We will also need to document this change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants