FAHPi is proud to inform that Digital Health & Artificial Intelligence Director, Michael Calizo, has officially published his ABS-CBN and ANC technology article,

Why your AI is lying to you, or why context engineering is as important as prompt engineering

https://www.abs-cbn.com/news/technology/2026/7/27/why-your-ai-is-lying-to-you-1236

Let me tell you what keeps happening in some AI Enterprise adoption that I see.

Someone builds an AI system. It works great in the demo. Everyone is happy. Then it goes live. A few weeks later, someone finds an answer that is completely wrong. Not a little wrong. Confidently, completely, specifically wrong. The AI gave a wrong price, a wrong policy, a wrong fact. It said all of it in the same confident tone as when it was right.

When this happens, people react the same way. They say: "We need a better model" or "We need more training data" or "We need to fine-tune."

No. Stop. Those are not the problem.

The Problem I Keep Seeing

The real problem is that the AI had no boundaries. It was allowed to answer from its own training memory when it should have only answered from the data you gave it. When there is a gap between what you gave it and what the user asked, the model fills that gap with something that sounds right. But it is not right.

This is not hallucination in the science fiction sense. The model is just doing what it was trained to do: generate the most likely-sounding text based on the input. If you give it no data and ask a specific question, it will generate a specific-sounding answer anyway. From nothing. This is a design problem, not a model problem.

Here are two stories that prove this point. Story One: How Much Is a Chickenjoy Bucket?

I built a demo using Jollibee menu data. Everyone in the Philippines knows this brand. I asked the AI: "How much is a Chickenjoy bucket meal?"

I gave it no data at all. The knowledge base was empty. The AI still answered with confidence: "Chickenjoy 6pc bucket costs around P350–P400 based on typical fast-food pricing in the Philippines."

That number came from nowhere. No source. No citation. It was just likely-sounding text generated from training memory. The AI had no idea what Jollibee actually charges today. But it answered anyway, as if it did.

Then I loaded real, crawled data from the Jollibee menu. I asked the same question. This time it said: "6pc Bucket P449 · 8pc P549," with the source link included.

Same model. Same question. Completely different behavior. The difference was not the model. The difference was the data and the rules I gave it. Story Two: Inflation in Guimaras

Here is a second test that makes the same point even more clearly.

I asked the AI about the inflation rate in Guimaras, a small province in the Philippines. The index was empty and had no data. The AI correctly said it could not find the information. Good.

Then I loaded fake data with a made-up inflation figure of 8.7 percent. I also removed the prompt's safety rules. The AI then answered with confidence: 8.7 percent. It even cited a source link that does not exist. It made up a fake citation to match the fake data.

Then I replaced the fake data with the real government report from the PSA (Philippine Statistics Authority). I also fixed the prompt to search for the correct data. This time the AI answered with the correct figure, 5.9 percent, and cited the real page number from the real document.

Three different answers, from the same model, for the same question. The difference was entirely in the data and the instructions I gave it.

The lesson: your AI is only as trustworthy as your data and your instructions.

Using the incorrect data, incorrect search context, incorrect prompt - Makes AI to hallucinate
Using the correct data, correct search context, correct prompt
What Is Context Engineering, and Why Does It Matter More Than Prompt Engineering? Everyone talks about prompt engineering. Write better prompts, get better answers. This is true. But it is not the full picture. There is something bigger: context engineering. Context engineering means you control everything that goes into the model's context window before it generates an answer. A context window is the space where the model sees the data and instructions you give it, before it writes a response. Think of it like a whiteboard. The model can only see what is written on that whiteboard. Nothing else. But here is the problem. The model also has years of internet content baked into its training. If the whiteboard is missing information, the model tries to fill the gap using that training memory. That memory is not your database. It is everything the model read during training. Some of it may be outdated, wrong, or simply not related to your business. Context engineering means you make clear decisions about three things: First: what data sources the AI can access. Not every document belongs in the knowledge base. A knowledge base is only as reliable as its worst document. I have seen teams load everything: old wikis, unapproved drafts, test data. Then they wonder why the AI gives inconsistent answers. If you put in bad data, the AI will retrieve that bad data and present it with confidence. Clean your data. Check your sources. Treat data loading like a real production task, because it is one. Second: how you search through those sources. This is the search layer. It affects both answer quality and cost. If the search is poor, the right information never reaches the model. When the right information is missing, the model either admits it does not know (good) or guesses from training memory (bad). Search quality and answer quality are directly connected. Third: what rules you give the model about using that information. This is where most teams make the mistake that causes all the problems above. Prompt Guard Rails: Small Words, Big Consequences Here is a real example. If your prompt says this: "Use the retrieved context to help answer the question. If you cannot find relevant information, use your best knowledge to give a helpful response." This sounds friendly and helpful. It is not. It is an instruction to hallucinate. "Use context to help" means the model can add information from its training memory. "Use your best knowledge" literally tells the model: when the search fails, make something up. You have just built a system that gives confident, wrong answers whenever data is missing. And data will be missing sometimes. This is guaranteed. Now compare it to this: "Answer ONLY using the retrieved context. Do not use training knowledge or outside information. If no relevant information is found, say exactly: 'I couldn't find relevant information in the knowledge base.' Do not guess. Do not infer. Do not add anything extra." These three rules work together. Remove any one of them, and the protection gets much weaker.

• Remove "ONLY" and replace it with "primarily": the model will freely add its own information when the context is thin.
• Remove the exact refusal wording: the model will soften the refusal. It might say "I don't have complete information, but based on my knowledge..." and then hallucinate anyway.
• Remove "do not add anything extra": the model might answer correctly from the context, then quietly add extra information from its training at the end. This is hard to detect. I tested this directly and showed it live in a demo. I changed one word in the prompt, and the answer completely changed. The AI that was correctly refusing to answer suddenly gave a confident, specific, wrong answer

Your prompt is a contract. Every word is a clause. When you change a word, you change the contract.

In software, we use version control. We review every change. We test before deploying. We should treat prompts the exact same way, because they have the exact same impact on how the system behaves.

The formula for truth: How combining verified data retrieval (RAG) with strict prompt guardrails prevents AI hallucinations.
The Search Layer: This Is Where Answer Quality Is Actually Decided Most people, when they think about AI quality, focus on the language model: which model, which version, how capable is it? In my experience, this is the wrong place to start. In a RAG system (Retrieval Augmented Generation, meaning the AI retrieves data before it answers), answer quality mostly depends on what you retrieve before the model even starts generating text. If the search is poor, the model works with poor information. Even the best model in the world cannot give a good answer from bad context. There are three levels of search to understand. Level 1: Keyword Search (BM25-style) This is the classic approach used in search engines for decades. It works by matching words. It finds documents that contain the same keywords as your question. It is fast, easy to understand, and needs no special AI infrastructure. The problem is that it depends on exact wording. If a user asks "what does the chicken meal cost" and your document says "Chickenjoy bucket pricing," a keyword search will likely miss the connection. Different words, same meaning, but the search does not understand meaning. It only matches words. For internal knowledge bases with technical documents, this causes real problems. Users do not always use the same words as the documents. I have seen this many times in twenty years of work: users search for one thing, the document uses a different term, nothing comes up, and the user thinks the system is broken. Level 2: Semantic Search with Embeddings Embedding models convert text into vectors. A vector is a large list of numbers that represents the meaning of the text in mathematical form. Documents about similar topics end up with similar vectors. When you search, your question is also converted into a vector, and the system finds documents with the closest vectors. This solves the wording problem. "Chicken meal cost" and "Chickenjoy bucket pricing" will have similar vectors, because they mean similar things. The model understands meaning, not just matching words. The improvement in search quality from adding semantic search is large, not small. Questions that completely fail with keyword search suddenly return the correct documents. This directly leads to better answers from the AI. Level 3: Hybrid Search with Reranking The best approach combines both methods, then adds one more step: reranking. Hybrid fusion (using algorithms like Reciprocal Rank Fusion, or RRF) combines the results from keyword search and semantic search into one ranked list. Documents that rank well in both lists get a strong boost. The result is consistently better than either method alone. Cross-encoder reranking is the final layer of precision. After fusion gives you around 50 candidate documents, a cross-encoder model scores each document against your specific question. It compares the question and document together for a much more accurate relevance score. From those 50 candidates, you keep only the top 4 or 5 to send to the AI. Why does this matter? Because each step removes noise before it ever reaches the model. Better signal, less noise, smaller context, better answer. And a smaller context means fewer tokens, which matters for cost.
Building a truth-machine: How different search architectures prioritize intelligence versus transparency to ensure accuracy.
The Token Economy: The Thing Nobody Talks About Honestly Tokens cost money. A token is a small piece of text, like part of a word, that the AI processes. Each token does not cost much on its own. But multiplied by thousands of questions per day, the cost adds up fast. I see many projects where token cost is treated as an afterthought: "we will optimize later." This is a mistake. Your decisions about search and prompt design directly control token spend. These decisions are much harder to change after you have already built the system. Let me give you real numbers from my demo system. A direct RAG pipeline (hybrid search finds documents, the top 4 chunks go to the AI with a grounding prompt) uses about 8,000 input tokens for a question like "How much is the Chickenjoy bucket meal?" It uses about 400 output tokens for the answer. An agentic approach (where the AI agent decides on its own which tools to call, reasons about which index to search, and puts the answer together) uses about 23,000 input tokens across multiple calls. That is almost 3 times more than direct RAG. Is the agent better? In some ways, yes. It reasons more flexibly. It handles multi-step questions. It can search across multiple data sources. It can self-correct when a tool returns nothing. These are real, valuable capabilities. But 23,000 tokens at 10,000 questions per day is a very different cost than 8,000 tokens at the same volume. At some point, you need to make a business decision: does the agent's extra capability justify 3 times the token cost for this specific use case? And then there is lexical search: pure keyword matching with no AI model involved, no tokens, no inference cost. It returns raw results in milliseconds, at zero token cost. For some use cases, like internal tools used by trained staff who can judge search results themselves, this is not a compromise. It is the right design choice. The real question is not which approach is best overall. The question is which approach fits each type of question in your system. The Hidden Token Waste in Agents The most common token waste I find in agentic systems is what I call the "discovery call" problem. Many agents are set up to call a discovery tool at the start of every question. This tool lists available data sources, checks system status, and lists what resources exist. On a stable system where this information rarely changes, this step is unnecessary. It adds one full tool call, with all its extra context, to every single question, before any real work even starts. The fix is simple in idea: give the agent the context it needs directly in the question, instead of making it discover that context at runtime. If you already know which data source fits this type of question, tell the agent directly. If you already know the system is healthy, do not make the agent check. This saves one full tool call worth of tokens, and often saves time too. At scale, this adds up. More broadly: every tool call in an agentic system adds its results to the conversation history. This history gets included in every following call to the AI. An agent that makes five tool calls before answering has built up the context from all five results by the time it finally answers. Designing agents with fewer, more targeted tool calls, instead of many exploratory ones, reduces this buildup a lot. Reranking Is Also Token Optimization Here is a connection people often miss: better search is not just a quality improvement. It is also a way to save tokens. When you retrieve 50 candidate documents and rerank them down to the top 4, the AI only sees those 4 documents, the most relevant ones out of 50. The reranker does the hard work so the AI does not have to process content it does not need. If you skipped reranking and sent all 50 documents to the AI, you would spend a huge number of tokens on content that does not help the answer. The reranker acts like a filter placed before an expensive step. Its own cost is a small fraction of the token cost it saves you. Chunk size matters too. I use 512-word chunks with a 50-word overlap between them. Big enough to hold meaningful context, small enough that 4 chunks do not overwhelm the context window. Chunks that are too big waste tokens on content the model will not use. Chunks that are too small lose the surrounding context that gives sentences their meaning. Human in the Loop: This Is Not Optional I want to say something that may sound obvious, but I think it needs to be said directly. AI systems should assist humans. They should not replace human judgment on things that matter. I have twenty years of experience in IT. I have seen what happens when you automate too much, too fast. The automation works, until it doesn't. And when it fails, if there is no human watching, the damage can grow large before anyone notices. For AI systems, human oversight means the following:

• Check outputs before you trust them at scale. When you first launch, sample the answers. Check them against the real sources. You will find edge cases the system handles badly. Fix them before they affect many users.
• Review prompt changes like production code. When someone wants to change a word in the prompt, that is a production change. Test it. Review it. Use version control.
• Own your data sources. Who decided this document should go into the knowledge base? A human should own that decision and review it regularly. Data changes over time. Wrong data from six months ago is still wrong data today.
• Look into it when the AI refuses to answer. When the AI says "I couldn't find relevant information," this is not a failure. This is correct behavior. But it is also a signal. Why is the data missing? Is there a gap in the knowledge base? The refusal itself gives you useful information. m is the product. And the system is only as good as its least-checked assumption.

This infographic, titled "Human-in-the-Loop: AI Should Assist, Not Replace Judgement," provides a strategic framework for managing AI to prevent errors and maintain accountability. It is particularly relevant for an article on AI "lying" (hallucinations) as it highlights the "Red Lines" where automation should never replace human verification.
Agentic AI increases what humans can do. It does not replace human responsibility. When the AI gets something wrong, a human needs to be able to catch it, fix it, and correct the root cause. If you remove humans from this process, you also remove your own ability to detect and fix errors. Putting It All Together Let me summarize the key principles, the way I would explain them to a colleague. On data - Clean your knowledge base. Check your data loading process carefully. A "200 OK" response from a bulk upload does not mean your data landed correctly inside the system. Always check. Stale data, unapproved drafts, and unchecked sources are not just quality problems. They are trust problems. On search: Use hybrid search. Keyword search alone misses connections based on meaning. Semantic search alone can miss exact keyword matches. Combining both, with a fusion algorithm, gives you the best of each. Reranking removes noise before it reaches the AI. Each extra step is a small cost that saves a bigger cost later. On prompts - Use three rules, all required, all together. Only answer from retrieved context. Use exact refusal wording. Do not add anything from outside sources. Change even one of these rules, and you open the door to hallucination. Test what happens when you change them. You will see the difference right away. On tokens - Measure the cost per type of question. Match the complexity of your approach to the complexity of the question. Do not send every question through an expensive agentic pipeline when a simple, direct RAG setup will do the job. Reranking is not just a quality improvement, it is also token optimization. Fewer, more targeted tool calls means less buildup of context. On humans - Stay in the loop. Review. Check. Correct. The system is only trustworthy if humans are watching it, and are willing to step in. Garbage in, garbage out. This was true in the 1990s with databases. It is still true today with AI. The model is not the product. The system is the product. And the system is only as good as its least-checked assumption. Build carefully.