Data Pipeline Tools for the AI Workloads You're Actually Building.

We focus on the data side - features, embeddings, retrieval pipelines, training data curation, inference observability - and integrate cleanly with model lifecycle tools (Vertex AI, SageMaker, MLflow, Weights & Biases, Comet). The line between data infrastructure and MLOps is blurry, and we deliberately stay on the data side because that's where most production AI failures originate. If you have model serving, experiment tracking, and registry already, Logiciel slots in to handle features and data without forcing you to abandon working tools. If you don't, we have integrations and reference architectures with the major MLOps vendors. We're explicitly not trying to be SageMaker or Vertex.

Pinecone, Weaviate, pgvector, Qdrant, Milvus, Chroma, plus OpenSearch and Elasticsearch with vector extensions - all native integrations. Vector DB choice is workload-dependent: pgvector for teams already on Postgres who want one less system, Pinecone for managed simplicity at moderate scale, Weaviate for hybrid search with metadata filtering, Qdrant or Milvus for self-hosted at scale. We don't push a preferred vector DB; we'll run a workload-grounded comparison if you're undecided. Embedding indexing happens as a Logiciel asset with versioning, so re-indexing on embedding model upgrades is a controlled, observable process - not a fire drill.

Embeddings are versioned as first-class assets, so when you upgrade your embedding model (OpenAI text-embedding-3-large to a newer version, or switching from OpenAI to Cohere or Voyage), Logiciel triggers downstream retraining and re-indexing as a managed workflow. The new embeddings sit alongside the old until evaluation passes; only then do you cut over consumers. This avoids the silent failure mode where an embedding upgrade improves average quality but breaks specific edge cases nobody re-tested. RAG eval pipelines (Ragas, TruLens, custom) integrate as observable assets so you have empirical evidence before cutover, not just vendor benchmarks.

Yes - training data curation, sampling, labeling integrations (Snorkel, Scale, Surge), and quality monitoring are first-class capabilities. Common workflows: assembling fine-tuning datasets with versioned filtering rules, deduplication, and quality scoring; training/eval splits with statistical comparison to ensure no leakage; PII scrubbing with documented procedures for audit; and continuous training pipelines that incorporate feedback loops (RLHF, evaluation results) over time. For regulated customers, we maintain audit trails on training data composition - increasingly important under EU AI Act and emerging US AI rules. We integrate with Hugging Face, Together AI, OpenAI fine-tuning APIs, and self-hosted training platforms.

Yes - and Cohere, Voyage, AWS Bedrock embeddings, Azure OpenAI, Anthropic embeddings (when available), self-hosted open-source embeddings (BGE, Nomic, Jina), plus custom fine-tuned embeddings on your own data. Embedding model selection is per-pipeline, not platform-level, so you can use OpenAI for one corpus and a self-hosted model for another (common for cost optimization or data sovereignty). We track embedding generation costs in the FinOps view so you can see the actual $/embedding tradeoff across providers and make informed decisions. Most customers run 2-3 embedding providers across their RAG portfolio.

We integrate with Ragas, TruLens, DeepEval, and custom evaluation pipelines as observable Logiciel assets, with evaluation results versioned and trackable over time. Common eval patterns: retrieval quality (precision@k, recall@k, NDCG), generation faithfulness (hallucination detection, citation accuracy), end-to-end task success (LLM-as-judge with human-in-the-loop calibration), and operational metrics (latency, cost per query). Evaluation runs as part of CI for changes to the RAG pipeline (new embedding model, new chunking strategy, prompt changes) and continuously in production for drift detection. For regulated customers, evaluation evidence supports EU AI Act compliance and emerging US AI auditability requirements.

If you're prototyping a hackathon RAG demo, probably yes - use a notebook and Pinecone and ship it. If you're shipping AI to users with SLAs, support tickets, and revenue impact, no - production AI needs production data infrastructure, and notebook-to-prod is where most AI projects fail. The threshold for needing Logiciel: when an embedding pipeline going wrong silently degrades user experience for hours before anyone notices, when training data drift surfaces in model performance with a quarter's lag, or when compliance asks 'show me the lineage of every training datapoint' and you can't. Start small (one production RAG pipeline, one feature store), expand as needs grow.