Method AddEmailEmbeddingGeneration
- Namespace
- MailFathom.Infrastructure
- Assembly
- MailFathom.Infrastructure.dll
AddEmailEmbeddingGeneration(IServiceCollection)
Registers the units of work that turn a message's passages into vectors.
public static IServiceCollection AddEmailEmbeddingGeneration(this IServiceCollection services)Parameters
servicesIServiceCollectionThe service collection.
Returns
- IServiceCollection
The service collection, for chaining.
Remarks
Separate from AddInfrastructure(IServiceCollection, Func<IServiceProvider, PostgresConnectionSettings>, PostgresTextSearchConfiguration, MailAnsweringBudget) because both of these resolve an ITextEmbeddingGenerator, which comes from the AI boundary and exists only where a deployment declared an embedding chain. Registering them beside the stores they write through would put a descriptor in every container that cannot be constructed in most of them, and a container that validates its descriptors on build — which is what a Development run does — then fails to start an instance that was never going to embed anything. Serving lexical search alone is a supported state, so the condition is expressed by not making the registration rather than by making one that would fail.
The three are one call because they are one decision: the backfill's unit of work is one message brought up to date by that same generator, the upkeep pass is that walk plus the transitions it completes, so a deployment that resolves none of them is the only other shape.
Semantic retrieval reads the same generator and is deliberately not here. It is asked for through a factory rather than injected, so its descriptor builds without one, and it has to: a search is served by every deployment, so registering it only where a chain was declared would make a lexical-only instance fail to resolve the search use case instead of serving it lexically.
Exceptions
- ArgumentNullException
Thrown when
servicesis null.