The session had a clear proposal: to show that building a real product with generative AI requires
much more than calling an LLM, sending a prompt, and waiting for a nice-looking answer.

In simple demos, it is common to see a PDF being split into chunks, embeddings being stored in a
vector database, and a question being sent to the model. That helps explain the concept, but it is
far from representing the complexity of a real application.

In a real product, AI is not just a prompt. It is architecture, data, security, cost,
observability, fallback, and well-retrieved context.

Beyond basic RAG

Fernando started by showing that traditional RAG solves only part of the problem. The idea of
retrieving context and sending it to the model remains essential, but when the domain becomes more
complex, retrieval needs to be smarter.

A model does not know the user, the job opening, the professional profile, the experiences, the
skills, or the specific data of an application. That is why the system needs to retrieve the right
information, at the right moment, with as little noise as possible.

The challenge is that vector search alone is not always enough. It works very well for semantic
similarity, but it can fail when the question depends on exact terms, such as technology names,
versions, frameworks, or very specific keywords.

That is where hybrid RAG comes in.

The product: Interview

To move beyond theory, Fernando presented Interview, a product he has been building
as a career assistant and intelligent chatbot for professional profiles and job opportunities.

The idea is to allow a professional to register information such as summary, experience, skills,
projects, soft skills, and career history. From there, the system can help the candidate improve
the profile or allow a recruiter to ask questions about that person.

On the other side, the user can also analyze a job opportunity, chat with it, and understand whether
there is a fit with their profile. Instead of only displaying static data, the product turns
professional information into a conversational experience.

This context makes the problem more interesting. It is not enough to throw the whole résumé into
the prompt. That would increase cost, consume tokens, and could reduce the quality of the answer.
The system needs to select only what really matters for each question.

Vector search + text search

The solution presented combines two strategies: vector search and
text search.

Vector search transforms text into embeddings, allowing the system to find content with similar
meaning even when the words are not exactly the same. Text search works better when the question
depends on specific terms, such as Java, RabbitMQ,
Spring Boot, AWS, or technology versions.

Instead of choosing one or the other, Fernando showed a hybrid approach. The system searches through
both paths, combines the rankings, and prioritizes the most relevant chunks.

To do that, he uses a technique called Reciprocal Rank Fusion, or RRF, which helps
merge vector search and keyword-based search results into a final ranking.

In practice, this improves the quality of the context sent to the model. The system stops depending
only on approximate semantics and also considers exact occurrences that may be decisive for answering
correctly.

PostgreSQL as a vector database

Another important point was the choice of PostgreSQL as the foundation for storing
relational data, text, and vectors.

Instead of starting with a new infrastructure layer only for vectors, Fernando showed that, for many
scenarios, Postgres with extensions such as pgvector can already work very well.

This choice reduces complexity. Relational data, metadata, tenant filters, profile IDs, chunks, and
embeddings can live in the same ecosystem. That makes queries, data isolation, and early product
evolution easier.

The message was pragmatic: before adding another piece to the architecture, understand whether the
problem really requires it. In many applications, the bottleneck may not be the vector database, but
the model, the API, latency, cost, or the way context is being assembled.

Guardrails are not a single layer

The guardrails section was one of the strongest parts of the session. Fernando made it clear that
security in AI applications does not depend only on a sentence in the prompt or a single filter in
the code.

Guardrails need to be designed in layers.

That includes input validation, question length limits, rate limiting, tenant isolation, context-bound
scope, instructions against prompt injection, language control, fallback behavior, response limits, and
clear rules about what the model can and cannot answer.

During the demonstration, prompt injection attempts were tested, such as asking the model to ignore
previous instructions, list database users, or reveal internal instructions. The system responded within
the expected scope, keeping the focus on the professional profile and refusing behaviors outside the context.

This is essential for any real product. An AI application needs to handle users trying to force answers,
extract private information, change the model’s behavior, or ask questions outside the domain.

Defense, cost, and latency

Fernando also showed that every defense layer has a cost. It is possible to classify the input before
sending it to the model, filter the response afterward, use another model to evaluate risks, apply
antibot rules, and make the application more robust.

But all of that adds latency, extra calls, and operational cost.

That is why the architecture needs to balance security, user experience, cost, and product criticality.
Not every application needs the same level of protection, but every real application needs to think
seriously about this topic.

Java is already AI-ready

The session also reinforced an important message for the Java community: developers do not need to
leave the Java ecosystem to build products with artificial intelligence.

Fernando mentioned tools and possibilities such as LangChain4j,
Spring AI, Spring Data, Hibernate Search,
Hibernate Vector, PostgreSQL, pgvector, local models with Ollama, and integrations
with different LLM providers.

Java remains a strong option for enterprise products, especially when the solution requires integration
with existing systems, security, observability, scalability, cost control, and well-defined architecture.

AI may start as an experiment, but when it becomes a product, it needs engineering.

Final thoughts

SouJava Sessions #007 showed that there is a major difference between an AI demo and a real AI product.

A demo can work with a prompt, a few chunks, and a model call. A real product needs high-quality context
retrieval, data protection, user isolation, cost control, observability, error handling, and mechanisms
to keep the model inside the expected scope.

Fernando Gomes’ presentation was valuable precisely because it showed this path using Java, architecture,
and real product decisions. Hybrid RAG, vector memory, and guardrails stopped being buzzwords and became
concrete pieces of a working solution.

For Java developers, the message is clear: the ecosystem is ready. The challenge now is to move beyond
tutorials, understand real problems, and build AI solutions with technical responsibility.

SouJava Brasília continues as a living movement: where knowledge, technology, and community come
together to shape better professionals and build more relevant solutions.