Projects

Focus of the day

The day was dedicated to defining a practical strategy for summarizing very long texts and conversations in a way that can be used inside an enterprise AI and document-assistance stack. The work went beyond model comparison: it focused on shaping a realistic, cost-aware approach compatible with durable memory management.

Model selection by role

A first round of decisions clarified which models fit which purpose:

• For high-quality synthesis on very large inputs:
  • Gemini 2.5 Pro for its large context window
  • GPT-5.2 Thinking / GPT-5.4 for faithful, well-structured synthesis
  • Claude Opus 4.6 for readability and nuance
• For low-cost extraction workflows:
  • Gemini 2.5 Flash-Lite as the leanest option
  • Gemini 2.5 Flash as a cost/performance compromise
  • DeepSeek V3.x and Qwen 2.5 72B as credible alternatives for structured chunk-based extraction

Architectural decision

The key decision of the day was to avoid a single monolithic summary pass and instead adopt a staged pipeline:

1. chunking,
2. structured extraction per chunk,
3. merge and deduplication,
4. final consolidation.

Prompting was reframed accordingly: ask the model for key-idea extraction rather than narrative summarization. The target output includes categories such as main ideas, decisions, constraints, key facts, action items, and open questions, using strict JSON output.

Cost control and useful memory

A second major track focused on limiting the cost of continuous memory extraction:

• do not summarize every exchange by default;
• filter messages first and retain only durable information;
• prioritize user messages over every assistant response;
• trigger memory extraction only on significant events;
• separate raw recent context, compact durable memory, and full archives accessible through RAG.

The target pipeline therefore becomes: local rules → candidate fragments → deduplication → minimal LLM call → atomic storage.

Broader continuity

This work directly extends the monthly effort around OpenWebUI and the sovereign document stack: the goal is no longer only to have an interface or a RAG layer, but to make the extraction, capitalization, and reuse of useful conversational knowledge reliable. At the yearly scale, it strengthens the build-out of a sovereign enterprise AI foundation able to turn raw exchanges into reusable knowledge without uncontrolled cost growth or loss of architectural control.

Making OpenWebUI data operational

Today’s work focused on bringing OpenWebUI’s internal data under control to better operate a self-hosted document AI stack. A first stream of work clarified the JSON structure stored in chat and produced SQL queries that are actually usable to:

• extract messages from chat->'messages'
• rebuild question/answer pairs
• generate full conversation transcripts
• add transcript length, byte size, and last-24h filtering

Several technical details were also hardened: using json_array_elements(...) because the column is json rather than jsonb, converting Unix timestamps with to_timestamp(...) for chat_message.updated_at, and rendering JSON content cleanly with content #>> '{}'.

Consistency checks across files, chunks, and knowledge

A second major topic was the detection of inconsistencies across document_chunk, file, and knowledge. The analysis made it possible to clearly separate:

• files attached to a knowledge base through meta.data.knowledge_id
• technical standalone collections named file-<uuid>
• potentially orphaned or incomplete records

In a multi-database setup, the practical decision was to compare datasets in n8n instead of forcing local SQL joins. The resulting checks strongly suggest there are no orphans for the specific criterion document_chunk.vmetadata->>'file_id' vs file.id, shifting the investigation toward other causes such as incomplete metadata, chunks without file_id, or broader application-level inconsistencies.

n8n orchestration and OpenWebUI memory hardening

The orchestration layer was also improved through n8n: SQL-side aggregation before comparison, consolidation of rows into a single JSON payload, generation of a clean results_text field for prompts, parsing LLM JSON outputs, and branch synchronization with Merge in Combine mode.

At the same time, OpenWebUI memory behavior was clarified, especially the distinction between Memory, Notes, and Knowledge. Reviewing the Auto Memory function exposed several structural issues, leading to a clear conclusion: the concept is relevant, but the code as reviewed is not reliable enough for production without fixes and proper log-based instrumentation.

As part of the monthly effort to optimize OpenWebUI and consolidate a sovereign enterprise document AI stack, today’s work strengthens the annual trajectory: turning OpenWebUI into a controlled front-end backed by verifiable data, traceable workflows, and a governable document architecture.

Design and structuring of a publication platform dedicated to a multilingual technical timeline, with a data model able to support dated cards, editorial content, and bilingual categorization. Today's work focused on the architecture of daily, monthly, and yearly levels of reading, in order to achieve a coherent rendering both in detail and summary. Implementation was based on an Azure PostgreSQL database structured to clearly separate content, temporal groupings, and the tag repository. The schema included consistency checks on dates, identifiers suited for editorial use, and automatic timestamp management to ensure reliable updates. A French / English tag repository was also standardized to harmonize content qualification and prepare for clean use on the interface side. This work fits into the month’s dynamic to turn technical achievements into publishable content, and continues the annual trajectory of structuring a controlled, sustainable, and valuable stack as part of a professional product approach.

Work continued on SharePoint document retrieval, with a more user-oriented approach. The focus was no longer just on synchronization, but also on simplifying access to content and enabling its use in workflows. Research on packages, connectors, and recovery strategies built upon the previously laid foundations. The subject remains central for feeding an exploitable knowledge base. This continuity confirms the strategic importance of Microsoft 365 in the architecture.

In March, efforts shifted towards stabilizing and coherently assembling the components already explored. The focus was on the practical use of OpenWebUI, PostgreSQL, embeddings, and document processing. The objective was no longer just to compare, but to ensure that everything fits together within a reliable framework. This includes the performance, functional coherence, and limitations of the chosen components. The month was dedicated to an active consolidation phase.

March also shows a stronger willingness to transform completed work into publishable content. The reflection on a timeline, a technical portfolio, and the storytelling of achievements becomes more visible. The goal is to present topics in the form of accomplishments, decisions, tests, and concrete integrations. The technical aspects here begin to be reworked as assets for professional communication.

This month saw the emergence of several practical topics around OpenWebUI: response quality, system prompt, analytics, branding, and integration. Efforts focused on improving the tool’s actual behavior in professional production settings. This points to a gradual shift toward issues of user experience, management, and perceived value. The tool is no longer viewed solely as a technical component, but also as a product usable in a professional enterprise context.

Strengthening the link between architectural choices and a clear, business-oriented offer. The focus covers controlled hosting, confidentiality, document-based AI, and the business value of the assistants developed. Technical elements are gradually tied to a clearer service proposition. This is no longer just technical experimentation, but the transformation into a credible, professional business offering. This gives the month of March a more product-oriented and strategic dimension.

The month was also marked by more technical operational topics related to Azure, PostgreSQL, and the deployment environment. Efforts focused on the database, extensions, migrations, reverse proxy, and relevant managed services. Cost, simplicity, and robustness trade-offs were central concerns. The objective was to make the ecosystem more stable and more consistent with the intended uses. This consolidation supported professional AI and documentary experiments.

The experiments encountered very concrete constraints related to CPU, memory, and processing time. The work consisted in testing what could actually run on the Windows Server 2025 VM in terms of embeddings, local models, and overall load. Options that were too heavy were reconsidered in light of observed performance. Self-hosted viability became as important a criterion as theoretical quality. This led to more realistic and usable choices, notably migrating to a Linux Ubuntu VM hosted on Azure, which manages resources (CPU, RAM, and disks) more efficiently.

Instead of evaluating OpenWebUI in the abstract, the work focused on its real-world behaviors in a professional production context. Topics addressed include collection management, file addition, use of external parsers, and integration with RAG services. Functional limitations were more clearly identified. This made it possible to distinguish what should remain inside the tool and what should be moved outside. The role of OpenWebUI was refined as an interface layer rather than a complete solution.

The month marked a transition between the target architecture and concrete implementation. The work focused on how to connect an external retrieval, manage the index, and ensure the actual reliability of the system's behavior. Issues around deletion, updating, index reconstruction, and result consistency became more prominent. The challenge was to move beyond a simple prototype towards a usable workflow. This phase reinforced the operational dimension of the company's document management project.

Exploration of an architecture where indexing and retrieval are managed outside the chat interface. The work focused on the benefits of finer control over documents, vectors, and content lifecycle. This paved the way for advanced features such as reranking or hybrid search logics. The approach also allowed for a clearer separation of responsibilities between the interface, search engine, and ingestion pipeline. This orientation clarified the overall structure of the enterprise AI system.

Assessment of trade-offs between indexing quality, CPU cost, vector size, and feasibility on virtual machines. Several approaches were compared for document extraction and embeddings, with particular attention to stability. The topic was not only theoretical: it was necessary to identify what could actually be supported in the environment. This phase allowed us to rule out some overly resource-intensive options. It also prepared the ground for more pragmatic decisions in upcoming developments.

The work included synchronization logic, change tracking, and the preparation of a continuous feed for the document engine. Delta queries and library management were at the core of the considerations. The aim was to build a robust flow between Microsoft 365 and the knowledge base. This project is part of a professional, industrialized approach to document orchestration.

Consolidation of n8n as an automation layer to manage document flows and service calls. The work focused on structuring sub-workflows, managing configuration flows, and composing technical JSON objects. The approach aimed to make processes reusable and readable. This made it possible to prepare for the progressive industrialization of pipelines. n8n has begun to play a central role in assembling the building blocks.

Definition of a documentary foundation capable of ingesting, indexing, and delivering company content in an actionable way. The work covered the complete pipeline: extraction, splitting, embeddings, vector indexing, and retrieval. Several options were compared to maintain strong technical control without complicating operations. The objective was to establish a clear, modular, and sustainable architecture. This phase served as a basis for the decisions made in the following weeks.

Exploration of the exact role of OpenWebUI within a broader document architecture. The topic is not only the interface, but also the boundary between what should remain native and what should be externalized. The analysis focused on collections, embeddings, parsers, and the overall behavior of the system. The challenge is to avoid being limited by the tool in more ambitious use cases. This work has prepared a more decoupled approach between UI, indexing, and search.