Hermes, a Mac Mini M4, and the Quest to Organise 197,000 Photos

Sometimes the most interesting AI projects begin with a problem nobody wants to solve manually.

Mine started with roughly 197,000 image files occupying around 44GB of storage.

The collection had grown over many years from publicly available websites, forums, social media platforms, blogs and news sites. Images were scattered across 65 folders, many named after domains, some with nothing more meaningful than a serial number.

Finding anything had become increasingly difficult.

The obvious question was:

Could an AI agent organise the collection for me?

What followed became a useful lesson about what AI agents can do today, and what they still struggle to do.

The Goal

The initial objective sounded straightforward.

Take thousands of photos, group them by person, determine who that person is, and rename the folders accordingly.

The naming logic was relatively simple:

  1. Use the original native-language name whenever possible.
  2. Fall back to a Chinese translation if one exists.
  3. Otherwise use the English name.

For example, if a public figure’s original Japanese, Korean or Chinese name could be identified, that name would be preferred over an English transliteration.

The challenge was that almost none of the photos came with reliable metadata.

Humans could solve this eventually.

I simply didn’t want to spend months doing it.


The Setup

The infrastructure was deliberately minimal.

Hardware:

  • Mac Mini M4
  • External storage
  • Hermes running locally

LLM access:

  • OpenRouter
  • USD$10 prepaid credit

Remote interface:

  • Telegram Bot

Security was intentionally restricted.

Only messages originating from my own Telegram Application ID were allowed to issue commands. Nobody else could interact with the agent.

This effectively turned Telegram into a secure remote terminal for my Mac Mini.

I could initiate jobs, monitor progress and review results directly from my phone.


The Models

Like many people, I started with free models.

On paper they seemed impressive.

In practice they frequently misunderstood instructions, lost context, ignored constraints or produced inconsistent decisions.

Many could discuss the work.

Far fewer could reliably perform it.

After numerous tests, OpenAI 5.6 Luna proved to be the most reliable option available through OpenRouter.

Even then, “reliable” did not mean perfect.

My own observation was that the model understood approximately 99% of what I intended.

That sounds excellent.

Until thousands of automated actions are involved.

At scale, a 1% misunderstanding rate becomes surprisingly visible.


The Pipeline Grew Much Larger Than Expected

What started as a renaming exercise evolved into a multi-stage workflow.

Hermes first performed face extraction and clustering.

The initial pass produced:

  • 232,850 detected faces
  • 7,014 clusters
  • 143,048 images identified as noise

The naming phase then relied on external services.

The workflow eventually became:

Face Clustering
        ↓
Representative Images
        ↓
Upload to ImgBB
        ↓
Google Lens via SerpDev
        ↓
Confidence Analysis
        ↓
If uncertain
        ↓
Queue for Yandex Search
        ↓
Additional Validation
        ↓
Folder Renaming

The idea sounded reasonable.

The reality proved much harder.


Hermes Was Surprisingly Good at Self-Correction

One unexpected discovery was how often Hermes reviewed its own work.

Rather than simply executing commands, it frequently reported problems.

The Telegram chat looked less like a chatbot and more like a junior engineer providing status updates:

  • clustering completed
  • worker restarted
  • validation failed
  • confidence too low
  • manual review required
  • schedule misconfigured
  • progress reporting restored

Sometimes I would simply respond:

Do what you think improves the result quality.

Hermes would patch scripts, modify workflows, restart workers and verify outputs.

It wasn’t autonomous in the science-fiction sense.

But it was surprisingly capable of identifying weaknesses in the process.


The Project Never Finished

The original target was roughly 840 high-priority clusters.

The plan was:

  • Top tier (150 groups)
    • Google Lens
    • Yandex verification
  • Middle tier (300 groups)
    • Google Lens
    • Yandex as needed
  • Lower tier
    • Process later

In practice, reality intervened.

The top 150 groups completed two-stage scanning.

Only around three quarters of the middle-tier groups finished Google Lens processing.

The Yandex stage never reached meaningful scale.

Costs increased.

Runtime increased.

Complexity increased.

Progress slowed dramatically.


The Disappointing Part

Eventually I reviewed the rename results.

And honestly?

I wasn’t impressed.

Some folders were excellent.

Some recovered original Japanese names.

Some recovered Korean names.

Some recovered Chinese names.

Many looked promising.

But many others were messy.

A significant number resembled search-result titles rather than identities.

Others inherited fragments from websites, article headlines or unrelated metadata.

Overall, I would estimate only about half of the renamed folders felt genuinely useful.

Not wrong enough to call a failure.

Not good enough to trust.

That was the point where I stopped.

Not because Hermes couldn’t continue.

Because I no longer believed additional spending and fine-tuning would produce proportionally better outcomes.

After roughly three to five days of experimentation, I had learned what I wanted to know.


What I Learned

The lesson wasn’t that AI agents are useless.

Quite the opposite.

Hermes successfully automated weeks of tedious work.

The lesson was that identifying a face and identifying a person are fundamentally different problems.

AI vision can group similar images remarkably well.

Recovering an accurate human identity is much harder.

It requires:

  • search engines
  • reverse image lookup
  • public web information
  • metadata analysis
  • language translation
  • confidence validation
  • human judgement

And despite all the recent advances, AI still struggles with that last part.

The technology worked.

The workflow worked.

The economics were reasonable.

The accuracy simply wasn’t high enough.

For me, that was the most interesting outcome.

The experiment didn’t end because the AI failed.

It ended because I finally discovered where its practical limits currently are.

And honestly, that answer was worth far more than the USD$10 I started with.

Earning the AWS Machine Learning – Specialty Certification (June 2025)

In June 2025, I passed the AWS Certified Machine Learning – Specialty exam—my third AWS certification. Unlike the previous two (Solutions Architect – Associate and Developer – Associate), this one opened the door to a completely new domain: machine learning and applied data science on AWS.

The shift wasn’t just technical—it was conceptual. I went from managing infrastructure and deploying APIs to preparing datasets, evaluating model performance, and experimenting with SageMaker pipelines.


🧭 Why I Took the Leap into ML

While working through architectural and serverless designs, I often came across problems that felt deeply data-driven—fraud detection, user behavior prediction, personalization. I realized that cloud fluency alone wasn’t enough; I wanted to learn how to build intelligent systems with the power of ML.

The Machine Learning Specialty exam offered a structured path to build that capability.


⚙️ A Different Kind of Challenge

Compared to Associate-level exams, the ML Specialty dives deep into:

  • Core ML Concepts
    Supervised vs. unsupervised learning, classification vs. regression, feature engineering, model tuning, and overfitting detection.
  • Model Evaluation
    Understanding metrics like precision, recall, F1 score, ROC AUC, confusion matrices—and when to use which.
  • End-to-End ML Pipelines
    Data collection → processing → training → deployment → monitoring—using services like S3, Glue, SageMaker, CloudWatch, and Model Monitor.
  • Bias, Explainability, and Governance
    Using SageMaker Clarify and managing fairness, transparency, and responsible AI design.

📚 Learning Notes

Rather than creating a separate section, I’ve continued adding to the existing AWS directory.

Some of the notes now live under:

  • 📘 Data Prepration
    Cleaning, transforming, and splitting datasets using Pandas, SageMaker Processing, and AWS Glue.
  • 📘 DataModel Training
    Covers training models in SageMaker (built-in + custom), using Estimators, handling imbalanced datasets, and hyperparameter tuning.
  • 📘 Modelling Evaluation
    Detailed walkthroughs of evaluation metrics, model selection strategies, and overfitting/underfitting signals.
  • 📘 Machine Learning Implementation
    Endpoints, autoscaling, versioning, and deploying models with real-time inference + A/B testing.
  • 📘 Machine Learning Governance
    Bias detection, explainability, and model monitoring using Clarify and Model Monitor.

🔍 Study Strategy & Tools

This cert took a different kind of discipline:

  • Hands-on Jupyter Labs in SageMaker
    I used real datasets (from UCI, Kaggle) to train XGBoost, Linear Learner, and NLP models with BlazingText.
  • Model Lifecycle Practice
    Practiced full ML lifecycles: data → processing → model training → endpoint deployment → monitoring.
  • Lots of Theory Repetition
    Concepts like recall vs. precision or when to use PCA required more time and real examples to solidify.
  • ML-Focused Mock Exams
    Focused on real-world case studies and use-case reasoning—not just configurations.

🧠 Key Takeaway

This was the most conceptually intense of all three certifications I’ve taken so far. While the Associate-level exams were about knowing how AWS works, this one required understanding why certain ML methods apply in specific scenarios.

And most importantly—it made me more confident as I take my first serious steps into the data science world.


🙌 Final Thoughts

Three certifications in—each one pushed me in a new direction. And the Machine Learning – Specialty was a powerful reminder that learning doesn’t stop at architecture or automation. If you’re cloud-native but curious about ML, or a developer looking to bridge into data science, I hope these notes and reflections help make that path less intimidating.

AWS Certified Developer – Associate Journey (Early March 2025)

In early March 2025, I earned my second AWS certification: the AWS Certified Developer – Associate. This built on the foundation I laid with the Solutions Architect – Associate, but with a much deeper dive into serverless development, event-driven design, and developer tooling on AWS.

Instead of creating a new section, I’ve continued updating and expanding the existing AWS knowledge collection with Developer-specific topics, keeping everything in one place for a cohesive learning path.


🔥 Focus: Serverless, APIs, and Automation

This certification emphasized building, securing, and deploying cloud-native applications—especially using AWS’s serverless offerings. I focused my preparation on:

  • AWS Lambda
    Building scalable, efficient functions with environment configs, permissions, and concurrency controls.
  • API Gateway
    Integrating REST and WebSocket APIs with Lambda, adding request transformations, and securing endpoints with JWT-based custom authorizers.
  • EventBridge & SQS/SNS
    Designing event-driven applications using EventBridge rules, SQS queues, DLQs, and SNS topics to decouple and scale workflows.
  • CI/CD Automation
    Automating deployments with CodePipeline, CodeBuild, and SAM templates—integrated with Git-based workflows.
  • Observability & Debugging
    Using CloudWatch Logs, metrics, alarms, and X-Ray to trace Lambda executions, API behavior, and message flow through event pipelines.

📝 Developer Topics Now in AWS

I’ve integrated all new Developer Associate–relevant material directly into the existing AWS notes section, including updates to:

  • Serverless
    Expanded to include advanced Lambda patterns, handler design tips, concurrency tuning, and architectural diagrams.
  • DevTools
    New content added covering CodePipeline, CodeBuild setups for serverless projects, and how to define full workflows using SAM CLI.
  • Database Storage
    Now includes DynamoDB tips relevant for developers—indexes, partition key planning, TTL, and DynamoDB Streams with Lambda triggers.
  • Security and Compliance
    More examples of IAM roles for Lambda, scoped permissions for developer workflows, and secure access patterns for Parameter Store & Secrets Manager.

🙌 Final Thoughts

The Developer Associate certification challenged me in new ways—from writing code to managing real-world deployments. It’s more than theory—it’s how AWS apps are actually built. If you’re studying or just exploring serverless, feel free to explore my updated AWS section, or reach out with questions or feedback.

Reflecting on My AWS Certified Solutions Architect – Associate Journey

Last December, I finally earned the AWS Certified Solutions Architect – Associate certification. It wasn’t a simple weekend prep session—it was the culmination of months of dedication: early mornings before work, late nights after dinner, and countless hours of hands-on practice across real-world scenarios.

To capture every milestone and make review easier, I documented my learning journey with a well-structured set of knowledge notes—hosted on my AWS section. Here’s a deep dive into that journey.


📚 Core Topics & My Note Collections

These posts served as the backbone of my study plan—check them out for summaries, diagrams, code snippets, and exam-style flashcards:

  • CloudFormation & Architecture Patterns
    Modular stack design, nested stacks, parameter input strategies, and template best practices. I included sample templates to showcase blue/green deployments, cross-stack references, and rollback behaviors.
  • Networking & VPC
    Subnet types, route tables, NAT gateways, VPC endpoints, cross‑account and cross‑region networking. I experimented with transit gateways and published flow diagrams for clarity.
  • Security & Compliance
    IAM roles, policies, fine‑grained permissions, STS, KMS, and service‑linked roles. I also covered AWS Config rules and CloudTrail integration—foundational for both exam success and real-world security.
  • Serverless Architecture (Lambda, EventBridge, CloudWatch)
    From writing Lambda functions to architecting event‑driven workflows with EventBridge and designing resilient retry patterns with dead‑letter queues. I shared CLI recipes and monitoring hacks.
  • Data & Storage Options
    S3, EBS, RDS, DynamoDB — lifecycle policies, provisioned capacities, encryption, and backup strategies. Got hands-on with lifecycle transitions and RDS read replicas.

🔍 How My Notes Transformed the Study Experience

  1. Active Learning Through Writing
    Turning course material and documentation into blog‑style notes pushed me from passive reading to active recall.
  2. Modular Review System
    Each topic living on its own page helped me target weak areas and do quick refreshers before mock exams.
  3. Hands-On Templates & Diagrams
    The reusable CloudFormation snippets and network visuals were invaluable—both in the exam simulation and in post-cert projects.

🙌 Final Thought

Embarking on the AWS certification path was challenging—but creating this knowledge base made it rewarding, repeatable, and shareable. If you’re preparing for the AWS Certified Solutions Architect path, I hope my notes give you a headstart. Interested in walkthroughs on specific modules? Just drop a comment below!

Scuba Diving

基本上,這件事情(指Scuba Diving),我個人真正跟它發生交集的時間,是早在今年年初一月份的時候;真的沒想到會延續到今日,而且可能得到九月初才會有個比較正式的暫停。

這樣說好了,首先我會想到Scuba Diving,是去年2009的事了;是在MSN上跟大學同學聊天時,問到他怎麼會對Brisbane感到有興趣時,他提到『讀博士班閒閒沒事,就去上了潛水課程,拿到相關證照。』對啊!既然都已經花大錢來國外享受生活了,怎麼不試著做些不一樣的事情?!

也剛好暑假不想回台灣,嘗試一下異國跨年的風情;可是想要找到PartTime Job的期望並沒有實現的情況下….就決定花點錢去做一些在台灣的時候自己不會去做的事情。

潛水的認證機構,主要是兩個比較大的,SSI(Scuba Schools International)網址與PADI網址,根據深愛潛水的朋友解釋,這兩個機構的認證都差不多,在器材教育與潛水訓練上都算是很嚴格的;不過,近幾年來SSI教導出來的學員普遍評價比較好,可能是對於合作店家的要求比較嚴厲以及需要學員比較多次的潛水訓練吧?!

我自己找了找,其實在Brisbane的潛水器材店資料很混亂(游泳池與舞蹈訓練教室也是一樣超級混亂,根本不知道有甚麼網站可以分享這些資訊的?!)最後,我找到SSI在Stafford的DiveXsite, http://www.divexsite.com/

Stafford在哪?簡單的說,我坐公車大約單程要花一個多鐘頭(南部zone2到北部zone3)….如果是開車,根據Google Map的預估,大約是四十分鐘上下。

Read More