DEV Community: Rodrigo Gomez Palacio

Automate Fine-Tuning Your LLM Models: the ChatGPT Fine-Tuning SDK

Rodrigo Gomez Palacio — Mon, 17 Feb 2025 21:08:11 +0000

Fine-tuning a ChatGPT model can significantly improve its accuracy and relevance for your specific use case. However, manually preparing datasets for fine-tuning can be tedious. Introducing the ChatGPT Fine-Tuning SDK, an open-source package designed to streamline the process of generating fine-tuning datasets in JSONL format.

🚀 Why Use ChatGPT Fine-Tuning SDK?

This SDK simplifies dataset generation by wrapping around the chatgpt npm package. It provides a structured approach to curating training data while allowing programmatic approval, rejection, and correction of AI-generated responses.

When finished, you will be left with a jsonl file you can upload directly to fine-tune a model.

🔧 Installation

You can install the package using npm or yarn:

# npm
npm install chatgpt-fine-tuning

# yarn
yarn add chatgpt-fine-tuning

⚙️ Configuration

Before using the SDK, configure it with your OpenAI API key and define a system message:

import ChatGptFineTuning from 'chatgpt-fine-tuning';

const outFile = 'fine-tuning-output.jsonl'; // required
const systemMessage = 'Marv is a factual chatbot that is also sarcastic.'; // required

const gpt4Api = new ChatGptFineTuning({
    apiKey: process.env.GPT4_API_KEY || '', // required
    systemMessage,
}, outFile);

🛠 Usage

Each sendMessage call returns a tuner object, which enables:

Approving the AI response
Rejecting an incorrect response
Fixing and correcting AI responses
Logging actions to maintain a record

Example Workflow

const tuner = await gpt4Api.sendMessage("What is the capital of France?");

// Programmatic verification
if (tuner.response.text.includes("Paris")) {
  tuner.approve();
} else {
  tuner.reject();
  tuner.fix("You did not provide the correct answer", "Paris");
}

tuner.log("Finished run");

📖 API Reference

tuner Methods

Method	Parameters	Return Type	Description
`approve()`	-	`Promise<void>`	Approves the current response for fine-tuning.
`reject()`	-	`Promise<void>`	Rejects the response, marking it with a weight of `0`.
`fix(userText, assistantText, log?)`	`string`, `string`, `boolean` (optional)	`Promise<void>`	Submits a correction for the AI response with optional logging.
`log(message)`	`string`	`void`	Logs a message to the output file.

ChatMessage Properties

Name	Type	Description
`id`	`string`	Unique identifier for the chat message.
`text`	`string`	Text content of the message.
`role`	`Role`	Role of the message sender (user, assistant, etc.).
`parentMessageId`	`string` (optional)	ID of the parent message in the conversation.
`conversationId`	`string` (optional)	ID of the conversation this message belongs to.

The API follows the same structure as the chatgpt npm package, ensuring familiarity if you've used it before.

🤝 Contributing

Contributions, bug reports, and feature requests are welcome! Check out the issues page to get involved.

⭐ Show Your Support

If this SDK has been helpful, consider giving it a ⭐ on GitHub!

📝 License

This project is MIT licensed.

Get Started Now!

Fine-tune your ChatGPT models effortlessly with ChatGPT Fine-Tuning SDK and take AI customization to the next level!

To Obfuscate or Not Obfuscate (React Native)

Rodrigo Gomez Palacio — Mon, 05 Aug 2024 04:59:50 +0000

Protecting Your React Native App's Intellectual Property: Using Hermes and JavaScript Obfuscation

Let's just jump to the point.

Code obfuscation is a software development process that makes source or machine code more difficult for humans or computers to understand.

This does not protect your app from being reverse-engineered. Someone with enough time, resources, or dedication can reverse-engineer your app.

NEVER include secrets on the client-side app, even if it's obfuscated.

So in the world of React Native, should you obfuscate your code?

To answer this question we have to first understand how React Native works. Your Javascript code will contain all your business & app logic. It runs and communicates with the native level through the "bridge." When something changes, the Javascript side sends a message to the native side telling it to update the UI, interact with the camera, etc...

Hermes

When it comes to your JS code, should you obfuscate it? If you're running the hermes engine, for most apps this should be enough. This is because hermes inherently obfuscates your code by compiling your JS to optimized bytecode ahead of time. While it can be de-obfuscated, it adds a hurdle that for most attackers may not be worth it -- especially if it's a low-risk app.

If you're not running the hermes engine and your JS code is included as plaintext in the APK, maybe you should consider switching to hermes.

Proguard / R8

Should you enable proguard / R8 to obfuscate the native code? In the React Native world, you shouldn't be worried about IP theft of the native code since there's likely little going on here -- barring some heavy proprietary native customization.

Now, should you enable proguard / R8 for the minification benefits? Up to you. If your app is big, this might be worth it. Just know that it comes at the cost of making debugging more difficult / viewing crash logs, etc... It also might break your app if you're using 3rd party libraries that may introduce regressions.

For most React Native apps, the critical logic is in JavaScript, but some native modules might still benefit from obfuscation if they contain sensitive logic.

Sensitive Data

If your app contains important user data such as financial or health data, proper obfuscation is probably worth the overhead just to be on the safe side.

TLDR

If you're concerned about IP theft, using the hermes engine should be enough for low-value apps. If you have proprietary native logic, consider using proguard / R8 while understanding the drawbacks. If your app is large, consider proguard / R8 for its minification capabilities.

Finally please feed the algorithm and give me some feedback if my post helped you 🙏!

Follow Me

Check out my other articles and projects!

Introducing Expo Pod Pinner: Elevate Your Expo Managed Workflow with Precision

Rodrigo Gomez Palacio — Wed, 27 Mar 2024 20:37:52 +0000

In the dynamic realm of mobile development, the Expo framework stands as a beacon of efficiency and ease, especially for those favoring a managed workflow. Today, I'm thrilled to unveil an addition to this ecosystem, crafted to further refine and enhance your development experience: Expo Pod Pinner.

The plugin is designed to bring more control and stability directly to your project's Podfile without stepping outside the managed workflow’s comfort zone.

A Glance at Expo Pod Pinner

Expo Pod Pinner enables developers to specify and pin pod versions explicitly, thus ensuring consistent and stable dependency management across all installations and updates.

This plugin not only fortifies project stability but also elevates the overall development workflow by allowing direct modifications to the Podfile—a feature that aligns seamlessly with the expectations of modern mobile development.

Developers can also work around native regressions by pinning pods to working versions.

How to Embark with Expo Pod Pinner

Setting sail with Expo Pod Pinner is straightforward. Simply integrate the plugin into your project with a one-liner command:

npx expo install expo-pod-pinner

Configuration

To weave this plugin into the fabric of your project, add it to the plugin array in your app's configuration file (either app.json or app.config.js). Here’s how you can do it:

{
  "plugins": [
    [
      "expo-pod-pinner",
      {
        "targetName": "YourTargetName",
        "pods": [
          { "PodName": "0.0.0" }
        ]
      }
    ]
  ]
}

export default {
  ...
  plugins: [
    [
      "expo-pod-pinner",
      {
        "targetName": "YourTargetName",
        "pods": [
          { "PodName": "Version" }
        ]
      }
    ]
  ]
};

Configuration Props

targetName: Specify the target in your Podfile where the pods should be added.
pods: Define an array of objects with the pod names and their versions to pin.

Join the Expo Pod Pinner Community

I'm on a mission to make your Expo development journey as seamless and enjoyable as possible. Contributions, issues, and feature requests are warmly welcomed. Dive into the issues page to join the conversation or suggest enhancements.

Show Your Support

Has Expo Pod Pinner enriched your development experience? A star on our GitHub page is much appreciated and fuels further innovation.

Follow Me

Don't Pay for EAS! How to Set Up an EAS Local Build on GitHub Actions

Rodrigo Gomez Palacio — Wed, 14 Feb 2024 21:56:24 +0000

You're out of credits!

Should you pay for EAS?

If you're a React Native developer using Expo, you might be familiar with the convenience of Expo Application Services (EAS). EAS provides a suite of tools that streamline the process of developing and deploying your React Native apps.

One drawback of EAS is the price, which at $1-$4 per build may quickly add up for a developer just getting started on a project.

Luckily, one of the great features of the EAS CLI is the ability to perform local builds, and integrating this with GitHub Actions can significantly automate your development workflow and save you money!

In this post, we'll walk through the steps to set up an EAS local build on GitHub Actions.

Pricing & Build Times

It's important to compare prices and build times, to see when this implementation makes sense.

Let's start with GitHub Actions. If you're trying to optimize for cost, you're likely on the free GitHub plan or the basic $4 Github Teams/Pro plan. You're going to need to run iOS builds on a macOS while Ubuntu should work just fine for Android.

While build times vary, for simplicity, an average build takes about 35 minutes. At $0.008 PPM (price per minute) for Ubuntu 2-core and $0.08 PPM for macOS 3-core, that comes out to $0.28 per build for Android and $2.80 for iOS. That's an expensive iOS build.

Now let's look at EAS pricing. Depending on your choice of resources, your potential EAS build will use more cores and thus run a lot faster than on GitHub Actions. That may be worth paying for depending on your needs.

As you can see above, however, builds are pricy on EAS as well. That said, if build time is not a priority, you can find big savings on the Android side by going with GitHub Actions given the low cost of running Ubuntu.

Thus, your choice between EAS or GitHub Actions depends largely on a) how fast you need the build to run, and b) the frequency of your builds since running lots of builds will quickly add up.

For iOS builds, I think EAS comes out slightly ahead at a flat $2 per build if you go with the iOS medium worker size.

Setup

Step 1: Understanding the Prerequisites

Before diving into the setup, ensure you have:

A React Native project managed by Expo.
A GitHub repository for your project.
Basic knowledge of GitHub Actions and workflows.

Step 2: Setting Up Your GitHub Actions Workflow

Create a Workflow File:
In your project repository, create a new file in the .github/workflows directory. You can name it something like build.yml.

name: Build App
on:
  workflow_dispatch:
    inputs:
      os:
        type: choice
        description: OS to build on. Ubuntu is faster, MacOS supports iOS builds
        options:
          - macos-latest
          - ubuntu-latest
      platform:
        type: choice
        description: Platform to build for
        options:
          - android
          - ios
      profile:
        type: choice
        description: Build profile to use
        options:
          - development
          - preview
          - production
      should_submit:
        type: boolean
        description: Whether to perform the submit step
        required: true
        default: false
jobs:
  build:
    runs-on: ${{ github.event.inputs.os }}
    strategy:
      matrix:
        node: [18.x]
    steps:
    - name: 🏗 Setup repo
      uses: actions/checkout@v2

    - name: 🏗 Setup Node
      uses: actions/setup-node@v2
      with:
        node-version: ${{ matrix.node }}
        cache: yarn

    - name: 🏗 Setup Expo and EAS
      uses: expo/expo-github-action@v7
      with:
        token: ${{ secrets.EXPO_TOKEN }}
        expo-version: latest
        eas-version: latest

    - name: 📦 Install dependencies
      run: yarn

    - name: 📋 Test project
      run: yarn test

    - name: 👷 Build app
      run: |
        eas build --local \
          --non-interactive \
          --output=./app-build \
          --platform=${{ github.event.inputs.platform }} \
          --profile=${{ github.event.inputs.profile }}

    - name: 🚢 Submit
      if: ${{ github.event.inputs.should_submit }}
      run: eas submit -p ${{ github.event.inputs.platform }} --profile ${{ github.event.inputs.profile }} --path app-build

Add Required Secrets:
For EAS to work, you need to add your Expo credentials as secrets in your GitHub repository. Go to your repository Settings -> Secrets and variables -> Actions. This is where you will paste in your access token. Double-check that you are creating the robot token at the right level (e.g. wherever your app is).

Finally, add any other required secrets you may need. A common example is the Google Services files.

Google Services Files
If you are not using Google Services files, skip ahead.

Problem: consider the scenario where your project needs these files, but you don't want to commit them. If that's the case, Github Actions wouldn't have access to their contents.

Solution: base64-encode the files, add them as secrets to Github, and then use a pre-install hook to re-create the files in Github Actions' cloud environment.

$ base64 -i googleServices/google-services.json (repeat for Plist, other files)
Add encoded strings as secrets to Github Actions
Write a script to decode them into their original files:

#!/bin/bash

# Create the directory if it doesn't exist
mkdir -p ./googleServices

# Decode the base64 strings and create the files
echo $GOOGLE_SERVICES_JSON_BASE64 | base64 --decode > ./googleServices/google-services.json
echo $GOOGLE_SERVICES_PLIST_BASE64 | base64 --decode > ./googleServices/GoogleService-Info.plist

Call that script from the eas-build-pre-install hook in your package.json.
Make the variables accessible via our build YML:

- name: 👷 Build app
      env:
        GOOGLE_SERVICES_JSON_BASE64: ${{ secrets.GOOGLE_SERVICES_JSON_BASE64 }}
        GOOGLE_SERVICES_PLIST_BASE64: ${{ secrets.GOOGLE_SERVICES_PLIST_BASE64 }}
        GOOGLE_SERVICES_JSON: ${{ vars.GOOGLE_SERVICES_JSON }}
        GOOGLE_SERVICES_PLIST: ${{ vars.GOOGLE_SERVICES_PLIST }}

Note that in this example, I am using GOOGLE_SERVICES_JSON and GOOGLE_SERVICES_PLIST as well. These contain the paths to the files.

This is applicable if you don't have a hard-coded path in your app.json / app.config.js:

  ios: {
    googleServicesFile: process.env.GOOGLE_SERVICES_PLIST,
  }

Step 3: Testing the Workflow

Once you've set up the workflow file:

Commit and Push: Commit the changes and push them to your repository.
Trigger the build via the Github Actions tab.
Click on the build to monitor it.

Step 4: Debugging and Optimization

If the build fails, check the logs in the Actions tab for errors.
Optimize your workflow by caching dependencies or splitting jobs.
If you know your tests pass, exclude that step and others to iterate more quickly until your build is stable.

Conclusion

Integrating EAS local builds into GitHub Actions can greatly enhance your CI/CD pipeline and save you some of the green. Remember, this setup might vary slightly depending on your project's specific needs, so feel free to adjust it as necessary.

And finally please feed the algorithm and give me some feedback if my post helped you 🙏!

Follow Me

Check out my other articles and projects!

Introducing the Unofficial Perplexity SDK for Node.js

Rodrigo Gomez Palacio — Wed, 07 Feb 2024 08:33:17 +0000

Overview

In today's ever-evolving tech landscape, innovative tools and frameworks are pivotal in shaping how we interact with technology. One such groundbreaking addition is the Perplexity.

The Unofficial Perplexity SDK for Node.js is a tool designed to bring you access to Perplexity.ai on Node.js.

How it was made

I built this project using OpenAPI. OpenAPI, an open-source format, played a crucial role in easily generating the SDK and will allow for simple updates.

Install

# npm
npm install perplexity-sdk

# yarn
yarn add perplexity-sdk

Usage

import Perplexity from 'perplexity-sdk';
import { ChatCompletionsPostRequestModelEnum } from 'perplexity-sdk';

const config = {
  apiKey: process.env.PERPLEXITY_API_KEY || '<YOUR_API_KEY>'
};

const perplexity = new Perplexity(config).client();

const result = await perplexity.chatCompletionsPost({
  model: ChatCompletionsPostRequestModelEnum.Mistral7bInstruct,
  messages: [{
    "role": "user",
    "content": "Your prompt here"
  }],
});

console.log(result);

Show your support

Please give a ⭐️ if this project helped you! That's all I ask.