📰 English IT Daily · 2026-07-19

Many people in tech and digital marketing want to know how ChatGPT decides which websites to use in its answers. Until now, much of the advice has been based on guesswork. People often say, “Write better content,” “Use list articles,” or “be active on Reddit.” However, a recent blog post took a different path. Instead of studying only the final answers on the screen, the writer looked at the network traffic sent to the browser. In simple terms, he examined the hidden JSON messages that support the reply. This approach does not reveal everything, but it offers a rare look under the hood.

The writer is careful about what his findings can and cannot prove. He says the research came from one logged-in Pro account over only a few days. The sample was also shaped by mostly SaaS and tech-related questions. Because of that, the study is not strong enough to measure broad market share or to rank websites with confidence. Still, it can document structural facts. For example, if a field appears clearly in the traffic, we can say that the system has that field and uses that label. That is different from large visibility studies, which may test thousands of prompts but still have to infer the internal process from the output alone.

One of the most interesting findings is that ChatGPT appears to attach internal labels to results. According to the blog, fields such as result_source, vendor names, search queries, model details, and turn_use_case could be seen in the captured traffic. The reported result_source values included labels like serp, bright, and oxylabs. The post also says these labels seem to point to specific providers or retrieval paths. In other words, the system may not rely on a single route to gather information from the web. It may draw from several channels behind the scenes, then combine or filter what it finds before showing citations to the user.

Another claim from the analysis is that different prompt types may trigger very different behavior. Simple text questions may skip the web entirely, while “Thinking” style requests can fan out into many extra searches, including site-specific checks and price verification queries. If that pattern is correct, then source selection is not one fixed process. It depends on the task. A quick factual request, a product comparison, and a deeper reasoning prompt may each send the model down a different path. This matters because users often treat every answer as if it were built in the same way, even when the system may be switching gears in the background.

For content creators, publishers, and engineers, this is both useful and a double-edged sword. On the one hand, the post gives a more grounded way to discuss visibility in AI tools. It suggests that appearing in answers may depend not only on content quality, but also on query type, retrieval path, and whether the system decides to search the web at all. On the other hand, the findings could be easy to overstate. A small sample can point researchers in the right direction, but it should not be treated as the final word. What shows up in one account, one region, or one topic area may not hold true everywhere.

The broader lesson is about transparency. AI products are becoming a bigger gateway to information, but their source-selection process remains hard to inspect. Reading network traffic is not the same as seeing the full model logic, yet it can still shine a light on how these systems operate in practice. For technical professionals, this kind of work is a reminder to separate what is observed directly from what is inferred later. As AI search tools gain traction, careful analysis will matter more than repeated myths. The next step is likely more independent testing across accounts, topics, and languages to see which patterns truly hold up.

A recent report says some LG monitors can cause software to be installed on Windows PCs without a clear consent step. According to tests highlighted by VideoCardz and carried out by Gamers Nexus, certain LG displays triggered Windows Update to install LG-related packages after the monitor was connected. Soon after that, a program called LG Monitor App Installer appeared on the system. Users did not see a normal approval screen before this happened, which is why the case has drawn attention.

The report became more controversial because the installed app did more than support monitor settings. In repeated tests, it often showed a promotion for a McAfee trial subscription. On most system boots in one test, the popup advertised that security product, while on another boot it promoted one of LG’s own monitor tools instead. The McAfee offer included a free trial that could later turn into a paid plan. For many users, that crosses a line because a monitor is expected to display images, not to act as a channel for marketing messages.

What makes the story more striking is that the behavior does not seem to be limited to brand-new hardware. Gamers Nexus also reported seeing the same kind of popup on an older LG monitor that had been bought several years earlier. In addition, user complaints about LG Monitor App Installer reportedly go back to at least 2024. Recent reports suggest the issue may be gaining traction across more models, although it is still not clear exactly how wide the rollout is or which monitors are affected.

At a technical level, the process appears to involve device metadata and Windows Update. In simple terms, when Windows recognizes connected hardware, it can also download related components or apps that the manufacturer has linked to that device. This can be convenient because it saves users from hunting down utilities by hand. However, it is also a double-edged sword. If the process is not transparent, users may end up with extra programs they never asked for, and they may not know which company is responsible for each step.

LG is not the only company using this route. The source notes that Dell also uses Windows Update to deliver Alienware Command Center when a compatible monitor or peripheral is detected. That means the broader issue is not just about one brand, but about how Windows handles device-associated application downloads in general. There is a trade-off here. Automatic installation can smooth setup and enable useful features, but it can also chip away at user trust if the system bundles promotions or installs apps without making the choice obvious.

For users and IT teams, the main question is how much control they really have over endpoint behavior. One option mentioned in the report is a Windows Group Policy setting that can prevent the automatic download of applications associated with device metadata. Turning that on may rein in unwanted installations, but it could also block legitimate tools that some monitors or peripherals need. This case is a reminder that convenience and control often pull in opposite directions. It also shows why consent, clear notices, and least-surprise design matter when hardware and operating systems work together.

PrismML has announced Bonsai 27B, a new multimodal AI model based on Qwen3.6 27B. The company says it is the first model in this capability class that can run on a phone. That claim matters because 27B-class models are usually seen as too large for mobile devices. They can handle harder tasks such as multi-step reasoning, structured tool calls, vision input, and agentic loops that stay coherent over many steps. In simple terms, this is the kind of model people want for real assistants, not just for short text replies.

The main reason this has been difficult is memory size. A full 27B model in 16-bit precision can take around 54 GB, and even a 4-bit version may still need about 18 GB. That is far beyond the limits of most phones and even many laptops. Bonsai 27B tries to break that barrier with two lower-bit versions. The ternary model uses weights of -1, 0, and +1, while the 1-bit model uses only -1 and +1. PrismML says the ternary version is about 5.9 GB and the 1-bit version is about 3.9 GB, small enough to fit within the memory budget of a recent high-end phone.

What stands out is that PrismML did not just compress one part of the model. According to the company, the low-bit setup runs end to end across the full language network, including embeddings, attention layers, MLPs, and the final language-model head. In other words, there are no higher-precision escape hatches hidden inside the system. Both versions are also multimodal. Their vision tower is shipped in a compact 4-bit form, so the model can work with screenshots, documents, and camera input as well as text. The model also supports a very long 262K-token context and speculative decoding, a method that speeds up generation by using a draft-and-verify process.

The benchmark results suggest a clear trade-off, but not a devastating one. Across 15 benchmarks, the ternary version reportedly retains about 95% of the full-precision baseline, while the 1-bit version keeps about 90%. The article says math and coding are nearly untouched, and tool calling remains fairly close to the original model. That is a key point because these are exactly the skills many agentic workloads depend on. If those results hold up in wider testing, the model could be more than a technical demo. It could become a practical option for local assistants that need to reason, call tools, and read visual information.

This matters beyond one product launch. Running stronger models on-device could shift the balance between cloud AI and local AI. For users, local inference can improve privacy, reduce network dependence, and lower latency. It can also keep features available when connectivity is weak. For developers, however, the picture is more mixed. On-device deployment must deal with battery limits, heat, performance differences across hardware, and tighter memory budgets. A model that fits on paper may still struggle in real-world use if response speed drops too far or if sustained workloads drain the device too quickly.

There is also a broader industry question. If very low-bit models can preserve most of the original intelligence, they may open the door to a new design space for laptops, phones, robots, and edge systems. At the same time, benchmark averages do not tell the whole story. Developers will want to see how such models behave under messy conditions, with long sessions, tool failures, and changing user input. PrismML has released Bonsai 27B under the Apache 2.0 License, which could help it gain traction quickly among researchers and product teams. The next thing to watch is whether this kind of compression becomes a one-off achievement or the start of a wider shift in how advanced AI is deployed.

vocabulary

A humorous article from design site VelvetShark asks a strange question: why do so many AI company logos look like the same circular shape with a hole in the middle? The joke is obvious, but the topic touches on a real branding trend. Many AI logos use soft curves, a central opening, radiating lines, and color gradients. Once people notice the pattern, it is hard to unsee. The article builds on an earlier observation from 2023, when Fast Company pointed out a similar trend in AI branding, though in more careful language.

One well-known example is OpenAI. According to the source context, its earlier logo was mainly text-based, but later branding moved toward a more circular symbol with a central void. OpenAI described this design in polished corporate language, saying it reflects the meeting point of humanity and technology. VelvetShark treats that explanation with skepticism and suggests that companies often dress up simple visual choices with abstract meaning after the fact. In other words, a design may begin as something that simply looks modern, and only later gain a deeper story.

This is not just about one company. The article argues that many major AI firms now lean toward similar visual identities. Circular, flower-like, or snowflake-like marks have become common, while some companies stand apart by choosing less abstract, less symmetrical designs. That pattern raises an interesting question: if branding is supposed to make a company distinct, why are so many firms converging on the same look? Part of the answer may be that designers want to signal safety, intelligence, creativity, and motion all at once, and soft geometric forms seem to tick those boxes.

There are practical reasons for this trend. A circular logo is easy to scale, easy to place in an app icon, and easy to animate. It also works well on websites, phones, and social media profiles, where small spaces matter. Gradients can make a logo feel current, and symmetry can suggest order and trust. In fast-moving markets, companies often borrow familiar visual cues to show that they belong to a new category. This can be a double-edged sword: a logo may look instantly recognizable as 'AI,' but it may also blend in with many rivals.

The source context also highlights Anthropic's Claude as a stronger case in the debate. VelvetShark compares it with a drawing from Kurt Vonnegut's book Breakfast of Champions and says the resemblance is difficult to ignore. It even mentions an interactive animation on Claude's site that, in the writer's view, adds fuel to the fire. Of course, this argument is partly comic and intentionally provocative. Still, the underlying point lands: when many users independently make the same visual joke, branding teams should probably pay attention.

Why does this matter beyond a laugh? In technology, design shapes first impressions. A logo is a shortcut for trust, personality, and product category. If every company reaches for the same symbols, the market may start to feel generic, even when the products are very different under the hood. For engineers and product teams, this is a useful reminder that user experience is not only about features. Visual identity also sends signals. As AI companies mature, it will be worth watching whether they keep following the circular trend or break away from it in search of a more distinctive presence.

Many people want to learn machine learning, but they do not know where to start. The field looks exciting, yet it can also feel overwhelming because it includes math, coding, models, and many tools. One practical way to begin is to follow a public study repository on GitHub. A Korean repository called "machine-learning" by teddylee777 is designed for beginners and for people preparing a study group. It brings several learning topics together in one place, which lowers the barrier to entry for learners who want a clear path.

From the source page, the repository includes folders such as Python, Kaggle, PyTorch, TensorFlow, TensorFlow 2.0, Pandas, visualization, and Scikit-Learn. Even this list tells us something important. Self-study in machine learning is not only about training models. It also involves programming basics, working with tables of information, drawing charts, and using common libraries for experiments. In other words, the repository seems to map out a broad learning journey rather than focusing on a single tool. That structure can keep learners from getting lost in the weeds too early.

For solo learners, that kind of roadmap matters. Many people jump straight into advanced model building and then hit a wall when they cannot explain the basics. A better approach is to build from the ground up. First, understand Python and simple data handling. Next, learn how to inspect results through visualization. After that, move on to classic machine learning with Scikit-Learn and then deeper frameworks like PyTorch or TensorFlow. This step-by-step order does not guarantee success, but it gives learners a sensible sequence and can make steady progress more realistic.

There are clear advantages to learning this way. A public repository is easy to access, and learners can revisit lessons at their own pace. They can also compare notebooks, rerun code, and branch out into side topics when curiosity strikes. For engineers, this style of study often fits better than a formal class because it connects theory with hands-on practice. Kaggle materials, for example, can expose learners to real problem-solving tasks. That said, self-study can be a double-edged sword. Freedom is useful, but without deadlines or feedback, some people lose momentum or spend too much time tweaking small details.

Another point to consider is how quickly the AI field moves. Tools and best practices shift fast, so any learning resource may lag behind the newest trends in some areas. Still, a well-organized repository can hold up well if it teaches durable foundations. Core ideas like problem framing, feature preparation, model evaluation, and clear visualization remain valuable even as specific libraries evolve. In that sense, a study repository is not only a set of tutorials. It can also act as a launch pad for deeper study, personal projects, and later specialization.

For today’s learners, the bigger lesson is simple: studying machine learning alone is possible if the path is visible and the materials are practical. Repositories like this one gain traction because they reduce uncertainty. They show that learning can start with small, repeatable steps instead of a perfect master plan. The most effective learners usually do not try to cover everything at once. They focus on consistent practice, review weak points, and build confidence over time. As AI becomes more relevant across industries, that disciplined habit may matter as much as any single model.

For many developers, frontend work used to feel simple. You could write an HTML file, add some CSS and JavaScript, upload the files, and the site was live. There was no long setup process and no huge list of tools to install first. Over time, that world changed. A recent deep-dive article argues that this change did not happen because developers enjoy complexity. Instead, each new tool arrived as a response to a real problem. In that view, modern frontend development is not random chaos. It is the result of many practical fixes built on top of earlier limits.

One of the first major shifts came when websites started to behave more like applications. Teams wanted small parts of a page to update without reloading everything. In the late 2000s, this became possible through browser features such as XMLHttpRequest, but the process was awkward and browser behavior was inconsistent. Libraries like jQuery gained traction because they hid many of those differences. They made common tasks, such as loading content or reacting to user actions, much easier. For a while, this was enough, and many websites became more dynamic without a complete rewrite of the page.

However, as products grew, developers ran into a deeper problem: keeping the screen in sync with the underlying state of the application. If a user changed one value, several parts of the interface might also need updates. A developer had to remember every place where the screen should change. If one piece was missed, the interface could show outdated or misleading information. This manual work became hard to manage at scale. It also created bugs that were difficult to trace, especially as teams and codebases became larger.

That problem set the stage for modern UI frameworks. Their key idea was declarative UI. Instead of writing every step needed to update the page, developers described what the screen should look like for a given state. The framework then handled the updates. This was a major turning point because it reduced a lot of repetitive work. At the same time, it introduced its own trade-offs. Once teams adopted component systems, build steps, package managers, and layers of tooling, frontend projects could become difficult for newcomers to navigate. The cure solved one wound, but it also added fresh overhead.

This history matters because it pushes back against the common view that frontend development became complicated for no reason. The article’s main thesis is that the ecosystem is a form of scar tissue: each layer exists because someone faced a genuine pain point and built a fix. Looking at the evolution in order helps explain why so many tools appeared. It also shows why opinions differ. Some developers see today’s stack as bloated and fragile. Others see it as the only practical way to build rich products with large teams, shared components, accessibility needs, and fast release cycles.

There is also an interesting twist in this story. After years of growing complexity, some parts of the industry now seem to be circling back toward simpler ideas. Developers still want good tooling, but many also want fewer moving parts and less ceremony. In other words, they want the benefits of modern practices without getting lost in the weeds. That does not mean the old days are simply returning. Today’s applications are far more demanding than a basic webpage uploaded by FTP. Still, the direction of travel suggests a clear lesson: before adopting a tool, it is worth asking which wound it actually heals and whether that trade-off still makes sense for your team.