Telegram 밈을 위한 시맨틱 검색. 러시아어나 영어로 질문하세요 — 어렴풋이 기억나는 밈을 찾아드립니다.
파이프라인: Telegram 내보내기 → 비전 캡션(이중 언어) + OCR → 다국어 임베딩(bge-m3, 로컬) → PostgreSQL/pgvector 하이브리드 검색(dense + full-text, RRF) → cross-encoder 리랭킹. CLI, 웹 UI, MCP 서버로 제공되므로 AI 어시스턴트도 여러분의 밈을 검색할 수 있습니다.
전체 아키텍처는 디자인 스펙에서 확인하세요.
cp .env.example .env # fill in OpenRouter API key
make up # PostgreSQL + pgvector on :5433
make test
uv run memgrep ingest # load data/result.json + photos into the db
uv run memgrep caption --limit 400 # describe images via a vision model (pilot)
uv run memgrep embed # local bge-m3 embeddings
uv run memgrep search "this is fine" # CLI search; --open shows files in Preview
uv run memgrep serve # web UI on localhost:8000
uv run memgrep evals # golden-set metrics for the current config
uv run memgrep sync # ingest + caption + embed for new exports
uv run memgrep watch # follow the channel via Bot APITelegram 내보내기 결과물은 data/에 저장됩니다(Telegram Desktop → Export chat history → Photos, JSON 형식). 밈과 내보낸 데이터는 로컬에만 남습니다 — data/는 gitignore 처리되며 코드만 공개됩니다.
Related MCP server: local-docs-mcp
UI 피드백 버튼("это он ✓")으로 수집한 21개 쿼리 골든 세트와 400개 이미지 파일럿 코퍼스로 측정했습니다. 각 검색 계층은 성능이 입증된 후에만 추가되었습니다:
계층 | hit@5 | hit@10 | MRR |
dense 벡터만 | 0.857 | 0.905 | 0.768 |
+ full-text 검색, RRF 융합 | 0.905 | 0.952 | 0.815 |
+ cross-encoder 리랭커 | 0.905 | 1.000 | 0.839 |
동일한 코퍼스와 골든 세트에서 캡셔닝 모델을 비교했습니다: qwen3-vl-8b는 검색 지표에서 qwen3-vl-235b와 동률이거나 더 우수했고 비용은 1/3에 불과했으므로, 전체 코퍼스는 8b 모델로 인덱싱되었습니다(약 $3.6, 약 11k 이미지 기준). evals 이력에 기록된 주의사항: 골든 세트는 8b 인덱스를 기반으로 수집되었기 때문에 비교 결과가 8b 모델에 유리하게 치우칩니다.
검색 설정은 환경 변수로 제어됩니다: MEMGREP_SEARCH_MODE=vector|hybrid, MEMGREP_RERANK_ENABLED=true|false. memgrep evals는 구성별로 타임스탬프가 찍힌 JSON을 evals/results/에 기록하므로 실행 간 비교가 가능합니다.
Claude(또는 모든 MCP 클라이언트)가 여러분의 밈을 검색할 수 있습니다:
claude mcp add memgrep -- uv run --directory /absolute/path/to/memgrep python -m memgrep.mcp_server도구: search_memes(query, k)는 파일 경로와 캡션이 포함된 일치 항목을 반환하고, get_meme(sha256)는 이미지 자체를 반환합니다.
memgrep watch 명령은 Bot API 롱 폴링을 통해 Telegram 채널을 실시간으로 팔로우합니다. 봇을 채널 관리자로 설정하고 MEMGREP_TG_BOT_TOKEN과 MEMGREP_TG_CHANNEL_ID를 구성한 다음 watcher 서비스를 실행하세요. 채널에 새로 올라온 사진은 자동으로 인덱싱되어 몇 분 안에 캡션 생성, 임베딩, 검색 가능 상태가 됩니다. 최근 게시물의 리액션도 참여도 추적을 위해 데이터베이스에 다시 동기화됩니다.
Python 3.12+, uv, PostgreSQL 17 + pgvector, sentence-transformers (BAAI/bge-m3 임베딩, BAAI/bge-reranker-v2-m3 리랭커, 둘 다 로컬), 캡셔닝을 위한 OpenAI 호환 비전 엔드포인트(기본값: OpenRouter, qwen3-vl), FastAPI, typer, MCP Python SDK. 테스트 49개, 테스트 스위트에는 네트워크 연결이나 모델 다운로드가 없습니다.
Return the meme image itself by sha256 from a search_memes result.
| Name | Required | Description | Default |
|---|---|---|---|
| sha256 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It states the core behavior (returning the image binary for a given hash) and implies a read-only action, but it does not disclose output format (e.g., binary, base64), error conditions, or whether any authentication is required. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. Every phrase contributes meaning: 'meme image itself' clarifies the return value, 'by sha256' identifies the key parameter, and 'from a search_memes result' indicates the source workflow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is largely complete: it identifies the input provenance, the operation, and the result. It does not mention potential errors or the exact binary format, but given the tool's simplicity the missing details are minor and unlikely to cause incorrect invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name and type (string) with 0% description coverage, so the description must add meaning. It does this by explaining that the sha256 parameter comes from a search_memes result, giving the agent crucial context on how to obtain a valid value. It could specify the expected format (e.g., hex-encoded SHA-256), but the guidance is already helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and names a precise resource ('the meme image itself') with a clear retrieval mechanism ('by sha256'). Referencing 'from a search_memes result' distinguishes it from its sibling tool search_memes, which presumably returns metadata or search results rather than the image content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the intended usage: call this tool with a sha256 obtained from search_memes to fetch the actual image. It doesn't explicitly state exclusions or when to prefer alternatives, but for a simple single-purpose tool the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic search over the meme collection. Query in Russian or English.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden; it does convey that matching is semantic rather than exact and that the query language is flexible. It does not state read-only behavior, result ordering, or limitations, but for a simple search tool the disclosed traits are non-trivial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences carry the essential message, with the main action stated first and no filler. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search with an output schema, the description is nearly sufficient, but it leaves two gaps: the meaning/behavior of 'k' and the relationship to the sibling get_meme tool. This is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning to 'query' by explaining the search is semantic and accepts Russian or English, but it remains silent on the 'k' parameter. The compensation is partial, making this minimum viable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Semantic search over the meme collection') and the 'semantic' qualifier distinguishes it from a direct fetch like get_meme. It is clear, but it does not explicitly name or contrast the sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Semantic search over the meme collection' implies when the tool is relevant, and 'Query in Russian or English' gives practical input guidance. However, it offers no explicit direction on when to choose this over get_meme or what types of queries are not appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have clearly distinct purposes: one performs semantic search over the collection, the other retrieves a specific image by hash. There is no overlap or ambiguity between them.
Both tools follow the same verb_noun pattern in snake_case: search_memes and get_meme. The singular/plural variation is natural for resource action and does not break consistency.
With only two tools, the server feels thin and sits at the low end of the borderline range. However, the narrow purpose of search and retrieval justifies a minimal surface, so it is not unreasonable.
For a read-only meme search and retrieval server, the surface is complete: search returns hashes and get_meme fetches the image. There are no dead ends or missing core operations within this defined scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Memory system for AI agents with semantic search. Store and recall memories with ease.
Persistent memory for AI agents. Search, store, and recall across sessions.
Persistent memory for AI agents. Semantic search, memory graph, W3C DID identity.
Persistent AI memory with semantic search, conflict detection, and ticketing.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Milflopper/memgrep'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
