Viewing a single comment thread. View all comments

iamspro t1_jderz7f wrote

I tried fine tuning vs few shot for my own implementation and in the end few shot was just much easier, despite the context window drawback. Huge advantage is you can dynamically add/remove/update APIs in an instant.

29

endless_sea_of_stars t1_jdezatt wrote

I suspect future versions will do both. They will "bake in" some basic APIs like simple calculator, calendar, fact look ups. They will use in context for 3rd party APIs.

18

iamspro t1_jdf0f1o wrote

Good point, that baking in could also include the overall sense of how to get the syntax right

6

countalabs t1_jdibk1j wrote

The "fine tuning" in OpenAI API can be few-shots. The other approach of putting the instruction or example in context should be called zero-shots.

1

iamspro t1_jdj4wzl wrote

Fine-tuning is distinct afaik... using OpenAI's language for it[1]:

zero-shot: no examples in the prompt, just an input (and/or instruction)

few-shot: one or more examples of input+output in the prompt, plus new input

fine-tuning: updating the model with examples (which can then be used with zero- or few-shot as you wish)

[1] https://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-with-openai-api (part 5)

3

_faizan_ t1_jdwdwsm wrote

Is there an open Implementation of ToolFormer? or you rolled your own implementation for finetuning? They did mention in their paper that they gave few In-context examples of tool usage and then used GPT-J to label more text which they finally used for fine-tuning. Did you follow a similar approach. I have been looking to reproduce tool-former but not sure where to start even.

1