DEV Community: Aris Pattakos

Turn Text Into Structured Data Using JavaScript & OpenAI's GPT

Aris Pattakos — Thu, 22 Feb 2024 17:22:40 +0000

Human languages are incredibly diverse and can describe an infinite amount of things, but most computer programs are not able to understand texts, at least not without preprocessing.

You can do very useful things once you get structured data out of large pieces of text:

Perform statistical analyses
Analyse sentiments
Build product features, such as summarisation
Extract properties to store in your data warehouse

This used to be much harder before the era of LLMs, and required more sophisticated knowledge of Natural Language Processing techniques. GPT and other models have made analysing large texts really accessible. It is worth noting that results are not always reliable, but the same caveat holds true with many other text processing techniques.

Let's look at a real example that will show you how to convert unstructured data into a useful structured format.

Extract Best Dishes From Restaurant Reviews

Let's say you're working with a chain of pizzerias and they want to figure out the dish that customers love the most. They have thousands of customer reviews that they can draw insights from, but it would take ages for a human to read everything and report back the results.

This type of problem is solvable using NLP methods such as NER (Named Entity Recognition) or other forms of rule-based matching. LLMs can make these problems a lot easier to solve, because you only need to:

Write a good prompt.
Call an API with the prompt and the data you want processed.

Let's take it step-by-step

Note: If you'd like to follow along, you can find 20 example reviews in this GitHub Gist. In our code we only have a few to keep things short.

const reviews = [
  {
    reviewText:
      "Absolutely loved the Margherita pizza here! The crust was just perfect.",
  },
  {
    reviewText:
      "The spaghetti carbonara was a bit too salty for my taste. Might try something else next time. The garlic bread was really good though.",
  }
  // ... find more reviews here: https://gist.github.com/arisp8/db7a2516e40ca9b84b18a6a19da36962
];

If you read through the reviews, you can see that some of them mention multiple dishes. Additionally, people might spell the same dish in many different ways (e.g. "Margherita pizza" VS "Pizza Margarita" VS "margarita")

Our goal is to find the most popular dish that people keep clamouring for so we can feed that back in our report.

First, experiment with prompts

Let's break down what I'm doing here:

First, I'm providing some context so that GPT knows what I'm trying to achieve. I am very specific in telling that scores should be negative, neutral, or positive.
I provide an example JSON of how I want the data to look like. This is important because otherwise you risk getting an inconsistent structure that wouldn't be easy to work with.
I note that the response should only include JSON, and no text or explanations.
And then I include the review text that I want to process.

And this is the result:

Now that I found a prompt that works, I will use the OpenAI package inside Node.js to get the results in a programmatic way.

Get results through the OpenAI API

I'll use the latest GPT3.5-turbo model, because it offers the lowest prices while being generally reliable.

I'm starting a new Node project and I'll use the official OpenAI NPM package to get chat completions. (The full guide on how to use chat completions can be found here)

First, you'll need to import the openai package and set your API key.

import OpenAI from "openai";

const openai = new OpenAI({
  apiKey: "your-api-key-here",
});

Now we need to create a system prompt. That is a set of instructions that explains what sort of output we're expecting.

const systemPrompt = `I am doing a large scale analysis of pizzeria reviews.
I want you to extract the dishes that customers mention in their reviews
and give them a score that is "negative", "neutral", or "positive"
depending on whether customers liked the dish or not. Dishes must be
things that you expect to see in a menu (Pizza, Pasta) but not things
like "water", "napkins", "crust" or specific attributes of the dishes (flavour, sauce, etc.).

Use this format for the resulting JSON object:
{
  "dishes": [
      {
          "name": "[dish name]",
          "sentiment": "[sentiment]"
      }
  ]
}
`;

I took the prompt that I created earlier, and I tweaked certain things to increase the chance of getting the right results. As an example, you can see that I explained that "water" or "crust" are not considered dishes, so that we don't get sentiment scores for these.

Next, I defined a function called analyseReview that accepts a review text and returns the results in a JSON format. I used the response_format property in the API call, so that the result is guaranteed to be valid JSON.

const analyseReview = async (reviewText) => {
  const chatCompletion = await openai.chat.completions.create({
    // 💡 Important: By setting the response_format to json_object
    // we guarantee that we'll receive a response that is valid JSON.
    response_format: { type: "json_object" },
    // This model is very cheap and accepts up to 16k tokens
    model: "gpt-3.5-turbo-0125",
    messages: [
      {
        role: "system",
        // Here we pass the system prompt
        content: systemPrompt,
      },
      {
        role: "user",
        // And here we pass the review text
        content: `Review Text: ${reviewText}`,
      },
    ],
  });
  // And finally we return the JSON that is returned from the OpenAI API
  return JSON.parse(chatCompletion.choices[0].message.content);
};

And now for the final step: I loop through all the reviews and use an object to aggregate the results. This should give us an idea of how many people like each dish.

async function main() {
  const result = {};
  for (const review of reviews) {
    const analysis = await analyseReview(review.reviewText);
    analysis.dishes.forEach((dish) => {
      const key = dish.name.toLowerCase();
      if (!result[key]) {
        result[key] = { positive: 0, neutral: 0, negative: 0 };
      }
      result[key][dish.sentiment]++;
    });
  }
  console.log(result);
}

main();

I tried running it with a small sample of reviews, and the most liked dish is the Mushroom Pizza! It's impressive how a few lines of code can get you this result, without depending on NLP methods.

I tried running it with a small sample of reviews, and the most liked dish is the Mushroom Pizza! It's impressive how a few lines of code can get you this result, without depending on NLP methods.There are obviously various improvements that you can add to this approach - this is meant purely as a proof of concept and an idea that you can take with you if you encounter a problem of this nature.

One issue that I noticed is that "margherita pizza" and "margarita" are treated as two separate dishes, even though they're the same. To improve the accuracy of the results, you can improve upon the systemPrompt by specifying all the menu items and instructing GPT to match different spellings for each of the dishes.

At the end of they day, this a process that requires trial & error, and the example is by no means a one-size-fits-all. I suggest that you try various different prompts until you find the one that works best in your specific case.

Conclusion

You can now use the methods above to extract structured data from any piece of text, and use the data for subsequent analyses. There are tons of other examples where you can use this approach to build cool features more easily than before:

Ask GPT to extract the main talking points from a conversation or transcript.
Do SWOT (Strengths, Weaknesses, Opportunities, Threats) analysis based on a company's website content.
Classify media articles based on various attributes that you're interested in.

If you're interested in trying this out, you can find a complete code example on GitHub.

Master TypeScript Quality with This Essential Checklist

Aris Pattakos — Mon, 12 Feb 2024 19:00:00 +0000

When I started using TypeScript it felt really simple. But in a sense, it also felt like I was just writing JavaScript with some extra effort on top to maintain types. I couldn’t see all the value it had to offer, at least not immediately.

It took me some time to start realising the benefits of using TypeScript, and the things that I need to be careful with. After a lot of trial & error, I have learned how to make good use of TypeScript and it’s one of the most important tools that I have available.

Good TypeScript protects you from bugs and makes collaboration with others much easier. Bad TypeScript, on the other hand, can give you false confidence while allowing numerous bugs through.

Whenever I’m looking at TypeScript code, I ask myself the following questions to ensure that I’m making the best possible use of the language.

Am I silencing type checks?

TypeScript is designed as a superset of JavaScript. This means that a JavaScript program, with no typing rules at all, is still considered valid TypeScript. This design decision, means that you can easily have code that’s not type-checked within your TypeScript code.

This flexibility is useful when migrating from JavaScript to TypeScript. But when your project is built in TypeScript, you shouldn’t be silencing type checks because it defeats the purpose of using it.

You should use strict mode when building a TypeScript project, but even then there are ways to silence type checks:

Using any
Using // @ts-ignore
Making unsafe type assertions with x as unknown as MyType

Using any or // @ts-ignore silences type checks, and should rarely ever be used in production code. Type assertions have their uses, but you should make sure that using them is not just a way to silence type checking.

Does the Type represent a valid state?

Types should always represent something that can really happen inside of your code. A common symptom of this problems is when your types allow certain combinations of values that are theoretically impossible.

Let’s say we have 2 kinds of products in our app: shoes & t-shirts. This is a Type that you might often see in such cases, but there’s a problem with it. Can you spot it?

type Product = {
  kind: "tshirt" | "shoes";
  price: number;
  shoeSize?: number;
  tShirtSize?: 'S' | 'M' | 'L';
};

As far as TypeScript is concerned, the product can have both shoeSize and tShirtSize available at the same time. Or the kind might be tshirt and tShirtSize might be missing. We know that these cases shouldn’t be possible based on our application logic, so how do we let TypeScript know that as well?

We’ll use Discriminated Unions to handle this case where one property (kind) gives us information about what other properties will be available.

type BaseProduct = {
  id: number;
  price: number;
}

type ShoesProduct = BaseProduct & {
  kind: 'shoes';
  shoeSize: number;
}

type TshirtProduct = BaseProduct & {
  kind: 'tshirt';
  tShirtSize: 'S' | 'M' | 'L';
}

type Product = ShoesProduct | TshirtProduct;

const product = getProductById(1);
if (product.kind === 'shoes') {
  // TypeScript knows that `product` is a `ShoesProduct` here
  // so we can safely access the `shoeSize` property.
  console.log(product.shoeSize);
}

In the example above you can see how this no longer supports impossible sets of values, and the types closely match the application logic.

A lot of times you also have properties that are defined together and undefined together. Let’s say that you have a type called Photo in your codebase which might have a set of coordinates (lat & long). In this pair of values, you can either have both or none. Having just one of them defined is an impossible state.

type Photo = {
  url: string;
  lat?: number;
  long?: number;
};

How might you fix the example above? Given that we know that lat and long follow each other, we can group them under a new property.

type Photo = {
  url: string;
  coordinates?: {
    lat: number;
    long: number;
  }
};

This is much better now, as coordinates either has both values or none of them. This means that we turned an impossible state into one that matches our actual logic.

Is there redundant code?

DRY in software engineering stands for Don’t Repeat Yourself. As in any programming language or paradigm, TypeScript code can end up being overly wordy and contain redundant code.

A common reason for repeated code in TypeScript is not relying on inference. Inference is TypeScript’s ability to understand (infer) a lot of types automatically. Here are some examples of how you can use inference to avoid redundant types.

// Assuming you have a method that returns a User type
interface User {
  id: string;
  name: string;
}

class UserService {
  getUser: (id: string) => User;
}

const userService = new UserService();
const user: User = userService.getUser('123');

In the example above, we’ve explicitly typed the user variable, but that was completely unnecessary. We can make our code easier to read by removing the explicit type.

const user = userService.getUser('123');

Since getUser returns a User object, TypeScript knows the type that the user constant will have.

Let’s look at some more examples.

// ❌ The explicit return type is unnecessary
const isOddNumber = (number: number): boolean => number % 2 === 1;

// ✅ Since we're returning a condition, TypeScript
// already knows it's a boolean
const isOddNumber = (number: number) => number % 2 === 1;

// ❌ TypeScript already knows it's a string based on the definition
let name: string = 'Full Name';

// ✅ We can make our code tidier like this
let name = 'Full Name';

Explicit types do have their uses. Sometimes you want code that’s short and easy to read, and other times you want to confirm that you’re returning the right thing. You will need to use your judgement as to which approach is suitable each time.

Is the Type as narrow as it can be?

Types are sets of possible values. When we define something as string it can be any string you can imagine, but it can’t be a number. The type string though is quite wide, and there may be cases where the possible set of values that we expect is much more narrow.

The possible status for an order, might be one of the values in this code example below.

// ✅ Using unions to define narrower
// types can be very helpful
type OrderStatus = 'Pending' | 'Processing' | 'Completed' | 'Cancelled';

Using a union or an enum has a lot of upside, compared to defining status as a string:

The union or enum acts as documentation for other engineers to know the set of possible values.
TypeScript will alert you when there’s a typo, or when these values are compared with values that would never be equal (e.g. orderStatus === 'Pnding' could never be true because it’s not in the set)
Your editor will provide improved auto-complete suggestions.

Am I future-proofing my code?

One of the things I personally love about TypeScrips is the toolset that it provides for future-proofing your code. Let’s look at a JavaScript example to illustrate code that isn’t future-proofed.

const messageForRole = {
  admin: "Hello Admin",
  user: "Welcome back!",
};

const user = getUserById(1);
console.log(messageForRole[user.role]);

What would happen if we added a new user role, say guest, but we forgot to change messageForRole? In this case we would obviously get an undefined value which can introduce bugs or cause runtime errors.

With TypeScript, we can create a type for roles and we can guard against problems like the one above. By using Record<UserRole, string>, we tell JavaScript that messageByRole must cover all roles to be a valid object. The error message protects from deploying faulty code to production and allows us to solve the issue easily.

type UserRole = 'admin' | 'user' | 'guest';
const messageByRole: Record<UserRole, string> = {
  admin: "Hello admin",
  user: "Welcome back"
};
// Property 'guest' is missing in type '{ admin: string; user: string; }'
// but required in type 'Record<UserRole, string>'.

Other issues of this kind are harder to spot because they don’t lead to language errors, but logical errors. For example, if you expect an action to happen based on a set of conditions, JavaScript doesn't have a good way of telling you to add new actions whenever new conditions are introduced.

const sendMessageToUser = (user, message) => {
  if (user.communicationMethod === 'email') {
    console.log(`Emailing ${user.name}: ${message}`)
  }
  if (user.communicationMethod === 'sms') {
    console.log(`Texting ${user.name}: ${message}`)
  }
  // If 'telegram' was added, this function would just do nothing
}

In this last example, if we added a new communicationMethod and didn’t update sendMessageToUser then the function would just do nothing! And that could be hard to spot because we wouldn’t see any errors immediately.

To account for the scenario above, which can occur quite often in real-life code, we can use exhaustive checks.

type User = {
  name: string;
  communicationMethod: "email" | "sms" | "telegram";
};

const assertNever = (value: never) => {
  throw new Error(`Unexpected value: ${value}`);
};

const sendMessageToUser = (user: User, message: string) => {
  switch (user.communicationMethod) {
    case "email":
      // sendEmail(user.name, message);
      break;
    case "sms":
      // sendSms(user.name, message);
      break;
    default:
      assertNever(user.communicationMethod);
    // Argument of type 'string' is not assignable to
    // parameter of type 'never'.
  }
};

TypeScript is able to narrow down the possible values. If case "email" is not true, then TypeScript narrows down the type to “sms” or “telegram”. And then, if “sms” is also not true, then the only remaining option is “telegram”. Since we haven’t covered that case, we end up calling assertNever which expects a never type, with a string (“telegram”) which obviously TypeScript is not happy about.

This acts as useful reminder that forces you to check something in the future whenever certain underlying types change. You can use this approach to force yourself to think whenever a change happens.

Conclusion

TypeScript has a lot of fancy operators that can be useful to learn, but not all of them add a ton of value to your codebase. The questions and advice that I listed above are the ones that I believe are the most important to keep in mind when you’re think about the question “Is my TypeScript code good?”.

All of the examples here are simplistic, but they do illustrate how TypeScript can help you in various situations and how you can make the best possible use of it. I encourage you to try them in your personal projects or your work, and I’d love to hear your comments.