<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>OpenAI on Clarence | Backend, AI, DevOps, Infrastructure</title>
    <link>https://clarence.tw/en/tags/openai/</link>
    <description>Recent content in OpenAI on Clarence | Backend, AI, DevOps, Infrastructure</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Mon, 26 Oct 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://clarence.tw/en/tags/openai/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Designing an LLM Summarization Pipeline: OpenAI API, Ollama, and Local Models</title>
      <link>https://clarence.tw/en/posts/llm-text-summarization-platform/</link>
      <pubDate>Mon, 26 Oct 2026 00:00:00 +0800</pubDate>
      
      <guid>https://clarence.tw/en/posts/llm-text-summarization-platform/</guid>
      <description>&lt;p&gt;Since 2022, I have been bringing LLMs into real product workflows. One part of that work is an internal text summarization and AI application platform that integrates the OpenAI API, Ollama, local models, and batch processing, with the focus on model usage that stays controllable and maintainable.&lt;/p&gt;
&lt;p&gt;The details of an internal system like this are not suitable for publication, so this is not a full case study. Instead, it collects the principles and trade-offs I apply when designing and operating a summarization pipeline. API behavior described here was checked against the official documentation at the time of writing (October 2026); check the latest docs before relying on it.&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>
