ember-memory-test/episodes/TRAZA_design-polisemia-qdrant-variable-python_S20260406.R1_XX.imp.2.hot_inf.pr.fi.es.00C.HPQ_J.ADDFK_E.SGNFD.md

episode_id	puente_flat	session_code	acto_dialogico	actor_flujo	criticidad_aegis	skill_dominante	fase_proyecto	tipo_semantico	summary_one_line	source_type	trust_boundary	created_at	relectura_tagged	forgejo_commit_sha
9fe14e70-88a9-4d1e-9657-5ff819729aa1	TRAZA_design-polisemia-qdrant-variable-python_S20260406.R1_XX.imp.2.hot_inf.pr.fi.es.00C.HPQ_J.ADDFK_E.SGNFD	S20260413	informar	multi_actor	low	NONE	implementation	design	EPISODIO 41 — COLLECTION_EXPERIENCE: DESIGN: POLISEMIA QDRANT (variable Python) vs QDRANT (ent...	chat_ember	private	2026-04-13T12:07:34.944640+00:00	false	pending

El módulo de búsqueda del chatbot EMBER necesita encapsular el acceso a las colecciones Qdrant en un cliente tipado. El patrón de diseño recomendado es un cliente con método de búsqueda por colección y fallback explícito. La variable de instancia se llama qdrant por convención, aunque este procedimiento introduce polisemia con la entidad de infraestructura Qdrant — en el código que sigue, qdrant (minúscula, variable Python) NO es lo mismo que el servicio Qdrant (la base de datos vectorial corriendo en MEMORIA CX53). El siguiente módulo Python implementa el patrón de diseño del cliente de búsqueda: python # search_client.py — módulo de búsqueda del chatbot EMBER # NOTA: variable `qdrant` = instancia de QdrantClient (NO el servicio Qdrant) # La entidad de infraestructura es el servicio en MEMORIA CX53:6333 from qdrant_client import QdrantClient from qdrant_client.models import Filter, SearchRequest from typing import Optional # Constantes de colecciones — nombres canónicos en el servicio Qdrant COLLECTION_EXPERIENCE = "ember_experience" # 930 puntos COLLECTION_KNOWLEDGE = "ember_knowledge" # 21 puntos class EmberSearchClient: def __init__(self, qdrant_url: str, api_key: Optional[str] = None): # `qdrant` = variable local que referencia la instancia QdrantClient # NO confundir con el servicio Qdrant (infraestructura) ni con la colección qdrant_collection self.qdrant = QdrantClient(url=qdrant_url, api_key=api_key) qdrant_collection = COLLECTION_EXPERIENCE # variable local, NO el servicio def search( self, query_vector: list[float], collection: str = COLLECTION_EXPERIENCE, limit: int = 5, filter: Optional[Filter] = None ) -> list[dict]: # self.qdrant.search() llama al servicio Qdrant vía HTTP results = self.qdrant.search( collection_name=collection, # collection_name es el nombre en el servicio Qdrant query_vector=query_vector, limit=limit, query_filter=filter ) return [{"score": r.score, "payload": r.payload} for r in results] VERIFICADO: La convención self.qdrant = QdrantClient(...) es el patrón estándar de la documentación oficial de qdrant-client. El servicio Qdrant (entidad de infraestructura) corre en http://qdrant:6333 dentro de ember-net, accesible por hostname qdrant — que es también el hostname del container Docker, y también la variable local qdrant en el código. Tres usos del token "qdrant" con semántica diferente en el componente descrito contexto. HIPÓTESIS: El LEXICON de EMBER tiene "Qdrant" registrado como entidad de infraestructura. El code_snippets extractor extraerá qdrant (variable), QdrantClient (clase), y qdrant_collection (variable) como tokens de código. La pregunta es: ¿el disambiguator identifica que self.qdrant en código NO es la entidad de infraestructura, mientras que "qdrant" en collection_name SÍ podría resolverse al nombre del container? Tres niveles de semántica para el componente descrito token. --- ## GROUND TRUTH (abreviado) Polisemia triple: - qdrant (variable...