Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
135960 stories
·
30 followers

Implementing Chat History for AI Applications Using Azure Cosmos DB Go SDK

1 Share

This blog post covers how to build a chat history implementation using Azure Cosmos DB for NoSQL Go SDK and langchaingo. If you are new to the Go SDK, the sample chatbot application presented in the blog serves as a practical introduction, covering basic operations like read, upsert, etc. It also demonstrates using the Azure Cosmos DB Linux-based emulator (in preview at the time of writing) for integration tests with Testcontainers for Go.

Go developers looking to build AI applications can use langchaingo, which is a framework for LLM-powered (Large Language Model) applications. It provides pluggable APIs for components like vector store, embedding, loading documents, chains (for composing multiple operations), chat history and more.

 

Chatbot application

Before diving in, let’s take a step back to understand the basics.

What is chat history and why it’s important for modern AI applications?

A common requirement for conversational AI applications is to be able to store and retrieve messages exchanged as part of conversations. This is often referred to as “chat history”. If you have used applications like ChatGPT (which also uses Azure Cosmos DB by the way!), you may be familiar with this concept. When a user logs in, they can start chatting and the messages exchanged as part of the conversation are saved. When they log in again, they can see their previous conversations and can continue from where they left off.

Chat history is obviously important for application end users, but let’s not forget about LLMs! As smart as LLMs might seem, they cannot recall past interactions due to lack of built-in memory (at least for now). Using chat history bridges this gap by providing previous conversations as additional context, enabling LLMs to generate more relevant and high-quality responses. This enhances the natural flow of conversations and significantly improves the user experience.

A simple example illustrates this: Suppose you ask an LLM via an API, "Tell me about Azure Cosmos DB" and it responds with a lengthy paragraph. If you then make another API call saying, "Break this down into bullet points for easier reading", the LLM might get confused because it lacks context from the previous interaction. However, if you include the earlier message as part of the context in the second API call, the LLM is more likely to provide an accurate response (though not guaranteed, as LLM outputs are inherently non-deterministic).

How to run the chatbot

Like I mentioned earlier, the sample application is a useful way for you to explore langchaingo, the Azure Cosmos DB chat history implementation, as well as the Go SDK.

Before exploring the implementation details, it’s a good idea to see the application in action. Refer to the README section of the GitHub repository that provides instructions on how to configure, run and start conversing with the chatbot.

Application overview

The chat application follows a straightforward domain model: users can initiate multiple conversations, and each conversation can contain multiple messages. Built in Go, the application includes both backend and frontend components.

  1. Backend: It has multiple sub-parts:
    • The Azure Cosmos DB chat history implementation.
    • Core operations like starting a chat, sending/receiving messages, and retrieving conversation history are exposed via a REST API.
    • The REST API leverages a langchaingo chain to handle user messages. The chain automatically incorporates chat history to ensure past conversations are sent to the LLM. langchaingo handles all orchestration – LLM invocation, chat history inclusion, and more without requiring manual implementation.
  2. Frontend: It is built using JavaScript, HTML, and CSS. It is packaged as part of the Go web server (using the embed package), and invokes the backend REST APIs in response to user interactions.

Chat history implementation using Azure Cosmos DB

langchaingo is a pluggable framework, including its chat history (or memory) component. To integrate Azure Cosmos DB, you need to implement the schema.ChatMessageHistory interface, which provides methods to manage the chat history:

  1. AddMessage to add messages to a conversation (or start a new one).
  2. Messages to retrieve all messages for a conversation.
  3. Clear to delete all messages in a conversation.

While you can directly instantiate a CosmosDBChatMessageHistory instance and use these methods, the recommended approach is to integrate it into the langchaingo application. Below is an example of using Azure Cosmos DB chat history with a LLMChain:

// Create a chat history instance
cosmosChatHistory, err := cosmosdb.NewCosmosDBChatMessageHistory(cosmosClient, databaseName, containerName, req.SessionID, req.UserID)
if err != nil {
	log.Printf("Error creating chat history: %v", err)
	sendErrorResponse(w, "Failed to create chat session", http.StatusInternalServerError)
	return
}

// Create a memory with the chat history
chatMemory := memory.NewConversationBuffer(
	memory.WithMemoryKey("chat_history"),
	memory.WithChatHistory(cosmosChatHistory),
)

// Create an LLM chain
chain := chains.LLMChain{
	Prompt:       promptsTemplate,
	LLM:          llm,
	Memory:       chatMemory,
	OutputParser: outputparser.NewSimple(),
	OutputKey:    "text",
}

From an Azure Cosmos DB point of view, note that the implementation in this example is just one of many possible options. The one shown here is based on a combination of userid as the partition key and conversation ID (also referred to as the session ID sometimes) being the unique key (id of an Azure Cosmos DB item).

This allows an application to:

  • Get all the messages for a conversation – This is a point read using the unique id (conversation ID) and partition key (user ID).
  • Add a new message to a conversation – It uses an upsert operation (instead of create) to avoid the need for a read before write.
  • Delete a specific conversation – It uses the delete operation to remove a conversation (and all its messages).

Although the langchaingo interface does not expose it, when integrating this as a part of an application, you can also issue a separate query to get all the conversations for a user. This is also efficient since its scoped to a single partition.

Simplify testing with Azure Cosmos DB emulator and testcontainers

The sample application includes basic test cases for both Azure Cosmos DB chat history and the main application. It is worth highlighting the use of testcontainers-go to integrate the Azure Cosmos DB Linux-based emulator docker container.

This is great for integration tests since the database is available locally and the tests run much faster (let’s not forget the cost savings as well!). An icing on top is that you do not need to manage the Docker container lifecycle manually. This is taken care as part of the test suite, thanks to the testcontainers-go API which makes it convenient to start the container before the tests run and terminate it once they complete.

You can refer to the test cases in the sample application for more details. Here is a snippet of how testcontainers-go is used:

func setupCosmosEmulator(ctx context.Context) (testcontainers.Container, error) {
	req := testcontainers.ContainerRequest{
		Image:        emulatorImage,
		ExposedPorts: []string{emulatorPort + ":8081", "1234:1234"},
		WaitingFor:   wait.ForListeningPort(nat.Port(emulatorPort)),
	}

	container, err := testcontainers.GenericContainer(ctx, testcontainers.GenericContainerRequest{
		ContainerRequest: req,
		Started:         true,
	})
	if err != nil {
		return nil, fmt.Errorf("failed to start container: %w", err)
	}

	// Give the emulator a bit more time to fully initialize
	time.Sleep(5 * time.Second)

	return container, nil
}

If you’re interested in using the Azure Cosmos DB Emulator in CI pipelines, check out the blog post – Using the Azure Cosmos DB Emulator in CI/CD Pipelines.

Wrapping Up

Being able to store chat history is an important part of conversational AI apps. They can serve as a great add-on to existing techniques such as RAG (Retrieval Augmented Generation). Do try out the chatbot application and let us know what you think!

While the implementation in the sample application is relatively simple, how you model the chat history data depends on the requirements. One such scenario has been presented is this excellent blog post on How Microsoft Copilot scales to millions of users with Azure Cosmos DB.

Some of your requirements might include:

  • Storing metadata, such as reactions (in addition to messages)
  • Showing top N recent messages
  • Considering chat history data retention period (using TTL)
  • Incorporating additional analytics (on user interactions) based on the chat history data, and more.

Irrespective of the implementation, always make sure to incorporate best practices for data modeling. Refer How to model and partition data on Azure Cosmos DB using a real-world example for guidelines.

Are you already using or planning to leverage Azure Cosmos DB for your Go applications? We would love to hear from you! Send us your questions and feedback.

Leave a review

Tell us about your Azure Cosmos DB experience! Leave a review on PeerSpot and we’ll gift you $50. Get started here.

About Azure Cosmos DB

Azure Cosmos DB is a fully managed and serverless NoSQL and vector database for modern app development, including AI applications. With its SLA-backed speed and availability as well as instant dynamic scalability, it is ideal for real-time NoSQL and MongoDB applications that require high performance and distributed computing over massive volumes of NoSQL and vector data.

Try Azure Cosmos DB for free here. To stay in the loop on Azure Cosmos DB updates, follow us on XYouTube, and LinkedIn.

The post Implementing Chat History for AI Applications Using Azure Cosmos DB Go SDK appeared first on Azure Cosmos DB Blog.

Read the whole story
alvinashcraft
7 hours ago
reply
Pennsylvania, USA
Share this story
Delete

A 10x Faster TypeScript

1 Share

Today I’m excited to announce the next steps we’re taking to radically improve TypeScript performance.

The core value proposition of TypeScript is an excellent developer experience. As your codebase grows, so does the value of TypeScript itself, but in many cases TypeScript has not been able to scale up to the very largest codebases. Developers working in large projects can experience long load and check times, and have to choose between reasonable editor startup time or getting a complete view of their source code. We know developers love when they can rename variables with confidence, find all references to a particular function, easily navigate their codebase, and do all of those things without delay. New experiences powered by AI benefit from large windows of semantic information that need to be available with tighter latency constraints. We also want fast command-line builds to validate that your entire codebase is in good shape.

To meet those goals, we’ve begun work on a native port of the TypeScript compiler and tools. The native implementation will drastically improve editor startup, reduce most build times by 10x, and substantially reduce memory usage. By porting the current codebase, we expect to be able to preview a native implementation of tsc capable of command-line typechecking by mid-2025, with a feature-complete solution for project builds and a language service by the end of the year.

You can build and run the Go code from our new working repo, which is offered under the same license as the existing TypeScript codebase. Check the README for instructions on how to build and run tsc and the language server, and to see a summary of what’s implemented so far. We’ll be posting regular updates as new functionality becomes available for testing.

How Much Faster?

Our native implementation is already capable of loading many popular TypeScript projects, including the TypeScript compiler itself. Here are times to run tsc on some popular codebases on GitHub of varying sizes:

Codebase Size (LOC) Current Native Speedup
VS Code 1,505,000 77.8s 7.5s 10.4x
Playwright 356,000 11.1s 1.1s 10.1x
TypeORM 270,000 17.5s 1.3s 13.5x
date-fns 104,000 6.5s 0.7s 9.5x
tRPC (server + client) 18,000 5.5s 0.6s 9.1x
rxjs (observable) 2,100 1.1s 0.1s 11.0x

While we’re not yet feature-complete, these numbers are representative of the order of magnitude performance improvement you’ll see checking most codebases.

We’re incredibly excited about the opportunities that this massive speed boost creates. Features that once seemed out of reach are now within grasp. This native port will be able to provide instant, comprehensive error listings across an entire project, support more advanced refactorings, and enable deeper insights that were previously too expensive to compute. This new foundation goes beyond today’s developer experience and will enable the next generation of AI tools to enhance development, powering new tools that will learn, adapt, and improve the coding experience.

Editor Speed

Most developer time is spent in editors, and it’s where performance is most important. We want editors to load large projects quickly, and respond quickly in all situations. Modern editors like Visual Studio and Visual Studio Code have excellent performance as long as the underlying language services are also fast. With our native implementation, we’ll be able to provide incredibly fast editor experiences.

Again using the Visual Studio Code codebase as a benchmark, the current time to load the entire project in the editor on a fast computer is about 9.6 seconds. This drops down to about 1.2 seconds with the native language service, an 8x improvement in project load time in editor scenarios. What this translates to is a faster working experience from the time you open your editor to your first keystroke in any TypeScript codebase. We expect all projects to see this level of improvement in load time.

Overall memory usage also appears to be roughly half of the current implementation, though we haven’t actively investigated optimizing this yet and expect to realize further improvements. Editor responsiveness for all language service operations (including completion lists, quick info, go to definition, and find all references) will also see significant speed gains. We’ll also be moving to the Language Server Protocol (LSP), a longstanding infrastructural work item to better align our implementation with other languages.

Versioning Roadmap

Our most recent TypeScript release was TypeScript 5.8, with TypeScript 5.9 coming soon. The JS-based codebase will continue development into the 6.x series, and TypeScript 6.0 will introduce some deprecations and breaking changes to align with the upcoming native codebase.

When the native codebase has reached sufficient parity with the current TypeScript, we’ll be releasing it as TypeScript 7.0. This is still in development and we’ll be announcing stability and feature milestones as they occur.

For the sake of clarity, we’ll refer to them simply as TypeScript 6 (JS) and TypeScript 7 (native), since this will be the nomenclature for the foreseeable future. You may also see us refer to “Strada” (the original TypeScript codename) and “Corsa” (the codename for this effort) in internal discussions or code comments.

While some projects may be able to switch to TypeScript 7 upon release, others may depend on certain API features, legacy configurations, or other constraints that necessitate using TypeScript 6. Recognizing TypeScript’s critical role in the JS development ecosystem, we’ll still be maintaining the JS codebase in the 6.x line until TypeScript 7+ reaches sufficient maturity and adoption.

Our long-term goal is to keep these versions as closely aligned as possible so that you can upgrade to TypeScript 7 as soon as it meets your requirements, or fall back to TypeScript 6 if necessary.

Next Steps

In the coming months we’ll be sharing more about this exciting effort, including deeper looks into performance, a new compiler API, LSP, and more. We’ve written up some FAQs on the GitHub repo to address some questions we expect you might have. We also invite you to join us for an AMA at the TypeScript Community Discord at 10 AM PDT | 5 PM UTC on March 13th.

A 10x performance improvement represents a massive leap in the TypeScript and JavaScript development experience, so we hope you are as enthusiastic as we are for this effort!

The post A 10x Faster TypeScript appeared first on TypeScript.

Read the whole story
alvinashcraft
7 hours ago
reply
Pennsylvania, USA
Share this story
Delete

A closer look at the details behind the Go port of the TypeScript compiler

1 Share

Today’s announcement by Microsoft:

[...] we’ve begun work on a native port of the TypeScript compiler and tools. The native implementation will drastically improve editor startup, reduce most build times by 10×, and substantially reduce memory usage.

This blog post looks at some of the details behind the news.

Read the whole story
alvinashcraft
7 hours ago
reply
Pennsylvania, USA
Share this story
Delete

Super Charge Copilot Chat

1 Share

Do you know to know an awesome trick to make GitHub Copilot Chat an expert in GenAIScript? Here’s how you can supercharge your Copilot chat with simple technique.

Add your entire documentation to the chat session!

Sounds crazy? Not really! The GenAIScript contains countless examples and examples of usage of APIs. It just needs to be compressed to fit into the context window.

How do I try this?

With the latest release of GenAIScript, you can now add a genaiscript prompt to your chat session. This prompt, crafted by the GenAIScript team, will include the GenAIScript documentation into the context to help the LLM provider better answers.

How it works?

The release of the latest GitHub Copilot Chat is adding support for reusable prompts. GiHub Copilot Chat also added support for local workspace indexing, which helps with handling large amount of context.

GenAIScript leverages these features by adding a custom prompt that includes the GenAIScript documentation.

.github/prompts/genaiscript.prompt.md
## Role
You are an expert at the GenAIScript programming language (https://microsoft.github.io/genaiscript). Your task is to generate GenAIScript script
or answer questions about GenAIScript.
## Reference
- [GenAIScript docs](../../.genaiscript/docs/llms-full.txt)
- [GenAIScript ambient type definitions](../../.genaiscript/genaiscript.d.ts)
## Guidance for Code Generation
- you always generate TypeScript code using ESM models for Node.JS.
- you prefer using APIs from GenAIScript 'genaiscript.d.ts' rather node.js. Avoid node.js imports.
- you keep the code simple, avoid exception handlers or error checking.
- you add TODOs where you are unsure so that the user can review them
- you use the global types in genaiscript.d.ts are already loaded in the global context, no need to import them.

To be continued

This technique is really new and there’s probably lots of improvment to be done.

Read the whole story
alvinashcraft
7 hours ago
reply
Pennsylvania, USA
Share this story
Delete

Tech Moves: Longtime Google leader Umesh Shankar joins Microsoft as new corporate VP

1 Share
Umesh Shankar. (LinkedIn Photo)

After nearly 19 years at Google, Umesh Shankar has joined Microsoft AI as a corporate vice president of engineering.

Shankar, based in New York City, has focused his career on privacy and security. His last role at Google was chief technologist and distinguished engineer for Google Cloud Security.

Shankar will lead a new privacy and security engineering effort focused on Microsoft’s Copilot AI assistant, according to Microsoft AI CEO Mustafa Suleyman.

“I believe that investing in a secure technical foundation will actually allow us to innovate with AI faster than we could in a world where giving AI more data and tools comes with unknown or unbounded risk,” he said on LinkedIn. “That’s why I’ll be focusing on building systems and platforms that have strong protections and user control built in.”

Shankar is the latest Google leader to join Microsoft AI in recent months. The unit has poached several execs from Google DeepMind, which was originally co-founded as a startup research lab by Suleyman.

Josh Hug. (LinkedIn Photo)

Remitly co-founder Josh Hug is leaving his role as vice chair of the company’s board of directors, and will become a board member, according to a SEC filing.

Hug has served as chief product officer and chief operator of the Seattle-based remittance company. Prior to Remitly, Hug co-founded Shelfari, a social platform for book lovers, that he led until 2008 when it was acquired by Amazon. Hug remained at Amazon for three years, leaving to help launch Remitly. Earlier in his career Hug worked at RealNetworks.

Hug is now based in Miami, according to his LinkedIn profile.

— Kate Cohen joined Boise-based recruiting software company Crelate as vice president of marketing. Cohen previously held marketing leadership roles at Voltron Data, Randstad USA, and Aptum.

Dina Bass. (LinkedIn Photo)

Dina Bass, a reporter covering Microsoft news for Bloomberg for more than two decades, has switched beats. Bass is now reporting on a newly created focus dubbed AI infrastructure.

“I’m looking forward to tackling the rapidly growing AI infrastructure area in all its aspects, opportunities and challenges — chips, servers, networking, energy, water, land, financing and more — looking at startups, established companies and the public sector,” Bass shared on LinkedIn.

Brody Ford will be joining the Microsoft beat at Bloomberg, teaming up with Matt Day.

Adam Loving. (LinkedIn Photo)

Pioneer Square Labs’ Adam Loving has joined Meta’s Bellevue, Wash., office as a partner engineer on Llama Enterprise.

Loving was principal software engineer and engineering manager for Seattle’s PSL for more than nine years, working with nearly three dozen startups. His roles at the startup incubator included creating Picco, an LLM-powered code generation agent, and serving as interim CTO for new companies.

Peggy Sloan. (Seattle Aquarium Photo)

Seattle Aquarium announced Peggy Sloan as its new president and CEO. In May Sloan will take over from Bob Davidson, who is retiring after more than 22 years at the aquarium. The organization is a world leader in marine conservation and restoration. In August it celebrated the opening of its immersive Ocean Pavilion expansion.

Sloan is an expert in marine biology and comes to the role from the John G. Shedd Aquarium in Chicago, one of the nation’s first and largest aquariums. She was previously at the North Caroline Aquarium at Fort Fisher.

The role marks Sloan’s return to the Pacific Northwest. Early in her career, she was a Seattle-based NOAA fisheries observer, deployed on catchers and trawlers in the Bering Sea.

— Longtime Seattle engineer Werner Koepf is now chief product and technology officer for the multilingual translation platform Lilt. Koepf comes to the role from Karat, where he was senior vice president of engineering for more than four years. His career includes leadership roles at Seattle companies Expedia, Amazon, Conversica, Ticketmaster and Wetpaint.

Katharine Reinhold is the executive direct of Built Oregon, an organization supporting the state’s consumer product companies and ecosystem. Reinhold was previously a mentor and board member with the group, and currently serves as chief product officer for Pod, a leadership and business consulting company. Reinhold was previously director of innovation at Adidas, where she worked for more than 13 years.

Fred Hutch Cancer Center announced the winner of the international Harold M. Weintraub Graduate Student Award. The 2025 winner is Jeremy Hollis, a research assistant in the Basic Sciences Division at Seattle’s Fred Hutch. His work is focused on a protein component that is implicated in multiple diseases.

Herman Radtke is chief technologist at Trove, a California “recommerce” company. Radtke comes to the role from Narvar and formerly held senior engineering roles at Nordstrom Rack.

Read the whole story
alvinashcraft
7 hours ago
reply
Pennsylvania, USA
Share this story
Delete

Trump says he will label violence against Tesla as domestic terrorism

1 Share

President Donald Trump said he will label violence against Tesla dealerships as domestic terrorism, per a transcript shared by the White House pool reporters, a sign of deepening ties with Elon Musk. “Tesla Takeovers” have been breaking out across the globe at Tesla dealerships as people protest what they see as a hostile takeover of […]

© 2024 TechCrunch. All rights reserved. For personal use only.

Read the whole story
alvinashcraft
7 hours ago
reply
Pennsylvania, USA
Share this story
Delete
Next Page of Stories