verbose widget descriptions and tags

[alcueca]

Hopefully this will enable cacti to identify better the purpose and context of each widget, so that it can choose more accurately and be more self-aware.

[sgzsh269]

The PR generally is fine, trying to better understand the context behind updating the description to improve model performance.

This file is translated in 2 places:-

• https://github.com/yieldprotocol/cacti-backend/blob/dev/utils/common.py#L69 (convert to GPT functions)
• https://github.com/yieldprotocol/cacti-backend/blob/dev/utils/common.py#L80 (convert to flat text for vector db)

One factor to consider while adding more text in the description is the impact on model's context window length as that is limited.

Moreover, we also have a model evaluation framework to test the effectiveness of new changes implemented by
Harsh, so it would help to use that to objectively check if tweaking the descriptions lead to improvements.
@harshraj172 can you help review this and share how to test the changes

[sgzsh269]

Another point, providing background knowledge such as the following could be unnecessary as there's a good chance the GPT-4 model already knows about it from being pre-trained on internet data uptil 2021

NFTs are non-fungible tokens. They are unique and can be used to represent ownership of digital assets. Usually, they include some sort of image or other media and can be traded.

[harshraj172]

you can test the changes this description has by using eval framework # 3 here..

[kahkeng]

Another thought: currently widgets.yaml is meant to be geared towards AI understanding and is not human-facing, i.e. it is an implementation detail (ideally hidden from user) for the app.

If we need to also expose these widgets/descriptions to a user, we should discuss the best way to approach that (i.e. possibly have a separate file or separate field just for displaying to the user, so as to not conflate the two purposes).

If we find that the model can't understand concepts like NFT, token, etc, such that a more verbose description is helpful, we might want a separate embeddings look-up step that injects short "explainers" for concepts relevant to the user query into the prompt. This way, there's no duplication happening when we have similar widgets. Or we have these explainers at each widget level but deduplicate them into their own section, potentially as part of the system prompt. But to Sagar's point, it will eat up the token budget of the context window.