Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
160 changes: 160 additions & 0 deletions docs/Workshops/Pitching/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,160 @@
---
title: Pitching
sidebar_position: 9
---

## What is a Pitch?

Pitching is telling the story of your project in a **clear**, **engaging**, and **memorable** way. A good pitch helps people understand what you built, why it matters, and why they should care.

At a hackathon, your pitch should answer a few important questions:

- What problem are you solving?
- Why does this problem matter?
- How does your solution work?
- Why should people care about it?

Great projects do not always win. Great presentations can make the difference.

## Why Pitching Matters

Judges do not see every late-night debugging session, design decision, or 24 hours of prompt engineering that went into your project. They only have a few minutes to understand what you made and decide whether it is valuable in the real world.

A strong pitch highlights the **effort**, **impact**, and **technical choices** behind your project. It helps judges see why your project is worth remembering.

## How Does Pitching Work?

At HackUTD, plan for a short pitch window:

- **3 minutes** to pitch
- **2 minutes** for judge questions

A simple pitch flow looks like this:

1. **Problem**: What issue are you solving?
2. **Solution**: What did you build?
3. **Demo**: Show the project working.
4. **Impact**: Why is it useful, interesting, or important?
5. **Questions**: Be ready to explain your decisions.

:::note
Do not treat the pitch like a status update. Treat it like a sales pitch. You are helping judges understand why your project deserves attention.
:::

## Pitching Starts Before the Judges Meet You

Your first impression often happens before your live pitch. Judges may see your Devpost, thumbnail, name, description, or demo video before they talk to you.

Before judging starts:

- Choose a visually compelling Devpost thumbnail
- Keep your demo video under 2 minutes
- Give your project a clear, memorable name
- Make sure your project description explains the problem and solution quickly

## Your Slides Do Most of the Talking

Slides should support your story instead of competing with it. Start from a clean template, then redesign it around your app's color palette and visual style.

Be intentional with every slide. A helpful slide flow is:

| Slide | Goal |
| ---- | ---- |
| What you built | Introduce the project and the core idea |
| Why it matters | Explain the problem, audience, and impact |
| How it works | Show the technical approach or product flow |
| What's next | Explain future improvements or where the project can go |

If your project has a strong visual interface, walk through the product. Judges remember demos more easily when they can see the user experience.

## Own the Room

Pitching is not just about having the right slides. Delivery matters too.

Talk to judges like you are trying to convince someone to invest in your idea. Avoid reading off a checklist. Make eye contact, pass between teammates smoothly, and show that your team understands both the product and the problem.

Practice at least once before the real pitch. Even a quick run-through helps catch awkward transitions, broken demos, and sections that run too long.

### Team Roles

If you are pitching with a team, delegate roles before judging starts.

| Role | Responsibility |
| ---- | -------------- |
| Storyteller | Opens the pitch and explains the problem |
| Demo driver | Controls the live demo or video |
| Tech lead | Explains important technical decisions |
| Closer | Ends with impact, future work, and final takeaway |

:::note
Knowing which track each judge is judging for can help you tailor your pitch. Emphasize the parts of your project that match the track or sponsor challenge.
:::

## Demo Time

Let's practice pitching with something low-stakes first: a hot take.

### Setup

Partner up with one other person. Each person should think of their biggest hot take. It can be about food, tech, school, movies, or anything else that is easy to argue for in a fun way.

You will need:

- A partner
- A timer
- One hot take
- A willingness to sound a little dramatic

### Step 1: Pitch Your Hot Take

Take 2 minutes to pitch your hot take to your partner. Try to make it clear, memorable, and convincing.

Use this structure:

1. State the hot take
2. Explain why it matters
3. Give your strongest evidence
4. End with a confident final takeaway

### Step 2: Answer Questions

Your partner gets 1 minute to ask questions. Stay curious, not argumentative. The goal is to practice thinking on your feet.

### Step 3: Switch Roles

Now switch. Your partner pitches their hot take for 2 minutes, and you ask questions for 1 minute.

### Step 4: Team Up

Pair up with another duo. Choose the best hot take from your group and turn it into a team pitch.

Take 3 minutes to decide:

- Who opens the pitch?
- Who gives the evidence?
- Who handles the counterargument?
- Who closes?

Then pitch to the room.

## Turning This Into a Hackathon Pitch

When you are ready to pitch an actual project, use this template:

```md
We built [project name], a [type of product] for [target audience].

The problem is [problem], which matters because [impact].

Our solution lets users [main user action or benefit].

Here is the demo: [walk through the most important user flow].

We built it using [tech stack], and the most interesting technical part was [technical highlight].

With more time, we would [future improvement]. For now, our project shows that [main takeaway].
```

## Next Steps

Before judging, rehearse your pitch with a timer and make sure your demo is ready. Keep your story simple, make your slides visually consistent with your app, and prepare answers for common judge questions.
61 changes: 61 additions & 0 deletions docs/Workshops/Pitching/resources.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,61 @@
---
title: Resources
slug: resources
sidebar_position: 1
---

## Workshop Links

- Slides - Coming Soon


## Pitch Checklist

- State the problem clearly.
- Explain why the problem matters.
- Name the target audience.
- Explain the solution in plain language.
- Show the project working.
- Keep the demo focused on the most important user flow.
- Mention the most important technical choices.
- Explain impact.
- End with future work or a strong final takeaway.

## Devpost Checklist

- Use a visually compelling thumbnail.
- Keep the demo video under 2 minutes.
- Give the project a clear, memorable name.
- Write a short project description that covers the problem, solution, and impact.
- Make sure screenshots or videos show the product clearly.

## Slide Checklist

- Match the slides to your app's color palette.
- Keep each slide focused on one idea.
- Walk through the product instead of only describing it.
- Include what you built, why it matters, how it works, and what comes next.
- Avoid overcrowding slides with text.

## Pitch Template

```md
We built [project name], a [type of product] for [target audience].

The problem is [problem], which matters because [impact].

Our solution lets users [main user action or benefit].

Here is the demo: [walk through the most important user flow].

We built it using [tech stack], and the most interesting technical part was [technical highlight].

With more time, we would [future improvement]. For now, our project shows that [main takeaway].
```

## Other Resources

- [How to Make a Great Pitch - YC](https://www.ycombinator.com/library/6q-how-to-make-a-great-pitch)
- [HackUTD 2025 Project Gallery](https://hackutd-2025.devpost.com/project-gallery)
- [Devpost Help Center](https://help.devpost.com)

53 changes: 41 additions & 12 deletions docs/Workshops/RAG/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,50 +2,69 @@
title: RAG
sidebar_position: 8
---

## What is RAG?

Retrieval-Augmented Generation (RAG) is a technique that **improves the accuracy** of Large Language Models (LLMs) by allowing them to **access external information**. Instead of relying only on the data they were trained on, a RAG system first retrieves relevant information from a knowledge base and then provides that context to the LLM. This helps **reduce hallucinations** and enables the model to answer questions using **up-to-date** or **domain-specific information**.

## Vector Embeddings

Vector embeddings are **numerical representations** of text that capture its meaning. An embedding model **converts** words, sentences, or document chunks into **vectors**, where **semantically similar** content is placed closer together in **vector space**. This allows a system to **search based on meaning** rather than exact keyword matches, making retrieval more effective for natural language questions.

## Vector Databases

A vector database **stores and indexes embeddings** so they can be searched **efficiently**. When a user submits a question, the question is converted into an embedding and compared against the stored embeddings to find the most similar pieces of content. In this workshop, we use **Pinecone** as our vector database and **cosine similarity** to retrieve the most relevant document chunks for the LLM.

## Demo Time

Let's build our own Poyobot to answer questions about a hackathon a generic LLM would never know.

Before we begin, we need to set up a few things.
### Setup

### Setup

#### Pinecone

1. Head over to [Pinecone](https://www.pinecone.io)
2. Create an account or sign in with Google
3. As soon as you sign in, you should see an API key generated for you, copy that!
![Pinecone API key screen](/img/rag/api_key.png)
![Pinecone API key screen](/img/rag/api_key.png)

4. Head back to the Colab notebook, click on the key icon to add a new secret. Enter the name as shown below and paste the API key in the value. Also make sure to give notebook access.
![Colab secret screen](/img/rag/colab_pinecone_key.png)
![Colab secret screen](/img/rag/colab_pinecone_key.png)

5. Go back to Pinecone and click on Create Index.
![Create index screen](/img/rag/create_index.png)
![Create index screen](/img/rag/create_index.png)

6. Name the index `poyobot` and click on Custom settings. Enter the config shown below and hit Create index.
![db config screen](/img/rag/config.png)
![db config screen](/img/rag/config.png)

#### Gemini API Key

1. Head over to [aistudio.google.com](https://aistudio.google.com) and go to the dashboard to create a new API key or use an existing one.

2. Go back to the secrets tab, name the key as shown and paste it in the value.
![colab secret screen](/img/rag/colab_gemini_key.png)
![colab secret screen](/img/rag/colab_gemini_key.png)

Now that you have everything you need, we can start building Poyobot. Head back to the Colab notebook.


### Step 1: Install Dependencies

In the first cell, we will be installing all the dependencies required to implement this project

```python
!pip install pinecone pypdf google-generativeai sentence-transformers
```

- **pinecone**: SDK to access Pinecone features
- **pypdf**: library to extract data from PDFs
- **google-generativeai**: SDK to access Gemini model
- **sentence-transformers**: library for embedding models

### Step 2: Upload and Extract text from PDF

Now, we will ask the user to upload a PDF, and use pypdf to extract text from it.

```python
from google.colab import files
from pypdf import PdfReader
Expand All @@ -58,10 +77,12 @@ for page in reader.pages:
text += page.extract_text() + "\n"
print(text[:1000]) # Preview first 1000 chars
```

You should be able to see the first 1000 characters in the PDF printed, meaning we're ready to chunk this text.

### Step 3: Chunk and vectorize the text
This is a crucial step that converts our data from just **plain text** into **vectors** which can be stored in Pinecone for our RAG logic.

This is a crucial step that converts our data from just **plain text** into **vectors** which can be stored in Pinecone for our RAG logic.

```python
from sentence_transformers import SentenceTransformer
Expand All @@ -77,14 +98,16 @@ embedder = SentenceTransformer('all-MiniLM-L6-v2')
embeddings = embedder.encode(chunks).tolist()
print(embeddings[0][:5])
```

To review, we first divided our text into chunks every 500 characters, with an overlap of 150 characters to capture the semantics of the text better.

Then, we used the `all-MiniLM-L6-v2` embedding model to convert these chunks into vectors. You don't have to worry about the specifics of this model, just know that it converted our chunks of text into vectors of numbers.
Then, we used the `all-MiniLM-L6-v2` embedding model to convert these chunks into vectors. You don't have to worry about the specifics of this model, just know that it converted our chunks of text into vectors of numbers.
:::note
Check out the resources tab to learn more about this step!
:::
:::

### Step 4: Use Pinecone to store these vectors

We will be using the index we made earlier to store these vectors in Pinecone.

```python
Expand All @@ -107,6 +130,7 @@ index.upsert(vectors = vectors_to_upsert)
```

### Step 5: Take input and generate context

We're almost there. Now we will be taking a **question** from the user and using the same **embedder** model to **vectorize** the question.

After vectorizing, we will be querying this vector against our **vector store** and returning the top 5 most **relevant vectors**.
Expand All @@ -122,11 +146,14 @@ query_results = index.query(
context_chunks = [match["metadata"]["text"] for match in query_results["matches"]]
context = "\n---\n".join(context_chunks)
print("Context:\n", context)
```
```

You should see different chunks of text that are somewhat related to the question asked.

### Step 6: Use Gemini to answer questions from the context

Finally, we will be using the Gemini 2.5 Flash model as our LLM to receive this context and use it to answer our question.

```python
from google.colab import userdata
import google.generativeai as genai
Expand All @@ -139,7 +166,9 @@ prompt = f"Answer the following question using the context given. Context: {cont
response = model.generate_content(prompt)
print("Answer:", response.text)
```

## Next Steps

Good job! You just built a RAG powered chatbot that can accurately answer questions by using relevant context for every question.

This is just the beginning. There are a lot of things you can do with RAG. Check out the resources tab for more!
This is just the beginning. There are a lot of things you can do with RAG. Check out the resources tab for more!
Loading