Inspiration

When you receive an e-mail, you expect to see critical details, not a wall of text. Even if you skim, tearing brick-by-brick through that wall drains time you cannot get back, time better served on the work you need to do. Our desire for efficiency is what laid the foundation for this project. All of us experienced this irritation of receiving long e-mails without a quick summary. Therefore, we erected a means of quickly summarizing your e-mails.

What it does

  • This project can showcase the most recent e-mail messages specified by the user, displaying each one's Message ID, Subject, Sender, and Unread Status
  • If the user is intrigued by one of these messages, they can view its body in text format by supplying the desired Message ID
  • Should they wish to summarize that message, they can do so with a large language model by providing the desired Message ID
  • The model's generated response is then saved in a database for faster viewing
  • After this, the user can choose to post this summary on Twitter/X if the message has any news the user wants to share with the world including
    • Product launches
    • Hiring news
    • Technological developments
  • They are presented the summary for review and must confirm they want to post it to Twitter
  • Should the summary be longer than 260 characters, it releases as a thread of posts, each 260 characters long

How we built it

We constructed this with the Nylas Email API at the core as it gave us access to all the data we needed for messages. When searching a message's body, the API provides the message as an HTML string, and we clean this into a text-only format through BeautifulSoup.

To perform summarization, we used a large language model for our artificial intelligence component. More specifically, we used llama-2-7b-chat-hf. One reason why we chose this model was because of how Meta open-sourced the model. This allowed us to set up our own local instance of the model, and this ensures users their e-mails, some of which are confidential, are secure. Additionally, we used the 7B parameter version as this could run on the NVIDIA T4 GPU provided by Google Colab's free tier. We needed Transformers to use the model and LangChain to create a template for prompts. It takes the model some time to generate summaries of messages, which is why we use a SQLite3 database to store summaries and retrieve them for the user when needed.

Letting the user tweet their messages was made possible by Tweepy accessing the Twitter/X API. We segmented the string by 260 characters instead of 280 characters because of newline characters potentially exceeding the limit. All of these components are stitched together and operate within Python3. The user interacts with the program in a Colab notebook using a text-based interface and can view shared summaries on their Twitter/X account.

In order to use this project, credentials for both the Nylas and Twitter/X APIs are needed. Alongside this, a token to a Hugging Face account approved to use LLaMa 2 by Meta is needed. We provided example credentials to run the program in the first slide of the notebook.

Challenges we ran into

One major challenge we encountered was the cost. Ideally, we wanted to partake in this hackathon without spending any money on upgraded tiers or compute credits. This impacted our choice of model as ideally, we would have tried using llama-2-70b-chat-hf for this task as its performance was on par with ChatGPT. However, this would have required using at least a NVIDIA A100 40GB GPU on Colab if using 4-bit quantization, which is a paid service. While we could use llama-2-7b-chat-hf on the T4, we limited its max_length to 1024 tokens as attempting to use 2048 or 4096 tokens as the limit made us run out of memory. It is possible we could have used one of the models hosted on Together AI to summarize messages, but the service requiring credits led us to ruling it out of contention. In addition, the cost impacted Twitter API usage as we needed to follow rate limits imposed on the free tier, necessitating careful testing to avoid wasting tweets.

Another challenge we worked through was privacy and how to ensure potentially confidential contents of messages are not tracked or leaked. The first model we thought to use was ChatGPT not just because of its strong capabilities, but also because OpenAI allows developers to interact with it through their APIs. We refrained from it because of one glaring issue with, that being how OpenAI saves conversation data. This proved problematic because if a user wanted to summarize an internal e-mail with confidential information, OpenAI would store this information, breaching the user's privacy and leading to further conflicts with that user's organization. Using a local model like LLaMa 2 keeps this information secure from outside companies, avoiding these quandaries. The tweet component naturally leads to additional concerns with privacy as the user is posting to their social media account. To confirm if the user wants to post their message summary to Twitter/X, we ask if they want to tweet their message after showing them the summary as confirmation.

We also found issues with communication due to our contradicting schedules. Most of the teammates were employed, and this relegated discussions to before and after work periods. This challenge was lessened by the fact we were all in the same time zone, but being scattered across different states meant we relied on online calls through Discord to coordinate our efforts.

Accomplishments that we're proud of

We are proud of how well our product cuts down on reading times even with our limited resources. Summarizing e-mails with a large language model has the potential to significantly increase workplace efficiency in an area one may not typically expect. Providing another AI-based product to a consumer provides them a more complete toolkit to navigating and succeeding in the professional world.

We are especially excited about the prospects the social media component holds. Sharing summaries of exciting news and events can foster discussions on platforms like Twitter/X, bolstering interactions between the user and interested parties. Going forward, this cross-pollination of ideas between the professional and social worlds is bound to benefit both in the long run.

What we learned

We each learned more about how to leverage the Nylas Email API in a product. For all of us, it was our first time working with this API, and after pouring over documentation, we learned what features could be tracked for our purposes. In this vein, we learned how to make multiple APIs communicate with each other in building a product that utilizes their functionality.

It was our first time using a large language model within an application. While we were familiar with these models from chatbots in an informal sense (ChatGPT), working with one in a project gave us an understanding for some of the underlying components to them. Working with LangChain gave us insight into how we can prepare templates to simplify prompting the model.

Individually, we each improved on our team-building and communication skills as working across schedule conflicts required patience and an open mind. When we met, the cross-pollination of our ideas enhanced our own creativity, and this collaborative element helped us face challenges with varying perspectives we will incorporate into our own views going forward. Further, we gained an understanding of what it meant to take responsibility on a project component, allowing us to examine how that piece fits into the system and works in accordance with other pieces as a whole unit.

What's next for Nylasum

We hope to see Nylasum implemented in standard e-mail systems such as Outlook or Gmail, but we envision more than just its current functions. One of the features we wanted to include was viewing a user's history of prompts so the user could view every summary more readily. Another feature we wanted to include was drafting responses to e-mails as the understandings garnered from the summary could be used to come up with a potential response. The AI would only go as far as drafting the response (not sending the message) in a way the user specifies through text input so the user could perform final edits before sending the response to the recipient. If possible, we would also let the model read the user's sent e-mails to imitate their writing style. Ultimately, we wish to host this service for multiple users to use, and while we tested this project with one user, we built the database with multiple users in mind and the hope we could host it on a server.

On top of these extensions, we have speculated what would be capable with Nylasum if we wanted to pay for extra capabilities. For example, if we wanted to pay for an A100 GPU instance or credits on Together AI, we could change the model to llama-2-70b-chat-hf and extend max_length to 4096 tokens. This would allow for longer e-mail messages, including conversations/threads, to be summarized. It may also improve its summarization capabilities and unlock the performance needed to draft responses in the user's writing style. With this would come a further need for prompt engineering as another template would be required.

Built With

Share this project:

Updates

posted an update

Instructions to run:

  1. Open the notebook in Colab
  2. Modify the slides at the top to use your credentials for the respective services/APIs provided
  3. Run all the slides - the last one will provide the user interface

Log in or sign up for Devpost to join the conversation.