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

[WIP] Configurable prompt templates #449

Closed
wants to merge 1 commit into from

Conversation

dlqqq
Copy link
Member

@dlqqq dlqqq commented Nov 8, 2023

TODO: description. Fairly self-explanatory though.

@dlqqq dlqqq added the enhancement New feature or request label Nov 8, 2023
@dlqqq dlqqq force-pushed the configure-prompts branch from ad7e07f to 0199d9d Compare November 8, 2023 17:37
@krassowski
Copy link
Member

I see an appeal for making this into a traitlet, but wanted to ask what I believe is an important question: should it be customizable on per-provider or per-model basis instead? It feels orthogonal to the existing get_prompt_template prompt customisation used for %ai magics.

Also linking #498.

@krassowski
Copy link
Member

I am happy to open a counter PR with the per-provider strategy if that makes sense.

@dlqqq
Copy link
Member Author

dlqqq commented Dec 20, 2023

@krassowski Agreed. I think that doing this on a per-model basis makes sense.

I am happy to open a counter PR with the per-provider strategy if that makes sense.

I'm currently encouraging other contributors to use providers as little as possible in their APIs.

I've been thinking a lot about the need for a new major release of Jupyter AI, one that invalidates the earlier design decisions that I now regret. One of the biggest pain points has been the notion of providers. Providers are an implementation detail that should be abstracted away; they are extremely prevalent in our code but are found nowhere user-side. It's so confusing how providers are only providers when they're classes, but become more like "models" when they're instances. Finally, it creates a ton of ambiguity on how to implement model-specific configuration.

Unfortunately, this year, I kept running out of time to pursue these ideas further. In 2024, hopefully I will have time to implement this.

@krassowski
Copy link
Member

One of the biggest pain points has been the notion of providers. Providers are an implementation detail that should be abstracted away; they are extremely prevalent in our code but are found nowhere user-side.

I think I know some of the pain points you are referring too ;) Is there an issue discussing these plans? That would allow users and developers to express their thoughts and maybe offer some helpful suggestions. I can see argument for going either way, and given the project prominence I think it would be hugely beneficial to the community if we had an opportunity to discuss major design decisions in the open.

PS. even if you do not have a plan to describe the detailed proposal now, just having a placeholder issue with one sentence to refer to would be helpful :)

@dlqqq
Copy link
Member Author

dlqqq commented Dec 20, 2023

@krassowski Feel free to open an issue with your thoughts! Just reference the discussion here for context. Then, when I plan the next major release of Jupyter AI (what I'm calling "Jupyter AI Next" for now), I will incorporate your suggestions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants