Skip to main content

Assistant Logs

This feature has a somewhat cumbersome name for humans. People would rather call it an FAQ system based on questions and corresponding answers. Since assistants are very familiar with logs and the logs principle, we chose "logs" as name.

  • Enable the tool "log", to allow your assistants to log on their own.
  • Per default, when a search fails, the query and the tag used in that attempt get logged using a "search_logs_failed" tag. The original tag used by the assistant will be set as alias.
  • Logs structure
    • For Assistants.
      • Tag (primary tag)
      • Message (or "question")
      • Answer
        • The answer can contain plain text, or instructions to further guide the assistant.
        • If the tool "fetch_url" is enabled, you can instruct assistants via the answer field to fetch the content of a URL.
          • If the content of fetched URLs is HTML, it will get sanitized to reduce token usage and filesize overall.
          • But it can also be a URL to any file, that returns text format.
        • Or suggest the correct search term and tag, to find the information in need. For example:
          • "Use search_logs(query: 'Try this query', tags: ['with', 'this', 'tags']) to find the data the assistant are looking for."
    • Not for Assistants, but considered in the search.
      • Tag aliases
        • To link data in the background without affecting the token size for assistants. A tag can have dozens of aliases, so the data can also be found under other tags than the primary one.
      • Search Terms
        • Additional terms, the data should be found with.
      • Is Private, a quick way to hide logs from assistants.
  • Advanced Search Algorithm
    • Fuzzy Matching:
      • The algorithm splits incoming queries into individual terms and uses both strict and flexible filters.
      • This allows even short or imprecise questions to trigger relevant results by scoring partial matches and awarding bonus points for full matches.
    • Multi-Filter Approach:
      • By combining multiple filters (including exact matches, partial matches, and alias searches), the algorithm can search both the primary "message" field and additional fields such as "answer" and "searchTerms".
    • Exclusion of Special Records:
      • To prevent interference with data meant only for internal use, the algorithm automatically excludes any log entries with the special message "FEL_FULL_FAQ" unless that query is explicitly made. This keeps the FAQ data isolated from regular queries while remaining accessible for specialized tasks.
    • Scoring and Ranking:
      • After collecting potential log entries, the algorithm evaluates them based on the presence and frequency of query terms. The logs are then scored and sorted so that the most relevant entries appear first, ensuring high-quality answers are returned promptly.
    • Fallback Mechanism:
      • In case the initial strict search returns no results, a fallback procedure is triggered. This employs a more lenient matching strategy (using an OR connection instead of AND) to retrieve logs with partial keyword matches. This flexibility helps overcome unpredictable user inputs.

If you want to store big chunks of data (eg. for special tasks backend assistants can do), but don't want that assistants in general find that content (because too much), set its message as: "FEL_FULL_FAQ" and paste your FAQ content into the answer field. This content is only accessible, when assistants search for "FEL_FULL_FAQ".