It's Alive!

I was able to start mnemonic and supporting infrastructure, load some patterns and examples, and query them using the mcp tooling!

Of course, it isn't perfect...yet. I ran into some challenges.

The biggest challenge is that I couldn't get any results back if the threshold was > 0.3. I want at least 0.7.

Technically, it's working, so the challenge is in the enrichment process.

Probably the biggest contributor was that the pattern documents get "chunked" up into discrete searchable patterns. These pattern docs are just markdown files, but do have a required schema:

---
name: your-pattern-name
entity_type: pattern-category
language: go
domain: backend
description: One sentence describing what this pattern teaches and when to use it. Keep under 500 characters.
tags:
  - keyword1
  - keyword2
related_patterns:
  - related-pattern-name
---

# Your Pattern Name

## Overview

Context, motivation, and when to use this pattern. Overview is never indexed, so place introductory material here. Explain the problem this pattern solves and why it matters.

[//]: pattern

## Section Title

Content indexed as a searchable chunk. Includes code examples, named techniques, implementation details — anything useful to retrieve later.

[//]: pattern

## Another Section

More indexed content. Each decorated section becomes a standalone search result, with the heading as the title.

The [//]: pattern acts like a decorator that lets the mnemonic enrichment process know what the patterns and examples are. The issue was that the patterns were being chunked as they are, with no metadata from the frontmatter. It doesn't lend itself to more natural, semantic searching.

Not enough metadata included in the chunk

As an example, if I searched using, "examples and patterns for error handling in go" mnemonic would return an empty set.

But if I searched specifically for, "go error handling", I'd get results, if the threshold was dropped to 0.3.

After discussing with Claude, I decided that when a chunk is vectorized, it needs to include info in the parent document's frontmatter.

Switched embedding models

I had been using text-embedding-3-small. I thought that would be more than enough with 1536 dimensions. I switched models to text-embedding-3-large, which should help improve performance with natural language queries; this remains to be tested.

The only challenge with switching models was in PGVector. It only supports a max value of 2000 (vector(2000)). Fortunately, text-embedding-3-large supports Matryoshka Embedding (something I learned about today).

I'd like to use the full 3072 dimensions of the large embedding model, but that will require me to move to Qdrant or Milvus. I'll make the move once I'm preparing Mnemonic to be a pure cloud-based solution.

Beyond that, I think having it run, accept and enrich patterns, then return queries using the MCP tooling is HUGE!