- Fewer restrictions on the types of content they will generate
- Speeding up generation and lowering token usage by discouraging verbose responses
- Leveraging prompts from popular libraries like LangChain which assume a completions-style interface
Interface Parity
While we try to maintain parity between the “Chat” and “Completions” interfaces in Rigging, you’ll find some deviations here and there. Completions should be a simple transition if you are familiar with the other code in rigging. Here are the highlights:chat
->complete
Chat
->Completion
ChatPipeline
->CompletionPipeline
generate_messages
->generate_texts
Message
objects have been
replaced with basic str
objects for both inputs and outputs.
Translator Example
Let’s build a simply translator object that we can store as aCompletionPipeline
and use it quickly translate a phrase to 3 different languages.
- OpenAPI supports the same model IDs for both completions and chats, but other providers might require you to specify a specific model ID used for text completions.
- We use
.with_()
to set stop tokens and prevent the generation from simply continuing until our max tokens are reached. This is a very common and often required pattern when doing completions over chats. Here, we aren’t totally sure what the model might generate after our translation, so we use a few different token sequences to be safe.
Using .apply()Text completion is a great place to use the
.apply
method as we can easily slot in our inputs without using .add
and following it with our output section of the prompt.