Sectores y YAML

Cada empresa Queria pertenece a un sector (sector) y opcionalmente a un sub-sector (subSector). La configuracion vive en archivos YAML versionados en el repositorio, que describen el dominio semantico del sector: que entidades existen, como se llaman en lenguaje natural, que medidas agregar, que reglas de acceso aplicar.

A partir de la v3.5.0 estos YAMLs son mucho mas ricos: incluyen tags, domain terms, dimensiones con alias, medidas, jerarquias y politicas de confidencialidad.

Sectores disponibles

Queria incluye 26+ sectores out-of-the-box:

Categoria	Sectores
Servicios profesionales	LEGAL, FINANCE, INSURANCE, BANKING, HR
Sanitario	HEALTHCARE, PHARMA, RESEARCH
Industria	MANUFACTURING, AUTOMOTIVE, ENERGY, ENGINEERING, CONSTRUCTION
Bienes de consumo	FOOD, ECOMMERCE
Transporte	LOGISTICS, TELECOM
Publico	GOVERNMENT, EDUCATION, NONPROFIT
Servicios	HOSPITALITY, TOURISM, SUPPORT, MEDIA, REAL_ESTATE, AGRICULTURE
Generico	CONTRACT, TECHNICAL, GENERIC, CUSTOM

Cada sector tiene un archivo YAML en backend/src/config/sectors/<sector>.sector.yml y se carga al inicio por el sector-loader.

Anatomia de un sector YAML

Ejemplo (extracto de legal.sector.yml):

sector: LEGAL
name: "Legale"
description: "Contratos, sentencias, normativas, actos legales"

typicalConcepts:
  - tipo_documento
  - parti
  - giurisdizione
  - data
  - materia
  - articolo
  - clausola

typicalQueries:
  - "Busca contratos con la sociedad X"
  - "Que sentencias afectan al condominio?"
  - "Que dice el articulo 5 del contrato?"
  - "Normativa sobre privacidad"

relevantMetadataFields:
  - document_type
  - parties
  - jurisdiction
  - date
  - matter
  - court

externalSources:
  - legal-sources

domainTerms:
  - contratto
  - sentenza
  - clausola
  - articolo
  - giurisdizione
  - parte
  - attore
  - convenuto

dimensions:
  - name: document_type
    type: string
    aliases: ["tipo documento", "tipo atto", "tipologia"]
    hierarchy: [category, specific_type]
  - name: parties
    type: string[]
    aliases: ["parti", "soggetti", "attore", "convenuto"]
  - name: date
    type: date
    aliases: ["data", "anno", "periodo"]

measures:
  - name: count
    type: count
    description: "Conteo de elementos"
  - name: distribution
    type: group_by
    description: "Distribucion por dimension"

accessPolicy:
  topicIsolation: true
  confidentialityRules:
    - role: READER
      exclude: ["CONFIDENTIAL", "RESTRICTED"]
    - role: EDITOR
      exclude: ["RESTRICTED"]
    - role: ADMIN
      exclude: []

yamlVersion: 1

Campos del sector

Identidad

Campo	Tipo	Descripcion
sector	enum	Codigo unico (uppercase, ej. LEGAL)
name	string	Nombre mostrado (ej. "Legale")
description	string	Descripcion breve, mostrada en la UI empresa

Lenguaje natural

Campo	Tipo	Uso
typicalConcepts[]	string[]	Conceptos que recurren en las preguntas, usados por el planner
typicalQueries[]	string[]	Preguntas tipicas, usadas como prompt del classifier
domainTerms[]	string[]	Vocabulario del sector: aumenta el score de chunks que los contienen y mejora la extraccion de metadatos

Tags y domain terms potenciados v3.5.0

Los domainTerms ahora se tambien estampan en chunks Qdrant como payload top-level (domainTerms) via el backfill sector-fields. Esto acelera el filtro retrieval ~5x y mejora el booster de pertinencia.

Dimensiones y medidas

dimensions[] -- atributos semanticos sobre los que tiene sentido filtrar, agrupar, comparar:

• name: nombre canonico (ej. parties)
• type: string | string[] | number | date
• aliases[]: sinonimos en lenguaje natural (ej. ["parti", "soggetti", "attore", "convenuto"])
• hierarchy[]: jerarquias opcionales (ej. [category, specific_type] para drill-down)

measures[] -- agregaciones aplicables:

• type: count | sum | avg | min | max | group_by

El planner LLM usa dimensiones y medidas para construir consultas estructuradas cuando el usuario pide agregaciones ("cuantos contratos del 2025?", "cual es la media de importes por categoria?").

Fuentes externas

externalSources[] -- lista los microservicios externos relevantes para el sector. Ejemplos:

• LEGAL -> legal-sources (Normattiva)
• FOOD -> food-sources (Open Food Facts)
• PHARMA -> pharma-sources (FDA, ClinicalTrials)
• TOURISM -> consume open-data via AI Constructor

Access policy

Politicas de confidencialidad por rol:

accessPolicy:
  topicIsolation: true
  confidentialityRules:
    - role: READER
      exclude: ["CONFIDENTIAL", "RESTRICTED"]

Significado: un usuario con rol READER no puede ver chunks con confidentiality en CONFIDENTIAL o RESTRICTED. Las politicas se aplican al filtrado Qdrant en runtime, independientemente de los topics.

Sub-sectores

Un sector puede tener sub-sectores (subSectors) que heredan la base y aplican deltas:

subSectors:
  contractDrafting:
    description: "Redaccion y revision de contratos"
    dimensions:
      - name: clause_category
        type: string
        aliases: ["categoria clausula", "tipo clausula"]

Los sub-sectores son utiles para empresas que comparten el sector base pero tienen especializaciones: ej. un despacho legal "tax" y uno "labor" tienen el sector LEGAL pero sub-sectores distintos con dimensiones mas finas.

En DB cada sub-sector es una fila de SubSector; la asignacion a la empresa se hace via Company.subSectorId. Sin asignacion, el routing sectorial no se activa y los chunks Qdrant no se enriquecen con los campos del sector.

Asignar un sector a una empresa

Desde el panel admin:

1. Empresas > [empresa] > Sector -> selecciona el sector del dropdown.
2. Opcional: elige un sub-sector.
3. Guarda. A partir de aqui los nuevos documentos ingestados seran estampados con los campos de sector.

Para empresas existentes anteriores a v3.5.0:

UPDATE "Company"
SET "subSectorId" = '<id-de-SubSector>'
WHERE id = '<companyId>';

Despues ejecuta los backfill para enriquecer los chunks ya en Qdrant (ver Ingestion DSL > Reingest).

Modificar un YAML

Los archivos *.sector.yml estan versionados en el repo. Para modificarlos:

1. Abre el PR sobre backend/src/config/sectors/<sector>.sector.yml.
2. Schema validado por Zod (_schema.ts): el build CI falla si invalido.
3. Bump yamlVersion de 1.
4. Deploy: al boot, sector-loader recarga los YAML, sector-seeder actualiza Sector y SubSector en DB.

Backfill despues de modificacion

Si anades/renombras domainTerms, considera re-ejecutar el backfill sector-fields en las empresas del sector, de lo contrario los chunks existentes no tendran los nuevos terms en payload.

Custom sector por tenant

Para tenants que no caben en los 26 sectores incluidos:

• Usa sector: CUSTOM con un YAML interno.
• Configura dimensiones/medidas/domain terms especificos para el dominio del cliente.
• Los documentos se indexan y buscan normalmente.

En V2 esta en roadmap la creacion de sectores custom desde UI (sin PR del archivo YAML).

Tags empresa (potenciados v3.5.0)

Independientemente del sector, cada empresa tiene un campo tags[] que funciona como etiqueta libre:

• Visible en la ficha empresa.
• Filtrable en busquedas cross-tenant (solo SYSTEM_ADMIN).
• Usado por el planner para desambiguar preguntas cuando el sector no basta (ej. "empresa con tag enterprise" -> usa template enterprise para el bot).

Anade los tags desde la ficha Empresa > Tags, separados por enter o tab.

Domain terms empresariales

Ademas de los domainTerms del sector, cada empresa puede anadir domain terms especificos desde la ficha:

• Siglas internas (ej. MOL, EBITDA-adj).
• Nombres de productos del cliente.
• Glosario terminologico de la empresa.

Se fusionan con los del sector cuando se evalua la pertinencia de los chunks, dando un boost explicito al lexico de la empresa.

---

Queria v3.5.0 -- Sectores YAML potenciados