Prompt engineering tools? (future of Prompt AI)

I will make a brief comment here because @mindaugasd has alerted me to this thread

It sounds like Prompt AI is doing a lot of things which Augmentor is also doing. Basically integrating with a variety of services and exposing the resulting data back into Drupal to augment content in a variety of ways. Augmentor now integrates with ECA and I have recently presented on this at DrupalSouth 2023 (Wellington). The video should be available soon to see how that is all working. So yeah - these two modules appear to be doing similar things.

@murrayw what do think about this?

Collaboration would mean not duplicating features. Prompt would focus on prompt engineering tools.

Hello, good morning. It may be a good idea.
Some time ago I didn't find other modules that did similar functionality, that's why I created Prompt.
I didn't know the Augmentor project.

The integration with ECA also exists with Prompt, I don't know if it is better or not than Augmentor. I have not tested it.

It may make sense to separate functionalities and avoid duplicating the same in the two modules.

From what I understand, the idea is that Augmentor manages the execution. Form buttons, API calls and saving values to the database.

And that Prompt allows to configure which prompts to use and which Augmentor API call to connect.

@murrayw If you can pass me the presentation, I would appreciate it. So we can see which functionalities are redundant.

Hi, great. And Augmentor side, we are discussing and exploring this on #augmentor slack channel at the moment if they would like to separate features. Plus this also a technical/design question on Augmentor side how to do this.

Slack discussion summary

I did not find how to adapt Augmentor module, so proposed to spread functionality to multiple highly specialized modules (more modular design).

by @trebormc:

[..] it makes sense to me to have three separate modules.
1. Interface modules with Drupal. Buttons on forms and ECA (Prompt right now only has very minimal integration with ECA)
2. Prompts configuration module (Prompt's main module)
3. Several modules of calls to different AI APIs (Right now, several submodules of Prompt module)

In order to integrate with APIs, I created this module today:

AI models library

→
https://www.drupal.org/project/aimodels →

@trebormc since we have beginnings of "AI models library", what do you think about reorganizing this module for prompt engineering only? Maybe a different branch?

About missing "2. Interface modules with Drupal" part - it is out of scope / not needed for my project, so don't know what to do with this.
(Augmentor is good at widgets side of things probably)
(And I will use ECA, but differently - planning to write new kind of ECA plugins)

On Augmentor side, maybe it will make sense to integrate with "aimodels".
On Openai side, maybe it will make sense to integrate with "aimodels" as well.

@trebormc any news?

@trebormc since we have beginnings of "AI models library", what do you think about reorganizing this module for prompt engineering only? Maybe a different branch?

@mindaugasd I don't know to what extent it makes sense to have a module just to test the prompts to be used by the Augmentor module.
If you want that, it's basically redoing the Prompt module. It would be another project or at least another branch.

I have been reviewing the functionalities of the Augmentor module, and it seems more complete than my Prompt module. Especially in the UI of the Drupal entity forms.

At the moment I have added a note on the Prompt module page recommending the Augmentor module.

PS: sorry for the delay in replying. I have had some pre-holiday work backlog of clients.

@trebormc (from slack):

I think a new module should be created for that.

Released today "AI prompt engineering" module. It allows to build complex prompts combining all kinds of Drupal data.

@trebormc (from slack):

The prompt text has to be a configuration entity, not a content entity with revisions. This is because it makes more sense to me that it should be exportable configuration between environments. For me it is a configuration that gives functionality, not a content that users can constantly edit.

Implemented both - "content" and "configuration" entities for ultra flexibility - letting AI builder flexibly adapt for their usecase.

Content entities are great for allowing end users to engineer their own prompts, while configuration entities are for administrators and developers.