| --- |
| library_name: concept-memory-model |
| tags: |
| - text-classification |
| - multi-task |
| - pytorch |
| - transformers |
| datasets: |
| - mteb/banking77 |
| - nyu-mll/glue |
| - google/boolq |
| --- |
| |
| # Concept Memory typed judgment base model |
|
|
| This repository contains the task-fine-tuned Concept Memory checkpoint for |
| criteria-conditioned Choice, ordinal Score, and Yes/No (Noul) judgments. It is |
| not a language model pretrained from scratch. Its text encoder is |
| `sentence-transformers/all-mpnet-base-v2`. |
|
|
| ## What is the problem? |
|
|
| Typed decision models can return structured outputs such as a Choice label and |
| its probabilities. In a domain workflow, teams may also need to understand |
| which reusable ideas are relevant, apply domain knowledge consistently, and |
| adapt those mappings as policies change. A prediction by itself does not |
| provide those capabilities, and a probability is not an explanation. |
|
|
| Concept Memory is designed to explore this gap. It supports three judgment |
| types: |
|
|
| - **Choice:** select one criterion, such as a support team. |
| - **Score:** estimate an ordinal position among supplied criteria. |
| - **Noul (Yes/No):** return a binary judgment. |
|
|
| ## What is the solution? |
|
|
| ### Theory |
|
|
| Concept Memory pairs a learned language representation with an optional, |
| editable Concept Bank. A concept describes a reusable pattern, such as |
| “integration failure,” and can link that pattern to outcomes such as |
| “Technical.” This separates some domain knowledge from the model's learned |
| weights, making the definitions and mappings easier to inspect, reuse, and |
| adapt across tasks. |
|
|
| This is a different design emphasis from a decision-only interface: the model |
| still returns a typed prediction, while the bank offers an additional path for |
| relating relevant concepts to outcomes. This is a potential architectural |
| benefit, not evidence of higher accuracy than Jev, Laya, or another model. |
|
|
| ### Technical design |
|
|
| The base model first predicts from the input state, question instructions, and |
| criteria. When a Concept Bank is supplied, a second Choice question ranks the |
| bank's concepts by relevance. The bank maps those concept signals to outcome |
| votes. The current helper adjusts probabilities only when the bank's top |
| outcome agrees with the base model's top outcome; when it does, it blends 20% |
| raw model probabilities with 80% normalized bank votes. The bank is therefore |
| constrained decision support, not an independent rule engine, and it cannot |
| overturn the raw model's winner. |
|
|
| Concept rankings and declared mappings make part of the decision process |
| inspectable. They are not causal explanations: relevance is a relative ranking, |
| not calibrated evidence, and it does not prove what caused the raw prediction. |
| The current implementation also does not independently detect each concept. |
| Concept hierarchies, dependencies, interventions, and provenance tracking are |
| future research directions, not capabilities of this checkpoint. |
|
|
| This architecture allows domain mappings to be changed without retraining the |
| encoder, but new concepts must still be evaluated on representative examples. |
| Accuracy, calibration, robustness, and latency should be compared on the same |
| data and conditions before making performance claims. |
|
|
| ## How can you use it? |
|
|
| ### Run the standalone Choice example |
|
|
| The local [`artifacts/base_model/example.py`](./example.py) script: |
|
|
| 1. Downloads the `Syigen/rgcm` repository snapshot from Hugging Face. |
| 2. Loads `model.pt` and constructs the model using its saved encoder settings. |
| 3. Creates a Choice question with Billing, Technical, and Sales criteria. |
| 4. Predicts a category for a sample Stripe integration problem, then prints |
| the chosen criterion and probabilities. |
|
|
| From the project root, install the dependencies and run it: |
|
|
| ```bash |
| pip install torch transformers huggingface_hub |
| python artifacts/base_model/example.py |
| ``` |
|
|
| The example demonstrates Choice. Score and Noul questions use the same typed |
| question interface with the appropriate `type` and criteria. The checkpoint is |
| a PyTorch artifact for this project's model class; it is not directly loadable |
| with `transformers.AutoModel.from_pretrained`. |
|
|
| ### Try the linked examples |
|
|
| - [Hugging Face `example.py`](https://huggingface.co/Syigen/rgcm/blob/main/example.py) is the hosted Python example file. |
| - [Open the Colab notebook](https://colab.research.google.com/drive/1LMLbdff8rAVxPy-qwcVI6iFROkjUk8EK?usp=sharing) to try the linked notebook. |
| - [Open the Concept Memory playground](https://dewmal--concept-memory-playground-playground.modal.run/) for interactive inference. |
|
|
| ### Add concepts |
|
|
| Concept Bank entries define a readable concept and the outcomes it supports or |
| contradicts. For example: |
|
|
| ```json |
| { |
| "id": "integration_failure", |
| "name": "Integration failure", |
| "description": "An API, SDK, or third-party integration is failing.", |
| "supports": ["technical"], |
| "contradicts": ["sales"] |
| } |
| ``` |
|
|
| Add concepts to the playground's Concept Bank field to see which ones rank as |
| relevant and how their links contribute to the decision. |
|
|
| ## Files |
|
|
| - `model.pt`: PyTorch state dictionary and training metadata. |
| - `config.json`: encoder, task, and training run metadata. |
| - `example.py`: standalone Python Choice example. |
|
|
| ## Training metadata |
|
|
| ```json |
| { |
| "datasets": [ |
| "mteb/banking77", |
| "nyu-mll/glue:sst2", |
| "google/boolq" |
| ], |
| "task_types": [ |
| "choice", |
| "score", |
| "noul" |
| ], |
| "encoder": "sentence-transformers/all-mpnet-base-v2", |
| "epochs": 50, |
| "batch_size": 32, |
| "seed": 42, |
| "model_version": "base-20261003-171325Z", |
| "generated_at": "2026-10-03T17:13:25Z" |
| } |
| ``` |
|
|
