Speaker 1: Okay, let's untack this. What if you could take the
Speaker 1: raw power behind tools like chat GPT and mold it
Speaker 1: to your exact needs. We're talking about going beyond just
Speaker 1: you know, chatting with an AI to actually building intelligent
Speaker 1: applications and specialized assistants.
Speaker 2: Exactly Today, our deep dive is all about the open
Speaker 2: Ai API, focusing on how it empowers well anyone really
Speaker 2: to create custom AI solutions. Our main source for this
Speaker 2: is Henry Habib's Open Ai API Cookbook, which Packed Publishing
Speaker 2: put out in March twenty twenty four.
Speaker 1: And Henry Habib he knows his stuff over a decade
Speaker 1: and AI and productivity right, and he's a big believer
Speaker 1: in this citizen developer idea that you don't need to
Speaker 1: be like a hardcore coder to build amazing things. He's
Speaker 1: also the guy behind the Intelligent Worker newsletter.
Speaker 2: That's right, and Sam Mackay, the CEO of Enterprise DNA.
Speaker 2: He actually calls the book an essential guide for knowledge
Speaker 2: workers eager to harness the power of open AI and
Speaker 2: chat GPT to build intelligent applications and solutions. High praise.
Speaker 1: So your mission for this, a deep Dive listener, is simple,
Speaker 1: get a shortcut really understand how to use the open AIAPI.
Speaker 1: We're focusing on the practical stuff, those real aha moments.
Speaker 1: You've heard of AI chat GPT. They're everywhere, constantly talked about.
Speaker 1: But what's cool here is how actionable they are. We're
Speaker 1: going to show you how to turn ideas into reality.
Speaker 1: Let's start with the basics. Why the API matters. It's
Speaker 1: more than just the chat box you see online. I mean,
Speaker 1: chat GPT's growth was just insane, wasn't it. One hundred
Speaker 1: million users in two months. That's faster than TikTok, which
Speaker 1: took what nine months. It really brought natural language processing
Speaker 1: NLPE to the masses.
Speaker 2: Absolutely, and the API it takes that democratization way further.
Speaker 2: It's a genuine paradigm shift. It means anyone can generate
Speaker 2: really human like text from simple prompts. You don't need
Speaker 2: a PhD in machine learning anymore. It's not just for
Speaker 2: the big players like Typeface or Jasper Ai building on
Speaker 2: top of it. It's for you integrating that power into
Speaker 2: your own stuff.
Speaker 1: And the open II Playground is kind of the perfect
Speaker 1: place to start messing around. Yeah, like a sandbox. It's
Speaker 1: got three main parts the system message, the chat log,
Speaker 1: and then the parameters. The system message is where you
Speaker 1: tell the AI who it should be, like you are
Speaker 1: an assistant that creates marketing slogans, simple as that shapes
Speaker 1: its whole persona right.
Speaker 2: And it's fascinating because the model isn't understanding like we
Speaker 2: do no thoughts, no feelings. Think of it more like
Speaker 2: super advanced autocomplete. It predicts the next word based on
Speaker 2: patterns from tons of text data. So you put examples
Speaker 2: in the chat log, say you give it company makes
Speaker 2: ice cream, and then that apply sham the ice cream
Speaker 2: that never melts. You're guiding those predictions. You're kind of
Speaker 2: training it right there to follow patterns like starting with
Speaker 2: sham and ending with an exclamation.
Speaker 1: Mark that makes sense, guiding the probabilities. Okay, so once
Speaker 1: you've got your prompts working well in the playground, you
Speaker 1: move on to making real API requests, maybe using something
Speaker 1: like postmam. And this is where it gets really powerful
Speaker 1: because you're not just watching it work, you're controlling it
Speaker 1: with code programmatically. And for an API request, there are
Speaker 1: like four main things you need. Right First is the
Speaker 1: endpoint that's URL, the address you're sending the request to
Speaker 1: like https, dot API, dot openI, dot com, forward slash
Speaker 1: v one chat completions exactly.
Speaker 2: Then there's the header. Think of this as containing important metadata.
Speaker 2: It tells open Ai what you're sending, usually content type
Speaker 2: dot application JSON because Jason is just a standard way
Speaker 2: for systems to swap structured data. And critically, it says
Speaker 2: who you are with your authorization bearer, your API key.
Speaker 2: That's your secret handshake with open Ai.
Speaker 1: Okay, So header is like the envelope details, and the
Speaker 1: body is what's inside the envelope.
Speaker 2: Correct. A body is a Jason object. It holds the
Speaker 2: specifics like which model you want to use, and the
Speaker 2: messages that's your system message and chat log content. And
Speaker 2: finally you get the response back from open Ai. That's
Speaker 2: also Jason containing the AI's output. It's choices and usage
Speaker 2: data like how many tokens you used?
Speaker 1: Cool? But okay, let's break out of just text. The
Speaker 1: open Ai API can do more than just words, can't it?
Speaker 1: Multimodal stuff? Oh?
Speaker 2: Absolutely, Beyond text. You've got image generation with Dally. The
Speaker 2: newer versions Dally two and three use this technique called diffusion.
Speaker 2: You can kind of picture it like starting with TV
Speaker 2: static and slowly clearing it up until an image appears.
Speaker 2: It's pretty neat. But the key with images, unlike text maybe,
Speaker 2: is you have to be super specific in your prompts.
Speaker 2: Just saying a dog gets you, well, a random dog,
Speaker 2: but a brown, furry, medium sized CORKI doog on a
Speaker 2: green grass field profile view that gets you much closer
Speaker 2: to what you actually want. It raises an interesting point.
Speaker 2: Text generation can infer context sometimes, but image generation it
Speaker 2: needs precise descriptive language. Ambiguity is your enemy here.
Speaker 1: Good point need to be crystal clear. And it does
Speaker 1: audio too. Transcripts.
Speaker 2: Yeah, the audio endpoint uses the Whisper model for that.
Speaker 2: It transcribes audio files.
Speaker 1: Ah and technically for file uploads you need to use
Speaker 1: form data instead of JSON in.
Speaker 2: The request right exactly. Jason is great for text data,
Speaker 2: but form data is built for sending files, kind of
Speaker 2: like attaching something to an email. It handles lots of
Speaker 2: formats dot MP three, dot MP four, dot MPEG, dotwave,
Speaker 2: dot web, dot WebM quite a few.
Speaker 1: So you could transcribe a meeting maybe easily.
Speaker 2: And the real magic starts when you chain these things together.
Speaker 2: Imagine a voice assistant. Voice comes in whisper transcribes it,
Speaker 2: chat Api figures out a response, maybe Dali even generates
Speaker 2: relevant image.
Speaker 1: Okay, that's starting to sound really powerful. Now, let's talk
Speaker 1: about fine tuning the dials and knobs as you called
Speaker 1: them in the book.
Speaker 2: The parameters, right, The parameters let you control the AI's behavior,
Speaker 2: and the model parameter is probably the biggest one. Usually
Speaker 2: you're choosing between GPT three point five and GPT four.
Speaker 2: GPT three point five has what one hundred and seventy
Speaker 2: five billion parameters. GPT four is estimated to be way larger,
Speaker 2: maybe over one hundred trillion parameters across a bunch of
Speaker 2: models working together. More parameters generally means the model is
Speaker 2: better at capturing subtle patterns and understanding complex instructions. So
Speaker 2: GPT four tends to be more reliable, better with nuance.
Speaker 2: It actually scores higher on things like standardized tests, EP calculus.
Speaker 1: The lsat Wow, and you can see that difference in
Speaker 1: the outputs. Can't you like that example in the book
Speaker 1: asking for a sentence about Mars with six five letter words,
Speaker 1: GPT three point five up the word count right, It
Speaker 1: gives our Mars strip felt vast, new, cold.
Speaker 2: Hard, grand grand isn't five letters.
Speaker 1: Exactly If GPT four gets it, Mars Red World, Brave Crew,
Speaker 1: Deep Space finds life. Perfect for the cigarette question how
Speaker 1: many chemicals? How many harmful? How many cause cancer? Just
Speaker 1: the numbers. GPT three point five gives you a paragraph.
Speaker 1: GPT four just answers two hundred and fifty sixty concise
Speaker 1: even logic puzzles. GPT four tends to reason more accurately
Speaker 1: than three point five, and GPT four has a bigger
Speaker 1: memory too. The context win much bigger.
Speaker 2: Like GPT four thirty two k can handle around thirty
Speaker 2: two thousand tokens maybe twenty four thousand words. GPT three
Speaker 2: point five max is out around four thousand tokens about
Speaker 2: three thousand words. Big difference if you're feeding it long documents.
Speaker 1: Okay, but there's a catch, isn't there cost?
Speaker 2: Huge catch? GPT four can be twenty to forty times
Speaker 2: more expensive per token than GPT three point five. It's significant.
Speaker 2: So the practical advice for you is always start with
Speaker 2: GPT three point five. If it does the job great,
Speaker 2: you save a lot of money. Only upgraded GPT four
Speaker 2: if you absolutely need that extra reasoning power or the
Speaker 2: larger context window.
Speaker 1: That's a massive cost difference. Why is it so much
Speaker 1: more just the size.
Speaker 2: Primarily, Yeah, it's a much bigger, more complex model. Just
Speaker 2: takes way more computing power to run each request. Think
Speaker 2: supercomputer versus calculator.
Speaker 1: Gotcha? Okay, another parameter dot N that controls how many
Speaker 1: answers you get back right.
Speaker 2: N sets the number of responses can be any whole
Speaker 2: number for chat, but max ten for images. Super useful
Speaker 2: for brainstormings, logans, getting different options, or for checking consistency,
Speaker 2: maybe ab testing outputs.
Speaker 1: And the interesting thing you mentioned is the cost isn't
Speaker 1: linear like N three isn't three times the price?
Speaker 2: No, it's often much less, maybe sixty percent more, not
Speaker 2: two hundred percent more, which tells you something cool. The
Speaker 2: AI isn't just running the request three times separately. It's
Speaker 2: likely batching the computation somehow finding efficiencies. It's an optimization
Speaker 2: hint clever.
Speaker 1: Okay, what about temperature? That one sounds a bit abstract.
Speaker 1: Controls creativity.
Speaker 2: Yeah, temperature basically controls the randomness or let's say, creativity
Speaker 2: of the output. It goes from point zero to two
Speaker 2: point zero th of it, like tuning a radio. Low
Speaker 2: temperature maybe twoint zero too point eight is like a sharp,
Speaker 2: clear signal, very focused, consistent factual responses. Good for things
Speaker 2: like code generation data analysis where you want deterministic.
Speaker 1: Output and higher temperature more static, more like an eclectic
Speaker 1: mix station.
Speaker 2: Yeah, higher temps, say one point two to two point zero,
Speaker 2: make the AI take more risks with word choices. It
Speaker 2: flattens the probability curve for the next word, so you
Speaker 2: get more diverse, unexpected sometimes more creative results. Great for brainstorming,
Speaker 2: writing stories, generating slogans.
Speaker 1: So for general use like a chatbot, maybe somewhere in
Speaker 1: the middle point eight to one point two exactly.
Speaker 2: Balance is making sense with being interesting.
Speaker 1: So the advice is start around one point zero and
Speaker 1: tweak it by like zero point two increments.
Speaker 2: That's a good practical approach. Yeah, see what works for
Speaker 2: your specific need.
Speaker 1: Okay, makes sense. Now let's shift gears to building real applications.
Speaker 1: Usually you don't just have your app talk directly to
Speaker 1: open AI, right, there's often a back end layer in between.
Speaker 2: That's right. The typical flow is from tend what the
Speaker 2: user sees talks to your back end, and your back
Speaker 2: end talks to the open AIAPI. This back end layer
Speaker 2: is crucial. First security, it keeps your precious API key
Speaker 2: safe hidden from the user's browser. Second control, you can
Speaker 2: process the input before it goes to open AI or
Speaker 2: clean up the output after it comes back. Plus it
Speaker 2: lets you integrate other services, hand logins, all that stuff.
Speaker 1: And for that back end, serverless options like Google Cloud
Speaker 1: functions are pretty popular.
Speaker 2: Very popular, yeah, because you don't have to manage servers.
Speaker 2: It just scales automatically. You write your code, upload it,
Speaker 2: and Google handles the rest. You set up an HTTP
Speaker 2: trigger so it could be called like a web address.
Speaker 2: Allow unauthenticated calls maybe for testing, but be careful in
Speaker 2: production and define your entry point function.
Speaker 1: And then for the front end the user interface. You
Speaker 1: can use no code tools like Bubble, so anyone can
Speaker 1: build the app part exactly.
Speaker 2: Bubble lets you visually design your web app and connect
Speaker 2: buttons and inputs directly to your back end cloud function.
Speaker 2: It's incredibly empowering.
Speaker 1: Let's walk through an example, like that email reply wrapper
Speaker 1: from the book. You could do it in chat GPT, sure,
Speaker 1: but building it yourself really teaches you the whole process.
Speaker 1: So you start in the playground testing proms, get the
Speaker 1: Python code, then you put that logic into a Google
Speaker 1: Cloud function that's your back end. It takes the email
Speaker 1: text as input, adds your API key. Secretly, you'd tell
Speaker 1: it to use say GPT four, maybe a higher temperature
Speaker 1: like one point four for creator replies, set N three
Speaker 1: to get three options, maybe limit topens to five to one.
Speaker 2: Right, and then you'd use Postman to test that cloud
Speaker 2: function directly, make sure it actually returns three email replies
Speaker 2: in the format you expect. Once that's working, you jump
Speaker 2: into Bubble. You build the input box for the original email,
Speaker 2: a button to generate replies, and maybe three textboxes to
Speaker 2: display choice one, choice two, choice three. Use bubbles API
Speaker 2: connector to link the button press to your cloud function
Speaker 2: URL and display the return choices. And really understanding this
Speaker 2: whole playground, Cloud function, Postman, Bubble. That's the fundamental pattern.
Speaker 2: Master this and you can pretty much any intelligent app.
Speaker 1: That's a great point. It's the core loop. What's a
Speaker 1: common sticking point when people first try this? Getting the
Speaker 1: data flow right often.
Speaker 2: Yeah, getting the JSON right in the requests and responses,
Speaker 2: making sure API keys are correct and secure, little syntax things.
Speaker 2: Postwind really helps debug that before you even touch the frontend.
Speaker 1: Okay, so that's a solid foundation. But let's get to
Speaker 1: something really cool, something you can't just do in the
Speaker 1: standard chat GPT interface easily. The multimodal travel itinerary app.
Speaker 1: That sounds awesome.
Speaker 2: It really shows the power of orchestrating multiple API calls.
Speaker 2: The idea user toxicity gets back a detailed one day
Speaker 2: plan morning, afternoon, evening activities and three AI generated images
Speaker 2: matching those activities.
Speaker 1: Wow, okay, how does that work behind the scenes in
Speaker 1: the cloud function.
Speaker 2: So first, because this involves multiple calls, including image generation,
Speaker 2: which can be slow, you need to increase the cloud
Speaker 2: function's timeout limit maybe to three hundred seconds five minutes,
Speaker 2: just to be safe.
Speaker 1: Good practical tip.
Speaker 2: Then one uber one uses the chat api GPT four. Specifically,
Speaker 2: it takes the city name. Crucially, you give it a
Speaker 2: detailed chat log with examples what the book calls fu
Speaker 2: shot prompting. You showed examples for Rome, Lisbon, et cetera.
Speaker 2: Format it exactly how you want warning activity, afternoon activity,
Speaker 2: evening activity. This force is GPT four to follow that
Speaker 2: structure precisely. It stores the resulting itinerary text.
Speaker 1: Got it. So the structure comes from good prompting and examples.
Speaker 1: How do the images get generated?
Speaker 2: That's call number two, also chat API, but this time
Speaker 2: using GPT three point five Turbo one one oh six.
Speaker 2: Its only job is to take the itinerary text from
Speaker 2: call one and create three short descriptive prompts suitable for DELI.
Speaker 2: Like if the itinerary mentioned the Colisseum, Vatican and Trevy Fountain,
Speaker 2: it might output Colisseum and Rome, Vatican City Interior, Trevy
Speaker 2: Fountain at night. Just the prompts separated by a pipe symbol.
Speaker 1: Ah. And you use GPT three point five here because
Speaker 1: it's cheaper and the task is simple. It doesn't need
Speaker 1: GPT four's nuance exactly.
Speaker 2: The user never sees this intermediate p output, only the
Speaker 2: final images, so three point five is perfectly adequate and
Speaker 2: much more cost effective for this specific step.
Speaker 1: Smart resource use nice optimization. Okay, So now you have
Speaker 1: the itinerary text and three image prompts.
Speaker 2: Right, So call number three hits the images API using
Speaker 2: DELI THII. Your code loops through the three prompts from
Speaker 2: call too, making a separate API call for each one
Speaker 2: to generated image. It collects the URLs of the three
Speaker 2: generated images image rolls Finally, the cloud function bundles everything
Speaker 2: up and returns a single Jason response containing the itinerary
Speaker 2: text and the URLs for morning image, afternoon image, and
Speaker 2: evening image.
Speaker 1: And then in bubble you just connect those pieces input
Speaker 1: for city button, a big text area for the itinerary,
Speaker 1: and three image elements. You map the JSON fields from
Speaker 1: the cloud function response directly to those elements. That's really slick,
Speaker 1: combining text and custom images on the fly like that.
Speaker 2: Very cool. Okay, let's switch tracks slightly. Building knowledge assistance
Speaker 2: this is huge. Standard chat GPT is great, but its
Speaker 2: knowledge is kind of frozen in time right, and it
Speaker 2: can sometimes just make stuff up hallocin. You can't easily
Speaker 2: to only use this specific document precisely.
Speaker 1: That's where building your own assistant comes in, using the
Speaker 1: API combined with your specific trusted knowledge source. A basic
Speaker 1: way to do this covered in the book is PDF analysis.
Speaker 1: Your app takes a PDF link and a question. The
Speaker 1: cloud function fetches the pdf, uses a library like pipdf
Speaker 1: two to scrabe all the text out of it. Then
Speaker 1: it stuffs that entire text into the prompt along with
Speaker 1: the user's question, and sends it off to GPT four
Speaker 1: so it just crams the.
Speaker 2: Whole PDF into the context window every single time. Yeah, coefficient,
Speaker 2: it can be. It works, but yeah, limitations. It only
Speaker 2: gets text, no images from the pdf. It struggles with
Speaker 2: really huge documents, and the biggest issue is that context
Speaker 2: window limit. If your PDF has more words then the
Speaker 2: model can handle like those three thousand words for GPP
Speaker 2: three point five or twenty four thousand for GPT four
Speaker 2: thirty two. K. It just won't work properly, right.
Speaker 1: But there's a better way now, isn't there with the
Speaker 1: newer assistance API.
Speaker 2: Oh yeah, the assistants APIs specifically with its built in
Speaker 2: knowledge retrieval tool, is a total.
Speaker 1: Game changer for this What makes it so different.
Speaker 2: It's incredibly smart. When you upload your documents, PDFs, word docs, etc.
Speaker 2: To an assistant with retrieval enabled, open AI automatically handles
Speaker 2: the hard parts. It breaks the documents into manageable chunks,
Speaker 2: creates embeddings for each chunk, those unique numerical fingerprints we
Speaker 2: talked about, and stores them efficiently. Then when you ask
Speaker 2: a question, it uses vector search to instantly find only
Speaker 2: the most relevant chunks of texts from your documents related
Speaker 2: to your question.
Speaker 1: So It doesn't read the whole document every time, It
Speaker 1: just finds the relevant paragraphs.
Speaker 2: Exactly, which means there's effectively no context window limit for
Speaker 2: your knowledge base. You can upload massive files or hundreds
Speaker 2: of documents and the assistant intelligently retrieves only the necessary
Speaker 2: snippets to answer the question. Incredibly efficient.
Speaker 1: That sounds amazing. How do you set that up? Still?
Speaker 2: Start in the playground, yep, The playground is great for
Speaker 2: creating the assistant itself. You give it a name US
Speaker 2: Constitution Expert Instructions answer questions based only on the provided
Speaker 2: constitution document. Choose a model like GPT four to eleven
Speaker 2: oh six Preview, which is good for this. Then the
Speaker 2: crucial step you toggle on the retrieval tool and then
Speaker 2: you upload your knowledge file like a PDF of the
Speaker 2: US Constitution. Once it's created, you grab the unique assistant ID.
Speaker 1: Okay, assistant created, knowledge uploaded. Then the cloud function code
Speaker 1: uses this assistant ID.
Speaker 2: Correct. The Python code for your cloud function becomes a
Speaker 2: bit different using the assistants API. First, you create a thread.
Speaker 2: Think of thread as a single conversation session. Then you
Speaker 2: add the user's question as a message to that thread. Next,
Speaker 2: you tell the assistant to run on that thread, providing
Speaker 2: the assistant ID and the thread ID. Now here's a
Speaker 2: key detail for the book's code. You need to wait
Speaker 2: a bit. The assistant needs time to process, search the
Speaker 2: knowledge and formulate the answer, so you might add a
Speaker 2: time dot sleep or similar pause. After the pause, you
Speaker 2: retrieve the list of messages from the thread and the
Speaker 2: assistem's answer will be the newest message.
Speaker 1: Okay, that pause is important. And the bubble front end
Speaker 1: for this probably simpler.
Speaker 2: Much simpler for this use case. Yeah, just an input
Speaker 2: boxer the user's question, a button and a text box
Speaker 2: to display the answer returned by the cloud function.
Speaker 1: And the result is you can ask specific questions like
Speaker 1: how many senators are there or what's the age requirement
Speaker 1: for a senator and it pulls the answer directly from
Speaker 1: that constitution pdf you uploaded exactly.
Speaker 2: It grounds the AI in your specific source material. It's
Speaker 2: incredibly powerful for legal teams, medical info, company knowledge bases,
Speaker 2: educational tools, anywhere you need reliable answers from a defined
Speaker 2: set of information.
Speaker 1: Wow, we've covered a lot, from just understanding the API
Speaker 1: basics to playing in the playground, making direct calls, adding
Speaker 1: images and audio. Then building actual apps with back ends
Speaker 1: and frontends, optimizing costs, and finally creating these powerful knowledgeable
Speaker 1: assistance tied to specific documents. You've really gone from just
Speaker 1: using chat GPT to understand how to build with its
Speaker 1: underlying power. You're equipped now to actually create things.
Speaker 2: Yeah, and it brings to mind something Paul Siegel, a
Speaker 2: tech entrepreneur, wrote in the forward to Henry's book, You said, Essentially,
Speaker 2: I strongly encourage you to use this knowledge to create
Speaker 2: your next successful app or business, or simply to enrich
Speaker 2: your thinking about how to innovate. Dream on it, then
Speaker 2: fashion your dreams into a reality with the tools you've
Speaker 2: gained here. I think that sums it up nicely.
Speaker 1: Great final thoughts, So the message is clear, don't just
Speaker 1: use AI, build with it, Go experiment, see what you
Speaker 1: can create.