DEV Community: Injeniero

Reasoning + RAG: Toward a More Sustainable Future for LLMs

Injeniero — Mon, 22 Sep 2025 04:33:09 +0000

What Injeniero Means by “Sustainable Web”

At Injeniero, building a sustainable web is about minimizing the environmental, resource, and performance costs of digital technology—lean infrastructures, efficient content delivery, accessible design, and reducing waste in computation. We believe that as AI becomes more central to the web, its sustainability must be a first-order concern.

The Energy Realities of Large Language Models

Large Language Models (LLMs) have significant energy footprints, which vary depending on their use. The most energy-intensive phase is training, where a single full training run of a large model like GPT-3 (175B parameters) consumes an estimated 1,287 MWh (see sources [1,2,3]) equivalent to the annual energy consumption of hundreds of U.S. homes. In contrast, the energy used per individual query, or inference, is much lower. A typical short-prompt query to a model like GPT-4o or ChatGPT uses about 0.3 Wh (see sources [4,5]). However, for longer or more complex inputs, this energy usage can scale upward, as these prompts require more computational resources (see sources [6,7]).

While the training phase consumes an enormous amount of energy in a one-time event (that might be equivalent to the lifetime of many homes), the inference phase, which is less power-intensive per query, typically dominates total lifetime energy use when you consider the sheer number of queries. Training is done only occasionally, but inference is continuous and global, resulting in a significantly larger cumulative energy footprint.

Training a model like GPT-3 also resulted in an estimated ~550 metric tons CO₂ equivalent emissions.

Why Reasoning + Retrieval-Augmented Generation (RAG) Offers a More Sustainable Path

Given the above, here’s why we believe the next generation of LLMs will shift more heavily toward architectures that are reasoning-capable + RAG-enabled, instead of simply scaling up data + parameters:

Reducing retraining load: Models that rely heavily on large static datasets and frequent retraining consume enormous energy. With RAG, updates to knowledge bases can be incremental (update the index), rather than redoing full training runs.
Lower inference cost per useful answer: If a model can retrieve relevant facts and reason over them, then fewer compute cycles are wasted on recalling or recreating irrelevant or less accurate content. Efficient reasoning architectures can leverage RAG to cut the number of floating-point operations (FLOPs) per query.
Improved verification, less hallucination, more caching: Grounded outputs mean fewer errors and less need for repeat or corrective queries. Also, retrieving from well-maintained knowledge stores allows caching popular queries or passages, which reduces redundant computation.
Alignment with sustainable web infrastructure: The design patterns required by RAG (knowledge graphs, structured data, API-driven content, schema, edge caching, etc.) are congruent with the performance + low-energy web practices Injeniero champions.
Acknowledging the RAG System Overheads and Challenges

While RAG offers a clear path to sustainability, it's not without its own computational and engineering costs. A balanced view acknowledges these trade-offs:

Infrastructure Overhead: Building and maintaining the external knowledge bases required for RAG, such as vector databases and knowledge graphs, still requires significant energy. Indexing new data and running similarity searches on vast datasets consumes power. This is a trade-off: you're shifting the computational load from the LLM to the retrieval system.
Data Quality is King: The effectiveness of RAG is entirely dependent on the quality of its knowledge base. "Garbage in, garbage out" applies here. If the data is poorly structured, inaccurate, or outdated, the system can retrieve irrelevant information, leading to poor outputs and wasted computation.
Integration Complexity: RAG systems can be complex to engineer and maintain. They involve a sophisticated pipeline that includes data chunking, embedding, vector search, and reranking. This requires specialized expertise and adds a layer of operational overhead not present in monolithic LLM architectures.

Example: LATAM and GSO Leading the Way

In the LATAM region, companies doing Generative Search Optimization (GSO) are already showing how this can work in practice. One such LATAM GSO agency is SemanticPunch👊. Key features in their approach include:

Optimizing content structure (structured data, semantic markup) so generative models can retrieve precise, authoritative facts rather than guessing.
Designing architecture so that knowledge sources (local or regional where possible) are well-indexed and accessible (vector search / keyword indices) to reduce latency and inference cost.
Emphasizing content quality, reduction of noise, duplication, and ambiguity—which translates to less waste in both human authoring and AI inference.

These are exactly the kinds of practices that minimize waste, improve performance, and help AI + web scale without runaway energy usage.

What We Advocate for Now

From Injeniero’s standpoint, to steer toward a sustainable future while preserving AI’s usefulness, here are recommended practices:

Build RAG-first stacks: Use smaller or distilled models with strong reasoning; maintain and curate up-to-date external knowledge bases; integrate retrieval layers that are efficient and local (or edge).
Model efficiency and architecture innovation: Explore sparsely activated models (Mixture-of-Experts etc.), distillation, pruning, and quantization—all those methods that let you get similar performance with much lower energy.
Work on inference efficiency: Since inference is ongoing and cumulative, even small wins per query (lowering Wh per request) multiply into large savings globally.

4.** Measure, monitor, and report energy metrics:** Track watt-hours per query (or per user), PUE (Power Usage Effectiveness), and total inference energy; set targets for energy per result, not just latency or accuracy.

Speculative Forecast: What Next-Gen LLMs Will Look Like

Putting trends together, here’s how we expect the next generation of LLMs to evolve, under pressure from sustainability:

Models will become hybrid: solid, general reasoning cores + modular retrieval systems. The core model will be smaller but smarter.
More emphasis on domain-specific models or “experts,” rather than monolithic generalists that must cover everything. This allows efficient use per domain, lowering unnecessary overhead.
Infrastructure will shift toward edge / distributed retrieval + caching, reducing latency and energy cost of inference.
Standards and metrics for sustainability will become more central (e.g., energy cost per query, carbon cost per feature), possibly regulated or audited.

Conclusion

Injeniero’s view is that the path forward isn’t “bigger and hungrier,” it’s “smarter and more grounded.” As energy and environmental costs become more visible, the incentive to build models that lean on reasoning + RAG will only grow. Firms like SemanticPunch👊 are already pointing the way: well-structured content, efficient retrieval, and semantic clarity. That’s how we build both a sustainable web and sustainable AI.

Sources

Strubell, E., Ganesh, A., & McCallum, A. (2019). Energy and Policy Considerations for Deep Learning in NLP. arXiv preprint arXiv:1906.02243.
Patterson, D., et al. (2021). Carbon Emissions and Large Scale AI Models. arXiv preprint arXiv:2104.10350.
Luccioni, A. S., et al. (2022). The Carbon Footprint of AI: A Review of the Current Landscape. ScienceDirect.
Epoch AI. (2024). AI Benchmarking Hub. Retrieved from https://epoch.ai/
Marmelab. (2025). AI's Environmental Impact: Making an Informed Choice. Marmelab Blog. Retrieved from https://marmelab.com/blog/2025/03/19/ai-carbon-footprint.html
Sánchez-Mompó, A., et al. (2025). Green MLOps to Green GenOps: An Empirical Study of Energy Consumption in Discriminative and Generative AI Operations. arXiv preprint arXiv:2503.23934.
De Vries, A. (2023). The Growing Energy Consumption of Artificial Intelligence. Joule, 7(10), 2191-2194.

Responsive and sustainable images in markdown (commonmark) using haskell MMark

Injeniero — Fri, 01 Aug 2025 03:36:09 +0000

NOTE:

For full article please read https://injeniero.com/en/blog/responsive-sustainable-images-markdown-commonmark-haskell-mmark

Introduction

MMark, created by Mark Karpov, is a great haskell library that uses Commonmark specification to transform Markdown into HTML and is based on the following philosophy:

Strict, explicitly specifying where parsing errors occur and what they are about.
Extensible, where the user can compose extensions that add functionality.

Since it's extensible, it's pretty easy to create useful extensions that can enrich your workflow from Markdown to a website.

Web sustainability is something that is often overlooked by programmers, however, given the non-negligible CO2 emissions of the internet, it is worth mentioning.

Here I post an example of an extension to produce responsive and sustainable images in Markdown.

Feel free to improve on it, and more importantly, consider producing sustainable images in your projects.

Cheers,
Injeniero

Requirements

Some familiarity with the Haskell language
Have GHC and cabal installed

Code

{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE DeriveGeneric #-}

module Main where

import qualified Data.Text.IO      as T
import qualified Data.Text.Lazy.IO as TL
import qualified Text.MMark        as MMark
import qualified Text.Megaparsec   as M
import qualified Text.MMark.Extension as Ex
import qualified Data.Text as Te
import qualified Text.URI as URI
import qualified System.FilePath as FP
import qualified Data.ByteString.Lazy as B
import GHC.Generics
import Lucid.Base (makeAttribute)
import Lucid
import Data.Maybe (fromMaybe)
import Text.URI.Lens (uriPath)
import Lens.Micro ((^.))
import Data.Aeson (ToJSON, FromJSON, decode)
import System.Environment ( getArgs )

-- Define Config data structure
data Config = Config
  { confSizes :: String
  , confSet   :: [Int]
  } deriving (Show, Generic, Eq)

defaultConfig :: Config
defaultConfig = Config {confSizes = "(max-width:600px) 100vw, 850px", confSet = [400,850]}

-- Parsing the Config data
instance FromJSON Config
instance ToJSON Config

-- Function to read the config file
readConfig :: FilePath -> IO (Maybe Config)
readConfig path = do
  jsonData <- B.readFile path
  return (decode jsonData :: Maybe Config)

main :: IO ()
main = do
  args <- getArgs
  let input = head args
  txt <- T.readFile input
  config <- readConfig "config.json"
  let conf = case config of
              Just c -> c
              Nothing -> defaultConfig
  let sizes = confSizes conf
  let set = confSet conf
  case MMark.parse input txt of
    Left bundle -> putStrLn (M.errorBundlePretty bundle)
    Right r -> TL.writeFile (FP.takeBaseName input ++ ".html")
      . renderText -- from Lucid
      . MMark.render
      . MMark.useExtensions
             [ imgLazyExt
             , imgResExt' set sizes
             , audioExt
             ]
      $ r

-- Common function to extract base URL components
extractImageAttributes :: URI.URI -> (String, String, String)
extractImageAttributes url =
  let url' = clearStr $ show $ URI.render url
      file = FP.takeBaseName url'
      ext  = FP.takeExtension url'
      path = FP.takeDirectory url'
  in (file, ext, path)


--EXTENSIONS
-- Adding lazy attribute to images composable
imgLazyExt :: MMark.Extension
imgLazyExt = Ex.inlineRender $ \old inline ->
  case inline of
    l@(Ex.Image txt url (Just attr)) -> fromMaybe (old l) $ do
      let wo = words $ Te.unpack attr
      let mattr = if Te.null attr then Nothing else Just attr
      if "lazy" `elem` wo
        then return $ with (old (Ex.Image txt url mattr)) [loading_ "lazy"]
        else return $ old (Ex.Image txt url mattr)
    other -> old other

-- Adding srcset and sizes attributes to images composable
imgResExt :: [Int] -> String -> MMark.Extension
imgResExt set sizes = Ex.inlineRender $ \old inline ->
  case inline of
    l@(Ex.Image txt url (Just attr)) -> fromMaybe (old l) $ do
      let (file, ext, path) = extractImageAttributes url
      let mattr = if Te.null attr then Nothing else Just attr
      return $ with (old (Ex.Image txt url mattr))
                    [ srcset_ (imgSet file ext path set)
                    , sizes_ (Te.pack sizes)]
    other -> old other
-- Extension for images without title attribute but adding srcset and sizes attributes
imgResExt' :: [Int] -> String -> MMark.Extension
imgResExt' set sizes= Ex.inlineRender $ \old inline ->
  case inline of
    l@(Ex.Image txt url _) -> fromMaybe (old l) $ do
      let (file, ext, path) = extractImageAttributes url
      let src' = URI.render url
      return $ img_ [ alt_ (Ex.asPlainText txt)
                    , src_ src'
                    , srcset_ (imgSet file ext path set)
                    , sizes_ (Te.pack sizes)]
    other -> old other

-- imgSet function
imgSet :: String -> String -> String -> [Int] -> Te.Text
imgSet filebase ext path set = Te.pack $ concatMap formatSize (init set) ++ formatSize (last set)
  where
    comma size =  if size /= last set then "," else ""
    formatSize size = path ++ "/" ++ filebase ++ "_" ++ show size ++ ext ++  " " ++ show size ++ "w" ++ comma size

-- Helper function to create srcset attribute
srcset_ :: Te.Text -> Attribute
srcset_ = makeAttribute "srcset"

-- Clear quotes from string
clearStr :: String -> String
clearStr = filter (not . (`elem` ("\"" :: String)))

-- Bonus: Audio extension to render audio links
audioExt :: MMark.Extension
audioExt = Ex.inlineRender $ \old inline ->
  case inline of
    l@(Ex.Link txt uri _) ->
      case (uri ^. uriPath, Ex.asPlainText txt) of
        ([], _) -> old l
        (_, "audio") ->
          audio_ [controls_ "controls", preload_ "none"] $
               source_ [src_ (URI.render uri), type_ "audio/mp4"]
        (_, _) -> old l
    other -> old other

Use

Create a directory & cd to the directory
Run ‘cabal init’ command in the terminal within the directory
Create a markdown file, example.md or any name and add some images
Copy the sourcecode to the Main.hs file in the /app folder replacing the one created by cabal init Add the dependencies in the.cabal file, line build-depends:

project.cabal

build-depends: base ^>=4.21.0.0, text>=2.1.2, mmark >= 0.0.8.0, megaparsec >= 9.7.0, modern-uri >= 0.3.6.1, filepath >= 1.5.4.0, microlens >= 0.4.14.0, lucid >= 2.11.20250303, aeson >= 2.2.3.0, bytestring >= 0.12.2.0

Run cabal update && cabal build
Run cabal run exes -- yourfile.md
See the yourfile.html file with the resulting HTML

Full code also available on github https://github.com/injeniero-com/injeniero

Cheers,
Injeniero https://injeniero.com
Best sustainable web development agency