## Inspiration

As the list of use cases grow for artificial intelligence (AI for short), we thought that it is important to use AI in order to bridge the gap between those who are tech-savvy and those who are non tech-savvy. We were inspired to create this project because we know people that are not knowledgeable in SQL; we know people who are not that knowledgeable in technology that is more on the complicated side. Not everyone is a data scientist. However, a database is an entity that most people often (but do not realize) interact with. In fact, people close to us such as our parents, often are not knowledgeable in SQL. That's where we thought of Databae. Why not just use a language that most people know (in the US) such as English and use that to provide insightful analysis and visualization to the user?

## What it does

Let's introduce you to your new friend, **Databae.** It is your personal AI assistant when it comes to making queries to any database and providing insightful analysis on the dataset. Let's be honest. Not everyone wants to write SQL queries. Not everyone knows SQL. Not everyone knows how to use complicated technologies. That's where Databae comes in. We utilize AI in order to use human language to provide insights on the data in your database.

Databae generates a SQL query, double checks the SQL query against the database schema and prompt to make sure that it is a valid query, execute the query, and analyze the result set in order to provide you visualizations (only table form is available for now) about data that exists in your database.

We do not just generate SQL queries and execute them. That is boring!!! We provide analysis on your data. Your question does not have to have anything corresponding with an SQL statement. You can perhaps ask, "Which employee in the company is best suited for frontend development?," and Databae will make sure to provide you analysis on that rather than just generating a SQL query and getting the result set.

## How we built it

![Diagram](https://i.imgur.com/SaW3t59.jpeg)
**Frontend:**

* Next.js - Basically, the core of our frontend. It displays the front page, connection page, and dashboard.
* Shadcn/ui - We used certain components from Shadcn/ui such as the buttons.
* Framer Motion - Do you see the cool animations on our website? Well, Framer Motion allows us to display those cool animations to you.

**Backend:**

* Python - This is the programming language that powers our backend.
* FastAPI - FastAPI powers our API endpoints and allows the frontend to request data to display on the frontend.
* Groq: We utilized Groq's LLaMA models to be able to generate SQL queries, check the SQL queries, and analyze the result set and provide insightful analysis and visualizations.
* uAgents: We utilized uAgents to create AI agents that are able to communicate with one another. uAgents powers our query generator, query checker, query executor, and query analyzer.

**AI Agents (part of our backend):**

* Query Generator: The query generator receive the user's request, utilizing the LLaMA model to process the user's prompt, understand and determining if a tool is need or not. If an SQL query and AI tool is needed, it will send the query to the Query Checker. If not, the workflow stops there and it will provide the user with general knowledge related to the database or its schemas.
* Query Checker: The query checker checks whether the SQL query generated abides by the database schema and user's prompt. If the query checker approves of the SQL query, it will forward the query to the query executor. Otherwise, it will notify the user that the query generated cannot be executed due to the query being too vague or unrelated.
* Query Executor: The query executor executes the query, gets the dataset from the query, and forwards the dataset to the query analyzer along with the database schema and prompt.
* Query Analyzer: The query analyzer analyzes the result set, gives insightful results and visualizes the results in a clear and concise manner accordingly to the user's request.

## Challenges we ran into

* As our frontend has a lot of animations and other cool elements to it, it took a long time to be able to perfect and optimize the appearance of our frontend.
* Being able to finetune and prompt engineer the LLM models in order to provide the appropriate responses. We had to make lots of adjustments in the prompts in order for it to provide good analysis of the data.
* We had to figure out how to properly translate the LLM's response into a proper Pandas DataFrame (basically the table).
* Handling multi-agent communication in uAgents was also a struggle as we had to figure out how to make one agent talk to another that talks to another and vice versa.

## Accomplishments that we're proud of

* We are proud of being able to utilize Fetch.AI's AI agents in order to satisfy our workflow of generating a SQL query => checking the SQL query => executing the SQL query => analyzing the SQL query and providing proper visualizations.
* We are also proud of being able to use Groq's extremely fast LLMs in order to quickly provide quality but fast analysis of the data in the database.
* Our frontend was also an important aspect. We used many libraries in order to optimize and "perfect" the appearance of our website. It took us a long time to design the website in the first place.

## What we learned

We learned about new amazing frameworks such as Fetch.AI's AI agents. With the assistance of many mentors in CalHacks, we were able to learn a lot about new technologies and techniques We also learned about Groq's LLMs; those were vital in providing those ultra quick responses to the user, and we see many other possible use cases for it.

## What's next for Databae.

* **More tools:** We intend to create more tools for Databae. Our application was designed to have many more tools such as a pie chart generator, prediction models, and other tools. For our use case, we decided to only generate our visualizations in table form, but it is able to scale up in order to be able to display it in many more forms such as pie charts, bar charts, etc.
* **Cross database analysis:** What if you want to analyze multiple databases and make correlations between multiple databases? We want to add this functionality.
* **Integration with more databases:** We want to be able to have Databae be able to be integrated into more databases such as PostgreSQL, MongoDB, and other DBs.
* **Finetuning the prompts:** We want to finetune the prompts in order to provide more insightful responses and visualizations.
## Inspiration

Inspired by Nicole's many trips to the ER.

## What it does

OctoBud is a chat bot for Amazon Alexa that helps decrease wait times in the ER by decreasing the amount of time that nurses have to spend with each patient and by giving alternative options to the current ER. OctoBud gets the information from the patient (currently just through the Alexa but eventually also through a computer to secure sensitive information like health card number) and runs analysis on it to determine the patient's priority and therefore their order in the queue. The patients data is then sent to the ER nurses as a card and they are given the opportunity to validate the decision made by the bot and update it if necessary or add comments. It doesn't eliminate the interaction between the patient and the ER nurses but instead decreases the time of these interactions by getting the patient's information prior to seeing the nurse and storing it in an organized fashion.

## How we built it

We utilized the StdLib api to build the Alexa skill as well as access MongoDB. The Alexa skill was written in node.js and the website for the nurse side was written in HTML(EJS)/CSS/JS.

## Challenges we ran into

StdLib did not have the functionality built in to do a session in the Alexa skill that is longer than one request and one response so we had to build that functionality ourselves and because we were using the StdLib api and not AWS lamda the solutions on the internet for this problem were not possible (at least not in the period of time that we have in the hackathon). Another problem is that amazon doesn't send the user's exact request (just the variables/slots) so we had no way of getting their answer for each reprompt without destroying the rest of the functionality or adding a trigger word/phrase. We solved this by using a trigger word/phrase that we believe still moves smoothly with the conversation with the bot and allows us to grab the values that we want.

## Accomplishments that we're proud of

No one on our team had ever built an Alexa app before last weekend (we were at another hackathon) and before this hackathon none of us had ever built a chat bot so we are proud that we were able to create a successful and useful chat bot despite the many challenges that we faced along the way.

## What we learned

We learned a lot about Alexa skills and more about persevering through challenges and building something that we can be proud of. In addition, we gained experience with database communication with MongoDB and between different files.

## What's next for OctoBud

We see a lot of potential for OctoBud. Wait times in ERs are a huge problem that we have all been affected by and is a solvable problem. The next steps that we see for OctoBud are to be able to submit information from a smart phone or smart home device at home and have your information either sent to your closest hospital or a different hospital depending on the wait times in near by hospitals and how good they are at treating your illness/injury. We also see this possibly integrating with other companies in this area such as house call doctors so that you can have a doctor come to your hospital instead of going to the hospital and spending hours waiting to see a doctor, or giving you the option and information about alternatives to ERs in hospitals such as urgent care centres. All of these things will help decrease the wait times in our emergency rooms and improve our health care system to make health care more accessible in a reasonable amount of time for everyone.
## Inspiration

We all came together to solve a problem that people struggle with on a regular basis. We are we were immigrants who hail from different places in the world where English is not a prevalent language! We thought to ourselves, what is someone that is difficult and is often. detriment to various communities? We discovered that we could leverage our knowledge to help communities that either are drawn into confusion or are taken advantage of through legal documentation that is often difficult to understand, even for those who are fluent in English.

## What it does

We leveraged large language models, ORC, and base 64 to scan documents, summarize them, and translate them to a person's language. We do this summarization and translation by implementing Together.ai's api and fine tuning models using our datasets.

## How we built it

We built it by splitting the team into various roles - Juan: Front-end, Aleks: Front-end / Back-end, Randolf: APIs, ML/AI, and Xiang (UI/UX / Front-end). Our technology/ Design stack: Tailwind.css, Python, Javascript, Together.ai API, Google Vision API, Typescript, Javascript, Next.js, Libraries for transforming PDFs.

## Challenges we ran into

We all ran into tough challenges as we struggled to connect components together which include:
 - Working with Pdf documents: searching for the best libraries to help convert documents to images
 - Connecting to google vision api after obtaining said images
 - Working with timeouts with displaying words using visual effects in the front-end
 - Loading effects, creating try-catch statements using logical processing
 - Designing the website using sigma to have a simple but elegant UI/UX
 - Congregating data to use in together.ai's LLMs (LLaMA - for summarization, llama 2 - for key points / insights) using python scripting
 - Working with Together.ai's prompting to ensure the best answer quality for the queries needed to operate our platforms

## Accomplishments that we're proud of

```
- Undertaking such an ambitious project
- Working tirelessly through problems without sleeping much
- Communicating our ideas about the project, while also helping each troubleshoot problems

```

## What we learned

```
- We learned that creating projects that are meaningful to us as individuals is much more rewarding than simply creating a project for the sake of a project
- How different technologies interact with each other and how they all play a role in the development process.
- Working with a team, delegating tasks so that each person has something to work on.

```

## What's next for LegalLingua

```
- Improving the large language models so that the summarization and translation process is easier to do/ much faster
- Increase capacity sizes for pdf / document input so that we can accept a larger variety of legal documentation.

```