#Retrieve current prompt 🧵

1 messages · Page 1 of 1 (latest)

prisma drum
#

Thread for @somber totem 's feature request, for more powerful inspection of current prompt history

somber totem
#

No it's not history inspection, I'll explain better

prisma drum
#

Retrieve current prompt 🧵

#

sorry I misunderstood -> changing title

#

it's just that there can be several prompts (which is why I thought of the history)

somber totem
#

I have a function that takes an Llm pointer as argument llm *dagger.Llm which acts as an LLM context, the caller configures it and sets an initial prompt.

The current problem is that you can set .WithPrompt() but you can't retrieve it later. Complex prompt need composition (langchain has a whole lib for it). We already support PromptVar, which is good. But ideally I'd like to inspect an existing Llm object and have the ability to change the prompt before calling the Llm.

For now, if we had a simple .Prompt() -> string that returns the current set prompt, it'd be enough.

Longer term, we could take some inspiration from more elaborate prompt libraries.

tidal dock
#

it still sounds to me like we want the llm.history? or maybe filtered down to role: user? I don't know what current set prompt means though. It's like asking what's the current withExec on a container. There might be lots and they're all additive to the state

coral bridge
#

i think that depends on whether .history forces a sync, which wouldn't be what you want here

prisma drum
#

Right. You can retrieve the last prompt today by calling history() and iterating on the result (user prompts are mixed with replies and tool calls in the history). But at the moment the history API is very crude, no filtering and no structured output. We could add that easily

#

no, I don't think it does

craggy basin
#

mm, i actually came up with a reason i want this for working on test cases 🤔
I think llm.history feels kind of like the right api, with the right filtering/structure

#

but, one issue i'm hitting is actually getting access to the llm object. e.g. in toy-programmer, the llm object we're using never escapes GoProgram - I only get the container afterwards