Training an AI to Reduce Network and Computational Resource Usage for Podcasts and Other RSS/Atom Feeds

Abstract

Podcast are announced online using a metadata document format that may be quite large and comprehensive, with some show feeds going back well over a decade and listing all 1000+ episodes that were ever produced. These documents are usually downloaded and processed multiple times a day simply to determine if there is a single new episode available (i.e., upwards of 99.99% of the information is processed only to be discarded). Such wasteful behavior negatively impacts both podcasters and their subscribers.

In this paper we utilize a breakthrough AI called SQLite3, which we are able to quickly train on large data sets without the need for power-hungry datacenters or arrays of GPUs. We then proceed to demonstrate prompt engineering techniques that generate smart solutions to the above problem. Our results have been verified as being both precise and 100% hallucination-free, something that has not been achieved by any of the competitors in the modern AI industry.

Corpus

The popularity of podcasts (and similar uses for RSS/Atom feeds) has created an increasingly large public data set which can be used to train an AI. However, not all uses of that complete data set are ethical. For our study, we focus on just the metadata for the episodes rather than the creative content itself, fully respecting the claims of copyright holders. While more comprehensive podcast feed data is available, we have restricted our training to episode details that we were able to get from the publisher's feeds directly. Furthermore, for brevity, in this paper we will restrict reporting to the sample set of 4 podcasts mentioned here. Our episode domain range is thus:¹

Hardware

To demonstrate the unparalleled efficiency of the SQLite3 AI, we have chosen to run it on a modest Raspberry Pi 3 Model B Plus. We know of no efforts to do significant training of large language model (LLM) AIs on systems this lightweight. Researchers experimenting on simply running those models on even the fastest Raspberry Pi hardware have found the results lacking (e.g., 2-10 tokens/s). We have found the SQLite3 AI provides excellent performance for both queries and training on a budget of not $50 million or $5 million, but $0.00005 million.

Training

Each new generation of LLM AI generally needs to be trained "from scratch", which is a time- and energy-intensive process. By contrast, an SQLite3 AI can be progressively trained, allowing you to use the previous model as the basis for the next. In fact, SQLite3 AI models are so stable that they are considered an archival format by the United States Library of Congress; no other AI model has been granted this status.

That said, we can examine two types of "from scratch" training for podcast data. The first is preprocessing the RSS/Atom format into AI-ready tokens. This must be done every time a feed is downloaded, and is highly dependent on the libraries and languages used to parse XML data. For the full range of data of the 4 sample podcasts listed earlier, our system setup benchmarked the following times:

real    0m9.758s                                  
user    0m9.446s                                  
sys     0m0.309s

That represents significantly more resource usage than the actual "from scratch" training of the SQLite3 AI model itself based on that parsed data:

real    0m0.410s
user    0m0.184s
sys     0m0.065s

This imbalance, and the (mis)use of feeds to keep publishing episodes that are over a decade old as "new", is why we see value in using the resulting SQLite3 AI to optimize the first phase of its own training process.

Prompts

As with all AI chatbots, SQLite3 often requires prompt engineering to get optimal results. Unlike those LLMs, though, SQLite3 has a published grammar for a domain-specific language (DSL) that can be used to better direct it towards the output you need. SQLite3 also works to keep this DSL stable; most chatbots do not process their prompts consistently between releases, further reducing the value of that hit-or-miss effort on their platforms.

Show me how many days there are between episode releases, at a minimum, on average, and the longest.²

real    0m0.033s
user    0m0.020s
sys     0m0.012s

This prompt needed to be further engineered in order to convert the time interval representation to days. We also instructed the SQLite AI to combine "duplicate" entries, where multiple episodes appeared to be released at the same time, ensuring a non-zero minimum time. Even so, the results of just this small sample shows that podcast releases exhibit a great deal of variability. Also note the incredible speed at which the SQLite3 AI generated the response. From the perspective of chatbot benchmarking, the performance for the SQLite3 AI was ~2500 token/s.

Our SQLite3 AI determined that Le Show has a fairly tight weekly release schedule, while Future Tense similarly averages weekly releases, but does so with much looser extremes. The SQLite3 AI clearly reports the greatest extremes are seen by The Infinite Monkey Cage: 5 minutes to nearly 1.5 years! Further prompt engineering could be done to limit the outliers to 1 or 2 standard deviations, but we do not do that here because we know these releases tend to be multi-cyclical (i.e., shows can have seasons/series of frequent releases followed by a long pause, and/or they skip episodes when they coincide with common yearly holidays) rather than following a normal distribution, creating a prompt engineering challenge worthy of future research.

For our purposes, it is enough of a win to have the SQLite3 AI discover we can essentially ignore most of these podcasts for days without falling behind on even a single episode. This knowledge allows us to formulate a new prompt for the SQLite3 AI to generate a new baseline schedule for us that is far more efficient than the common practice of "refresh feeds every X hours".

Show me how many hours we have until we first expect the next new episode.³

real    0m0.032s
user    0m0.016s
sys     0m0.016s

Here we see the SQLite3 AI rescheduling the next feed refresh based on each podcast's minimum time. Negative values are in the past (i.e., a new episode may already be due for release), which will almost always be the case for The Infinite Monkey Cage due to their unusually brief 5m minimum, but Le Show is also overdue for a release, simply because we happen to be writing this late in the afternoon on the day of their weekly release. Those will both be checked during the next "regular" refresh (in just under an hour). The other two podcasts will not be processed for upwards of 2 days because the SQLite3 AI has determined there will likely be nothing to process.

This leads to a followup query that could additionally improve efficiency. The SQLite3 AI correctly determined that some podcasts come out once a week on average, but others only come out around once a month. So, for example, it doesn't make much sense to start regularly refreshing The Infinite Monkey Cage every few hours after the brief initial wait, since we know it is likely going to be weeks before the next one. We can get the SQLite3 AI to make this adjustment to the refresh interval as well.

Show me how many hours we can wait until we next refresh the feed.⁴

real    0m0.032s
user    0m0.022s
sys     0m0.010s

As we hoped, the SQLite3 AI was able to figure out that, even though The Infinite Monkey Cage is "overdue" by our first metric, we can actually wait more than another day before checking for a new episode (but never more than ~3 days). Only Le Show is currently overdue by both metrics.

Application of these results will represent a significant savings in resources. For example, over a one month period we will now be checking The Dana Gould Hour only ~7.5 times using the smart schedule generated by our SQLite3 AI, whereas a naive "every X hours" schedule might have it being processed 120 or even 180 times (for X = 6 and 4 respectively).

Replication using Other AI Chatbots

We made a good faith effort to accomplish these same tasks with ChatGPT-4, but were banned for "suspicious activity" the moment we mentioned The Infinite Monkey Cage, presumably because the less sophisticated LLM technologies cannot safely distinguish between domain words and prompts resulting in infinite loops. This is yet another advantage to using the SQLite3 AI for real-world data sets.

We leave it to other researchers to do followup studies to determine if any other generative AI can even accomplish tasks of this nature.

1. ^{^} sqlite3 --markdown model.db "select (select title from feeds where url = feed_url) as title, datetime(min(items.updated_at), 'unixepoch') as beginning from items group by feed_url"
2. ^{^} time sqlite3 --markdown model.db "select title, update_min_interval/(24.0*3600) as min_release_days, update_avg_interval/(24.0*3600) as avg_release_days, update_max_interval/(24.0*3600) as max_release_days from feed_stats join feeds using(url)"⁵
3. ^{^} time sqlite3 --markdown model.db "select title, (updated_at + update_min_interval - unixepoch('now'))/3600.0 as min_threshold_hours from feeds join feed_stats using(url)"
4. ^{^} time sqlite3 --markdown model.db "select title, (mtime + update_avg_interval/8 - unixepoch('now'))/3600.0 as avg_threshold_hours, (update_avg_interval/8)/3600.0 as max_threshold_hours from feeds join feed_stats using(url) join sqlar on sqlar.name = feeds.url"
5. ^{^} create view if not exists feed_stats (url, update_min_interval, update_avg_interval, update_max_interval) as select feed_url, min(diff), avg(diff), max(diff) from (select feed_url, (items.updated_at - lag(items.updated_at) over (partition by feed_url order by items.updated_at)) as diff from items join feeds on items.feed_url = feeds.url) where diff > 0 group by feed_url