5 ms·

I see a lot of people asking how does this work. The method he is using is one shot learning. He has a prompt and an example of what the interaction should look

I see a lot of people asking how does this work. The method he is using is one shot learning. He has a prompt and an example of what the interaction should look like. You can see the prompt here: https://github.com/gd3kr/BlenderGPT/blob/main/__init__.py https://github.com/gd3kr/BlenderGPT/blob/main/__init__.py It is really easy to build this kind of thing - I've got a very simple command line chatbot that should be very understandable and you can easily play with the prompt. https://github.com/atomic14/command_line_chatgpt https://github.com/atomic14/command_line_chatgpt I would also recommend that people try out the openai playgrounds. They are great for experimenting with parameters.

MattRix 4y ago
yeah there’s also AICommand for Unity that uses a similar technique: https://github.com/keijiro/AICommand https://github.com/keijiro/AICommand
cube2222 4y ago
Did something similar as a natural language interface to DuckDB this weekend, and it's surprising how nice it works[0]. That said, through my testing I found it tended to trail off during longer exchanges if I only added the guidelines to the system prompt, so I ended up adding them to the first user message + adding a small reminder at the end of each further user message. [0]: https://github.com/cube2222/duckgpt https://github.com/cube2222/duckgpt
- chrisjc 4y ago
  This is brilliant! Nice job! Why didn't you do the same for OctoSQL? Are you considering DuckDB for your compute engine for OctoSQL?
  - cube2222 4y ago
    > This is brilliant! Nice job! Thanks! > Why didn't you do the same for OctoSQL? I started with OctoSQL! But the SQL dialect is a bit non-standard, while DuckDB uses the popular postgres dialect. This came up esp. with more complicated queries, where GPT was generating queries that failed with OctoSQL, while it manages to do well with the DuckDB dialect (even though it sometimes needs 2-3 attempts, but those are automatic). > Are you considering DuckDB for your compute engine for OctoSQL? I've been exploring that. The main disadvantage is that OctoSQL has support for temporal features and live-updating queries (something like reactive materialized views, in a sense), which would not be possible to accomplish with DuckDB. Moreover, if you're already using DuckDB for the execution engine, there's not much reason (other than the plugin system requiring you to use C++) to not use it end2end. I think in that case a more duckdb-native project would make sense to just fill in the niche of simpler plugin authoring for DuckDB. Something like Steampipe for Postgres foreign data wrappers, but for DuckDB. For OctoSQL I'm experimenting with WASM now as a SQL compilation target, as that could be designed to support the features I've mentioned above.
quadcore 4y ago
You can see the prompt here See how this file quickly got hacked together all in one file. It's refreshing to see and note-worthy as it appears when new exciting world-changing tech emerges that makes programmers let-go and become hackers again.

MattRix 4y ago

yeah there’s also AICommand for Unity that uses a similar technique: https://github.com/keijiro/AICommand https://github.com/keijiro/AICommand

cube2222 4y ago

Did something similar as a natural language interface to DuckDB this weekend, and it's surprising how nice it works[0]. That said, through my testing I found it tended to trail off during longer exchanges if I only added the guidelines to the system prompt, so I ended up adding them to the first user message + adding a small reminder at the end of each further user message. [0]: https://github.com/cube2222/duckgpt https://github.com/cube2222/duckgpt

chrisjc 4y ago
This is brilliant! Nice job! Why didn't you do the same for OctoSQL? Are you considering DuckDB for your compute engine for OctoSQL?
- cube2222 4y ago
  > This is brilliant! Nice job! Thanks! > Why didn't you do the same for OctoSQL? I started with OctoSQL! But the SQL dialect is a bit non-standard, while DuckDB uses the popular postgres dialect. This came up esp. with more complicated queries, where GPT was generating queries that failed with OctoSQL, while it manages to do well with the DuckDB dialect (even though it sometimes needs 2-3 attempts, but those are automatic). > Are you considering DuckDB for your compute engine for OctoSQL? I've been exploring that. The main disadvantage is that OctoSQL has support for temporal features and live-updating queries (something like reactive materialized views, in a sense), which would not be possible to accomplish with DuckDB. Moreover, if you're already using DuckDB for the execution engine, there's not much reason (other than the plugin system requiring you to use C++) to not use it end2end. I think in that case a more duckdb-native project would make sense to just fill in the niche of simpler plugin authoring for DuckDB. Something like Steampipe for Postgres foreign data wrappers, but for DuckDB. For OctoSQL I'm experimenting with WASM now as a SQL compilation target, as that could be designed to support the features I've mentioned above.

quadcore 4y ago

You can see the prompt here See how this file quickly got hacked together all in one file. It's refreshing to see and note-worthy as it appears when new exciting world-changing tech emerges that makes programmers let-go and become hackers again.