Framework: crewai (2025-04)
Issue: crewai with AzureOpenAI embeddings fixed
Mechanism cluster: M-storage-amplification
Notes: paper:bu with REPORTER-IMPLEMENTS-OWN-FIX-AND-RENAMES-TITLE-ANNOUNCING-FIX pattern (NEW) + ARCHITECTURAL-DEFECT-DEFLECTED-TO-VENDOR pattern. MOST PAPER-QUOTABLE SINGLE CRAI ROW. RENUMBERED FROM ORIGINAL PASTE (was "CRAI-009" but ID collision; renumbered to CRAI-014). Filed Apr 22 2025 by @Proxy-Pointer tagged bug. CLOSED Apr 25 2025 by Contributor @lucasgomide as completed (~3 days filing-to-close). Reporter 3 EXPLICIT ARCHITECTURAL-CONFUSION QUESTIONS (paper-strong evidence of M-cost-observability + M-storage-amplification intersection): (a) PAPER-QUOTABLE FOR v23 SECTION 1 INTRODUCTION: "Do the knowledge sources get embedded everytime the crew is run and therefore, consume tokens? Or only the first time?"; (b) "Where is the chromadb embedding database stored for the knowledge sources. I looked up CREWAI_STORAGE_DIR its empty."; (c) "I tried to clear knowledge memory using crewai reset-memories -kn after I have created knowledge sources using the embedder, and says Failed to reset knowledge memory." Three architectural-blackbox-questions about embedding behavior layered onto M-storage-amplification. Reporter cannot reason about cost from framework API surface -- exactly what type-level discipline addresses. CONCRETE QUANTIFIED COST: "I am giving a large JSON as a knowledge source to the crew using the Azure OpenAI embedder. Embedding it consumes > 1M tokens. Each time I run the crew, the embedding happens all over again." Per-crew-run amplification (distinct shape from MAST-014 per-call amplification). DEEP-DIVE-DEBUGGING: Reporter traced through CrewAI codebase + chromadb + openai_embedding_function.py and identified 3 EXACT bug-fix locations: Line 115 (added self._api_type == openai check), Line 130 onwards (Azure-specific embedding-create branch), Line 144 (.index access vs [index]). Plus argument-name-mismatches: chromadb code uses engine parameter while OpenAI new SDK uses model. REPORTER-IMPLEMENTS-OWN-FIX-AND-RENAMES-TITLE-ANNOUNCING-FIX pattern (NEW at n=1): Reporter changed issue title from "[BUG] crewai reset-memories -kn throws an error" to "[BUG] crewai with AzureOpenAI embeddings fixed" Apr 27 announcing self-implemented fix in title. PR never filed upstream. Closed by maintainer @lucasgomide as completed without upstream merge. NEW closure sub-shape (26th in taxonomy): closed-as-completed-without-PR-merge-with-user-local-fix. Closure semantics ("completed") do not reflect upstream resolution -- only that reporter has working private fork. ARCHITECTURAL-DEFECT-DEFLECTED-TO-VENDOR pattern: @Vidit-Ostwal Apr 24: "Seems like chroma db has issue making it somewhat incompatible with azure open ai. I found this active issue on there github: chroma-core/chroma#1770 related to the same." Maintainer-acknowledges-defect-deflects-to-upstream-vendor without coordinated fix (parallels PYAI-003 deflection-to-downstream-spec but at vendor layer rather than spec layer). Sub-mechanism within M-storage-amplification: re-embedding-every-crew-run-consumes-millions-of-tokens-with-Azure-OpenAI-broken-default-embedder. 3rd CrewAI row to M-storage-amplification cluster establishes 3 distinct sub-mechanisms across CrewAI alone: (CRAI-012) embedding-dimension-mismatch-forces-full-re-embedding + broken reset CLI; (CRAI-013) re-embedding-on-every-load-with-no-bypass-API; (CRAI-014) re-embedding-every-crew-run-consumes-millions-of-tokens. Cross-references chroma-core/chroma#1770.